Git 实践备忘

---

git初始化的一些操作

$ git pushssh://git@dev.lemote.com/rt4ls.git master // 把本地仓库提交到远程仓库的master分支中

$ git remote add originssh://git@dev.lemote.com/rt4ls.git

$ git push origin master

这两个操作是等价的，第二个操作的第一行的意思是添加一个标记，让origin指向ssh://git@dev. lemote.com/rt4ls.git也就是说你操 作origin的时候，实际上就是在操作ssh://git@dev. lemote.com/rt4ls.git。origin在这里完全可以理解为后者 的别名。 $ git remote add origin  ssh://git@dev.lemote.com/rt4ls.git 这一步基本在创建git库的时候就会被初始化了。

---

分支的一些操作

在一个分支下面修改完代码，需要在这个分支下面commit了代码以后再切换到其他分支比较好。

如果在某个分支下修改了但是没commit，在其他分支commit的话，那么之前修改的都算是在这个分支下的修改。所以在切换分支的时候最好要commit

删除develope分支：

git branch -D develope

切换到服务器上的某个分支

Git checkout origin/master

 git branch –r 列出服务器git库的所有分支。 

（可以继续使用命令 “ git checkout -b 本地分支名 服务器分支名”来获取服务器上某个分支的代码文件）。 

删除服务器上的某个分支：

不能用这个：这个还是会隐藏那里git branck -Dr origin/dev

要有：git push origin :dev  这样dev就被删除了

提交到服务器上面的dev分支上去

git push origin master:dev

 

pull：

把服务器上面的dev分支的代码pull到本地develope上:

git pull origin dev:develope

---

stash 缓存当前工作 mac上基本不用，可以用可视化界面来修改

使用git的时候，我们往往使用branch解决任务切换问题，例如，我们往往会建一个自己的分支去修改和调试代码, 如果别人或者自己发现原有的分支上有个不得不修改的bug，我们往往会把完成一半的代码 commit提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。这样的话往往log上会有大量不必要的记录。其实如果我们不想提交完成一半或者不完善的代码，但是却不得不去修改一个紧急Bug，那么使用'git stash'就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修 Bug，等到修完Bug，提交到服务器上后，再使用'git stash apply'将以前一半的工作应用回来。也许有的人会说，那我可不可以多次将未提交的代码压入到栈中？答案是可以的。当你多次使用'git stash'命令后，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，'git stash list'命令可以将当前的Git栈信息打印出来，你只需要将找到对应的版本号，例如使用'git stash apply stash@{1}'就可以将你指定版本号为stash@{1}的工作取出来，当你将所有的栈都应用回来的时候，可以使用'git stash clear'来将栈清空。
在这里顺便提下git format-patch -n , n是具体某个数字， 例如 'git format-patch -1' 这时便会根据log生成一个对应的补丁，如果 'git format-patch -2' 那么便会生成2个补丁，当然前提是你的log上有至少有两个记录。

---

标签：

轻量级标签

轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。要创建这样的标签，一个 -a，-s 或 -m 选项都不用，直接给出标签名字即可：

$ git tag v1.4-lw

含附注的标签

创建一个含附注类型的标签非常简单，用 -a （译注：取 annotated 的首字母）指定标签名字即可：

$ git tag -a v1.4 -m 'my version 1.4'

用log 一行行查看commit 

$ git log --pretty=oneline

然后给某个commit打标签tag

$ git tag -a v1.2 9fceb02 -m "first"  

删除标签的命令

git tag -d v1.2

删除远端服务器的标签

git push origin :refs/tags/v1.2

从服务器上拉下所有tag

git pull --tags

提交所有tag到服务器上

git push --tags

---

分支回滚

有时候使用Git工作得小心翼翼，特别是涉及到一些高级操作，例如 reset, rebase 和 merge。甚至一些很小的操作，例如删除一个分支，我都担心数据丢失。

不久之前，我在做一些大动作（rebasing）之前，我总是备份整个版本库，以防万一。直到最近我才发现git的历史记录是不可修改的，也就是说你不能更改任何已经发生的事情。你做的任何操作都只是在原来的操作上修改。也就是说，即使你删除了一个分支，修改了一个提交，或者强制重置，你仍然可以回滚这些操作。

让我们来看一些例子：

$ git init

$ touch foo.txt

$ git add foo.txt

$ git commit -m "initial commit"

$ echo 'new data' >> foo.txt

$ git commit -a -m "more stuff added to foo"

你现在看git的历史记录，你可以看到两次提交：

$ git log

* 98abc5a (HEAD, master) more stuff added to foo

* b7057a9 initial commit

现在让我们来重置回第一次提交的状态：

$ git reset --hard b7057a9

$ git log

* b7057a9 (HEAD, master) initial commit

这看起来我们是丢掉了我们第二次的提交，没有办法找回来了。但是 reflog 就是用来解决这个问题的。简单的说，它会记录所有HEAD的历史，也就是说当你做 reset，checkout等操作的时候，这些操作会被记录在reflog中。

$ git reflog

b7057a9 HEAD@{0}: reset: moving to b7057a9

98abc5a HEAD@{1}: commit: more stuff added to foo

b7057a9 HEAD@{2}: commit (initial): initial commit

所以，我们要找回我们第二commit，只需要做如下操作：

$ git reset --hard 98abc5a

再来看一下 git 记录：

$ git log

* 98abc5a (HEAD, master) more stuff added to foo

* b7057a9 initial commit

