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
到此这篇git log 指定版本(git log -l)的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章,希望大家都能在编程的领域有一番成就!版权声明:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符,请将相关资料发送至xkadmin@xkablog.com进行投诉反馈,一经查实,立即处理!
转载请注明出处,原文链接:https://www.xkablog.com/bcyy/16363.html