星空网 > 软件开发 > 操作系统

git笔记

这篇有关git的博客,写着写着有些崩了。里面有些碎碎念了。下次一定注意这个问题。

创建项目:

  • midir xx :创建xx文件夹
  • git init : 为当前文件夹创建代码仓库

提交代码:

  • git add xx : 将文件名为xx的文件暂存起来,当commit的时候就提交到代码仓库
  • git commit -m "xx" : 为当前提交添加描述

检查状态:

  • git status : 检查当前仓库的状态,即查看是否存在未提交的新文件
  • git log : 查看更改清单

单行历史

你可以很好的控制处理 log 命令要精确显示的内容。我喜欢 单行格式:

$ git log --pretty=oneline

你应该看到:

$ git log --pretty=oneline1f7ec5eaa8f37c2770dae3b984c55a1531fcc9e7 Added a comment582495ae59ca91bca156a3372a72f88f6261698b Added a default value323e28d99a07d404c04f27eb6e415d4b8ab1d615 Using ARGV94164160adf8faa3119b409fcfcd13d0a0eb8020 First Commit

控制显示哪个条目

log 命令有许多选项用来选择显示哪个条目。玩玩下面的选 项:

$ git log --pretty=oneline --max-count=2$ git log --pretty=oneline --since='5 minutes ago'$ git log --pretty=oneline --until='5 minutes ago'$ git log --pretty=oneline --author=<your name>$ git log --pretty=oneline --all

参阅 man git-log 了解更多细节。

更加漂亮

这是我用来复查上周所做更改的命令。如果我只想看自己所 作的更改,那么我将添加--author=jim

$ git log --all --pretty=format:'%h %cd %s (%an)' --since='7 days ago'

终极日志格式

随着时间的推移,我发现在工作时最喜欢下列日志格式。

$ git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short'

它看起来像这样:

