git log 指定版本（git log -l）



http://blog.csdn.net/pipisorry/article/details/

分支的意义

        创建分支可以避免提交代码后对主分支的影响，同时也使你有了相对独立的开发环境。

        假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

分支管理使用基本命令

创建并切换到新分支

git checkout -b new_branch

新建分支

git branch new_branch

查看当前分支

git branch

查看所有分支

git branch -a

切换到master分支

(dev): git checkout master

Note: 切换分支后你会发现本地文件会变化，如果dev分支和master文件不同的话。再cheout回来就又可以看到之前分支的文件了。不过git2.0以上好像都看得到文件。

在dev分支中时，可以通过git pull origin master将master分支上的文件下载到本地当前分支中。
合并分支到当前分支

$(master): git merge dev

合并分支的操作是从new_branch合并到master分支(这时master的内容就变成了dev的内容)，当前环境在master分支。
删除分支

git branch -d

皮皮Blog

Git里默认分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

每次提交，master分支都会向前移动一步。

当创建并进入新的分支dev时

$git checkout -b dev    #这时是看不到master中的内容，如果想同步master内容到dev，需要使用git merge master

Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向！

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如在dev上的工作完成了，就可以把dev合并到master上。最简单的方法，就是直接把master指向dev的当前提交：

$git checkout master     #到master中来时，本地看不到修改的文件及内容

$git merge dev      #这样master分支和dev分支的内容一样了

git merge命令用于合并指定分支到当前分支。直接使用git merge的合并是“快进模式”Fast-forward，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，其它merge策略可参考后面的分支merge策略。

合并完成后，就可以放心地删除dev分支了：

删除后，查看branch，就只剩下master分支了：$ git branch     #输出* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

[创建与合并分支]

git merge --no-ff dev

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

建议使用 git merge --no-ff，这样无论如何都会产生一个新的 merge commit。然后你 git show <merge-commit-sha1> 就可以看到这次 merge 的所有改动。

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

首先，仍然创建并切换dev分支：

修改readme.txt文件，并提交一个新的commit：

现在，我们切换回master：

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

可以看到，不使用Fast forward模式，merge后就像这样：

Git Rebase

合并多次提交git rebase

当你提交你的代码进行审核并创建一个pull request时(在开源项目中常常发生这样的情况)，你经常会在代码被采纳前，要求修改一些代码。你进行了一些修改，而在下一次审核中，又会被要求进行另外的修改。你不知道还有多少次修改等着你，在你知道以前，你进行了多次额外的提交。理想的状态是，你可以使用rebase命令，把他们都合并成一次提交。
git rebase -i HEAD~[number_of_commits]
如果你希望合并最后两次提交，您需要以下命令
git rebase -i HEAD~2
使用该命令，你会进入一个交互式的界面，显示了最后两次提交，并且询问你要压缩哪些。理想状态是你pick最近的一次提交并把它和之前的提交squash。

接下来你会被要求为合并后的这次提交填写描述信息。这一个过程实际上重写了你的提交历史。

[彻底搞懂 Git-Rebase]

git merge –squash

–squash：使用squash方式合并，把多次分支commit历史压缩为一次

git merge –squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用–squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

[git merge 将多个commit合并为一条之--squash 选项]

减少commit/更容易找到回滚点的策略

Note: 需要注意的一点是，无论是git merge dev还是git merge --no-ff dev，在master分支上都能看到dev上提交的所有commit，这样在master上直接找上一个回滚点也是很烦。需要使用

$git log --graph --pretty=oneline --abbrev-commit

这个来查询commit历史，更容易找出master上的commit。[Git版本控制：Git查阅、撤销文件修改和撤销文件追踪]

或者使用上面的git merge --spuash减少dev上的commit数。

实际开发中分支管理的几个基本原则

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

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

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

所以，团队合作的分支看起来就像这样：

[分支管理策略]

皮皮Blog

Github推出了“可以写保护的分支”，对多人协作的项目非常有用：不得删除、不得强行推送、只有测试全部通过才接受PR

[About protected branches]

from:Git版本控制：Git分支处理_git 保护分支_-柚子皮-的博客-CSDN博客

ref:learnGitBranching-demo

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/bcyy/16363.html