所以，如果你因为reset等操作丢失一个提交的时候，你总是可以把它找回来。除非你的操作已经被git当做垃圾处理掉了，一般是30天以后。

---

合并merge rebase

git merge是用来合并两个分支的。

git merge b

      # 将b分支合并到当前分支

同样 git rebase b，也是把 b分支合并到当前分支

-----------------------------------

他们的 原理 如下：

假设你现在基于远程分支"origin"，创建一个叫"mywork"的分支。

$ git checkout -b mywork origin

假设远程分支"origin"已经有了2个提交，如图

现在我们在这个分支做一些修改，然后生成两个提交(commit).

$ vi file.txt

$ git commit

$ vi otherfile.txt

$ git commit

...

但是与此同时，有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着"origin"和"mywork"这两个分支各自"前进"了，它们之间"分叉"了。

在这里，你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的"合并的提交"(merge commit):

 

但是，如果你想让"mywork"分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase:

$ git checkout mywork

$ git rebase origin

这些命令会把你的"mywork"分支里的每个提交(commit)取消掉，并且把它们临时 保存为补丁(patch)(这些补丁放到".git/rebase"目录中),然后把"mywork"分支更新 为最新的"origin"分支，最后把保存的这些补丁应用到"mywork"分支上。

 

当'mywork'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc)

 

二、解决冲突

在 rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用" git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:

$  git rebase   --continue

这样git会继续应用(apply)余下的补丁。

在任何时候，你可以用--abort参数来终止rebase的行动，并且"mywork" 分支会回到rebase开始前的状态。

$  git rebase   --abort

三、git rebase和git merge的区别

现在我们可以看一下用合并( merge )和用 rebase 所产生的历史的区别：

当我们使用Git log来参看commit时，其commit的顺序也有所不同。

假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM，C6提交于12:00AM,

对于使用 git merge 来合并所看到的commit的顺序（从新到旧）是： C7 , C6 , C4, C5 , C3 ,C2,C1

对于使用 git rebase 来合并所看到的commit的顺序（从新到旧）是： C7 , C6‘,C5' ,C4,C3, C2,C1

 因为C6'提交只是C6提交的克隆，C5'提交只是C5提交的克隆，

从用户的角度看使用 git rebase 来合并后所看到的commit的顺序（从新到旧）是： C7 , C6,C5 , C4,C3 ,C2,C1

---

冲突的解决办法

冲突的产生

很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。

而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。

git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。

树冲突

文件名修改造成的冲突，称为树冲突。

比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。

$ git status
    added by us :    b.c
    both deleted :   origin -name.c
    added by them :  a.c

如果最终确定用b.c，那么解决办法如下：

git  rm a.c
git  rm origin -name.c
git add b.c
git commit

执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。

 

树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。

最后执行git commit提交即可。

内容冲突的解决办法

发现冲突

一般来讲，出现冲突时都会有“CONFLICT”字样：

$ git pull
Auto -merging  test.txt
CONFLICT (content) : Merge conflict  in  test.txt
Automatic merge failed; fix conflicts  and  then commit the result.

 

但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：

error : project mini /sample

注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。

 

这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：

git rebase remote -branch -name

冲突解决的一般过程

merge/patch的冲突解决

先编辑冲突，然后git commit提交。

注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。

rebase的冲突解决

rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。

解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：

git add  -u

注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。

 

然后执行下面命令继续rebase：

git rebase  -- continue

有冲突继续解决，重复这这些步骤，直到rebase完成。

 

如果中间遇到某个补丁不需要应用，可以用下面命令忽略：

git rebase  --skip

 

如果想回到rebase执行之前的状态，可以执行：

git rebase  --abort

 

注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。

编辑冲突的方法

直接编辑冲突文件

冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：

a123
<< << << < HEAD
b789
== == == =
b45678910
>> >> >> ]] >   6853e5ff961e684d3a6c02d4d06183b5ff330dcc
c

其中：冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。

此时，还没有任何其它垃圾文件产生。

 

最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

---

.gitignore

.gitignore 只能作用于untracked Files。

如果一些文件比如xxx.log以前被提交了。现在想git不要提交xxx.log，应该这样做：

git rm --cached logs/xx.log

然后更新  .gitignore 忽略掉目标文件，最后 

git commit -m "We really don't want Git to track this anymore!"

git有个类似功能命令： git update-index

不过git update-index的真正用意不是用于ignore文件。

git update-index --assume-unchanged 的真正用法是这样的：

1. 你正在修改一个巨大的文件，你先对其 git update-index --assume-unchanged，这样 Git 暂时不会理睬你对文件做的修改；
2. 当你的工作告一段落决定可以提交的时候，重置改标识：git update-index --no-assume-unchanged，于是 Git 只需要做一次更新，这是完全可以接受的了；
3. 提交＋推送。

用git update-index的方法替代.gitignore会产生下面的问题：

     1、所有的团队成员都必须对目标文件执行： git update-index --assume-unchanged <PATH> 。这是因为即使你让 Git 假装看不见目标文件的改变，但文件本身还是在 Git 的历史记录里的，所以团队的每个人在 fetch 的时候都会拉到目标文件的变更。（但实际上目标文件是根本不想被 Git 记录的，而不是假装看不见它发生了改变）

     2、一旦有人改变目标文件之后没有  git update-index --assume-unchanged <PATH>  就直接 push了，那么接下来所有拉取了最新代码的成员必须重新执行 update-index，否则 Git 又会开始记录目标文件的变化。