Git学习(2)

git分支的创建，切换和删除，可以迅速完成，相比较与其它版本控制系统。

分支的创建与合并

在git里面，有个分支叫主分支，即master分支。HEAD指向master，master指向提交，所以HEAD指向的就是当前分支。一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点。

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上。Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！之后对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动，而master指针不变。

在dev分支上的工作完成之后，就可以把dev合并到master上，可以直接把master指向dev的当前提交，即可完成合并。合并之后就可以删除dev分支，即删除dev指针。

git checkout -b dev     //     创建并切换至dev分支

git branch dev
git checkout dev      //   这2个命令结合起来就是上面的命令

git branch              //   列出所有分支，当前分支前面标*号

git merge dev            //         把dev分支的工作成果合并到master分支上

//  git merge用于合并指定分支到当前分支，默认是Fast-forward合并，这是快进模式，合并速度很快

git branch -d dev            //合并完之后进行删除dev分支

解决冲突

当在分支上的修改进行提交后，返回主分支又进行不一样的修改准备提交时，git试图把各自的修改合并起来，这样系统回告知发生冲突，这时必须手动解决冲突。可以使用git status查看发生冲突的文件，然后直接查看冲突的文件（文件里会标识出不同分支的内容），手动修改文件之后，再提交，会提示冲突解决了。

git status    //查看工作区的状态，在这里可以查看冲突的文件
git log --graph --pretty=oneline --abbrev-commit    //查看分支的合并情况
git branch -d feature1    //删除分支

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

git merge --no-ff -m "merge with no-ff" dev    //禁用fast forward的合并模式

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Bug分支

当开发中出现bug时，对于每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后删除临时分支。

但是如果目前dev分支上还有未提交的工作时（可以通过git status命令查看），可以使用git提供的stash功能，把当前工作现场存储起来，等恢复现场后继续工作。

git stash

然后确定在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

git checkout master                 //切换分支
git checkout -b issue-101            //创建分支并切换至新分支

然后修复bug，进行提交

git add readme.txt
git commit -m "fix bug 101"

修复之后，切换至master分支，并完成合并，最后删除issue-101分支

git checkout master
git merge --no-ff -m "merged bug fix 101" issue-101

然后回到dev分支，并查看状态

git checkout dev
git status

发现工作区是干净的，之前保存的工作现场呢？可以通过 git stash list查看下

git stash list

 发现工作现场还在，只是被存在某个地方，要恢复有2种方式：

（1）

git stash apply           //恢复
git stash drop            //删除stash内容

（2）

git stash pop                 //恢复的同时把stash内容也删了

再次调用  git stash  list查看就看不到任何内容了。

当然也可以多次stash，恢复的时候先用        git stash list查看，然后恢复指定的stash

git stash apply stash@{0}

Feature分支

软件开发中，当添加新功能时，可以新建一个feature分支，在上面开发，完成后合并，最后删除该feature分支。

git checkout -b feature-vulcan
git add vulcan.py
git commit -m "add feature vulcan"

切回dev分支，准备合并：

git checkout dev

如果一切顺利，feature分支和bug分支是类似的，合并然后删除。

但是如果因为某种原因必须取消分支，这个时候采用强行删除操作

git branch -D feature-vulcan    //丢弃一个没有被合并的分支，可以通过 -D参数强行删除

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

git remote           //查看远程库的信息
git remote -v        //查看更详细的远程信息，可以查看fetch和push的地址

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

git push origin master

推送其它分支

git push origin dev

并不是一定要把本地分支都推送到远程

• master分支是主分支，因此要时刻与远程同步；

• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

现在在自己电脑上的另一个目录下克隆，模仿同组的小伙伴

git clone git@github.com:michaelliao/learngit.git

可以使用 git init来初始化，然后执行 git branch查看分支，只看到master分支

如果要在dev分支上开发，必须创建远程origin的dev分支到本地，于是用这个命令创建本地dev分支：

git checkout -b dev origin/dev

于是，可以在dev分支上继续修改，然后把dev分支push到远程

git add env.txt
git commit -m "add env"
git push origin dev

这就模仿你的小伙伴提交了

回到你自己原来的目录，对同样的文件进行修改，并试图推送

git add env.txt
git commit -m "add new env"
git push origin dev

执行最后的push时，会提示发生推送失败，因为你的小伙伴的提交和你试图进行的提交有冲突，我们可以先用 git pull把最新的提交从origin/dev上抓下来，然后在本地合并，解决冲突，再推送。

git pull

如果git pull也失败，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

git branch --set-upstream-to=origin/dev dev

再次 git pull，成功，但是合并有冲突，需要手动解决，与之前的冲突解决一样，解决后，提交，再push

git commit -m "fix env conflict"
git push origin dev

因此，多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

 

git rebase    //把本地未push的分叉提交历史整理成直线