$ git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short* 1f7ec5e 2013-04-13 | Added a comment (HEAD, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

让我们看一下细节:

  • --pretty="..." 定义输出的格式
  • %h 是提交 hash 的缩写
  • %d 是提交的装饰(如分支头或标签)
  • %ad 是创作日期
  • %s 是注释
  • %an 是作者姓名
  • --graph 使用 ASCII 图形布局显示提交树
  • --date=short 保留日期格式更好且更短

 

获取旧版本:

  • git checkout <hash> :检查日志输出,并且找到hash对应的提交,和下面的配合,能看到这次提交的改变
  • cat 文件名 : 如 hello.rb
  • git checkout master : 返回最新的版本

为版本打标签

  • git tag xx : 为当前版本打上标签XX, 如 git tag v1

标记先前的版本======》通过上面的方法获取旧版本,然后再为当前版本打标签。

  • git tag :获取日志中的所有标签

去除标签:

  • git tag -d xx : 移除标签xx

撤销更改:(这里都以hello.rb文件为例)

  1. 撤销本地更改(更改的内容没有缓存,更没有提交)

     @处理之前确定你在master的最新提交上===》 git checkout master ; 

     @检查状态,确定更改的内容没有缓存,更没有提交,属于撤销本地更改===》 git status;

     @使用checkout命令检出更改的文件,在仓库中的版本,以hello.rb文件为例    

$ git checkout hello.rb  //这句就撤销了本地更改,下面两句是查看 hello.rb 的内容$ git status$ cat hello.rb

 

   2.撤销缓存更改

    @检查状态,确定更改的内容已经缓存,但没有提交,属于撤销缓存更改===》 git status;

    @清空暂存区内容===》git reset HEAD hello.rb

    @使用checkout命令检出提交的版本(即上一次提交的内容)===》git checkout hello.rb

    3.撤销提交的更改

    @使用创建一个提交来移除由不想 要的提交所引入的更改===》git reset HEAD

    @上面的语句将进入编辑器,你可以编辑默认的提交信息,或直接 离开它。保存并关闭文件。会看到:

$ git revert HEAD[master f98cb24] Revert "third commit" 1 file changed, 1 insertion(+), 3 deletions(-)

 

   @第二步就已经成功了,此时让我们来查看提交记录(这里的git hist 是自己定义的命令,可以用git log 查看):

$ git hist* f98cb24 2016-04-04 | Revert "third commit" (HEAD -> master) [mecury]* da6b209 2016-04-04 | third commit [mecury]* d44641b 2016-04-04 | second commit (tag: v1) [mecury]* 46de4a5 2016-04-04 | First Commit (tag: v1-beta) [mecury]

 

重置分支:

首先,标记分支

但在我们移除提交前,让我们使用一个标签来标记最新的提 交以便能够再次找到它。

$ git tag oops

重置到 Oops 前

看看上面的日志历史,我们将知道标记为“v1”的提交是错误 提交之前的正确提交。让我们重置分支到该位置。因为分支 已经标记,所以我们可以在 reset 命令中使用标签名( 如果它没有被标记,那么我们只能使用哈希值)。

$ git reset --hard v1$ git hist
$ git reset --hard v1HEAD is now at 1f7ec5e Added a comment$ git hist* 1f7ec5e 2013-04-13 | Added a comment (HEAD, v1, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

我们的 master 分支现在指到 v1 提交,并且 Oops 和 Revert Oops 提 交已经不在分支中。--hard 参数表示应当更新工作目录以便与新的分 支头保持一致。

什么也没丢

但错误的提交发生了什么?结果是提交仍然在仓库中。事实上,我们仍然 能够引用它们。记得在本实验开始我们使用标签“oops”标记了还原的提交。 让我们看看所有的提交。

$ git hist --all
$ git hist --all* a10293f 2013-04-13 | Revert "Oops, we didn't want this commit" (oops) [Jim Weirich]* 838742c 2013-04-13 | Oops, we didn't want this commit [Jim Weirich]* 1f7ec5e 2013-04-13 | Added a comment (HEAD, v1, master) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

在这儿我们看到错误的提交并没有消失。它们仍然在仓库中。它们只是不再 列到 master 分支中。如果我们没有标记它们,它们依然在仓库中,但除了 使用哈希值外没有别的方法引用它们。未引用的提交保留在仓库中,一直到 系统运行垃圾回收软件时。

修正提交:

更改程序并提交

给程序添加作者注释。

# Default is World# Author: Jim Weirichname = ARGV.first || "World"puts "Hello, #{name}!"
$ git add hello.rb$ git commit -m "Add an author comment"

唉,该有 Email 啊

在你做了提交之后,你意识到任何好的作者注释都应该包含 Email 地址。更新 hello 程序来包含 Email。

# Default is World# Author: Jim Weirich (jim@somewhere.com)name = ARGV.first || "World"puts "Hello, #{name}!"

修正先前的提交

我们真的不想因为 Email 而分开提交。让我们修正先前的提交 来包含 Email 更改。

$ git add hello.rb$ git commit --amend -m "Add an author/email comment"
$ git add hello.rb$ git commit --amend -m "Add an author/email comment"[master eb30103] Add an author/email comment 1 files changed, 2 insertions(+), 1 deletions(-)

回顾历史

$ git hist
$ git hist* eb30103 2013-04-13 | Add an author/email comment (HEAD, master) [Jim Weirich]* 1f7ec5e 2013-04-13 | Added a comment (v1) [Jim Weirich]* 582495a 2013-04-13 | Added a default value (v1-beta) [Jim Weirich]* 323e28d 2013-04-13 | Using ARGV [Jim Weirich]* 9416416 2013-04-13 | First Commit [Jim Weirich]

我们可以看到最初的“author”提交现在消失了,而且它已经 被“author/email”提交替换。通过重置分支到某个提交并重 新提交新的更改,你可以实现相同的效果。

 移动文件:

  •  mkdir xx  :  在当前文件夹下,创建 XX 文件
  • git mv hello.rb lib  ===>将hello.rb 文件移动到 lib 文件夹下
  • git status : 查看到以下的状态
$ git statusOn branch masterChanges to be committed: (use "git reset HEAD <file>..." to unstage)    renamed:  hello.rb -> lib/hello.rbChanges not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)

  • git commit -m "xxxx" :将此次改变提交

通过使用 Git 来移动文件,我们通知了 Git 两件事:

  1. 文件 hello.rb 已被删除。
  2. 文件 lib/hello.rb 已被创建

 

 

Git

创建分支
  git checkedou -b greet //创建了一个名为greet的新分支

!上面语句是git branch branchname 及 git checkout branchname的简写(branchname:分支名)

导航分支
  git checkout master //切换到master主分支

git checkout branchname:切换到分支branchname

当有两个或多个分支时,使用
  git hist --all //--all能显示出来所有的分支

git笔记images/loading.gif' data-original="http://i.imgur.com/DlJk6Qh.png" />

合并分支
  git merge master //将分支mster合并到当前分支

git笔记

冲突产生于解决(坑太多,只举个小例子)

将分支切到master,此时更改hello.rb并且提交就会产生冲突。
原因:应为master已经和greet分支合并,但现在在master又有一个新的提交还没有合并回greet,冲突产生。

 

如果此时返回greet分支并且尝试合并master分支后,查看hello.rb,如图

git笔记

冲突解决:在hello.rb中改正后,重新提交hello.rb

解决后:

git笔记

变址vs合并
  1. 重置greet分支git笔记
  2. 重置master分支
  3. git笔记
(未知的问题:在重置greet分支后,立即重置master分支出现错误,好像需要重新提交所有文件)

变基失败

 

实用篇

与远程仓库建立联系remote

查看所有的远程链接信息

git remote -v

查看某个远程连接的详细信息

git remote show [remote-name]

为本地添加一个普通的远程仓库git remote add pb git://github.com/paulboone/ticgit.gitpb为仓库的别名,后面为仓库的地址

为本地添加一个origin仓库

git remote add origin [仓库url]

重命名远程连接git remote renamed [old name] [new name]

删除远程仓库git remote rm [shortname]

pull 和 fetch 的区别:

1.git fetch 相当于是从远程获取最新版本到本地,不会自动mergegit fetch origin master

2.git pull 当于是从远程获取最新版本并merge到本地

git向github提交代码

1. 创建新的版本库
在GitHub中,一个项目对应一个版本库,创建一个新的版本库,就是创建一个新的项目。

在GitHub中创建一个新的版本库后,采取先克隆,再通过推送完成GitHub版本库的初始化。步骤如下:

1.克隆版本库:

git clone git@github.com:mecury/HelloWorld.git //mecury是注册时的名字,HelloWorld是新创建的版本库</br>

2.添加README.md文件并提交(这个也可以直接在GitHub中修改)

git add REAMDE.md

3.向GitHub中推送,完成版本库的初始化

git push origin master

2.从已有的版本库中创建

对于要上传的项目,首先应该建立本地的仓库.
git init //在当前项目的根目录下
向文件中添加README.md文件,并且提交(可以省略)
git add README.mdgit commit -m"README for project"
执行推送命令
git push -u origin master
强制推送命令,将会覆盖远程仓库的不同之处
git push -f origin master

 

退出git的vim编辑器:

  1.按 i ,进入insert编辑模式

  2. 编辑完成后,按 esc 键

  3. 输入 :wq! ,然后回车即可删除




原标题:git笔记

关键词:Git

Git
*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。
相关文章
我的浏览记录
最新相关资讯
海外公司注册 | 跨境电商服务平台 | 深圳旅行社 | 东南亚物流