写在最前:鉴于我写的两篇文章,git相关的大家比较喜欢,那我就先写一点这方面的... ,老实说我的git水平只能算初学者,只是用的了三年没深入钻研,还停留在使用SourceTree和偶尔使用命令行的阶段.
Why
既然你们这么多强迫症喜欢简洁明了的git提交记录,那么我就给你们
-
给你们看个极端点的提交例子
-
我也没想到公司里竟然有人提交出这么多分枝来,这个确实太夸张了!
image.png 嗯,其实至少这个提交应当是可以精简的. 当然这个也不完美,但是真正干活儿的时候,也不是特别在乎了. 我也没法完全要求所有人都一样.
image.png -
- 怎么出现这样情况的?
- git作为协作的版本控制系统,假设你和你的同伴在本地中分别有各自的新提交,而你的同伴先于你 push 了代码到远程分支上,那么你必须先执行 git pull 来获取同伴的提交,然后才能 push 自己的提交到远程分支.而按照 Git 的默认策略,如果远程分支和本地分支之间的提交线图有分叉的话（即不是 fast-forwarded）,Git 会执行一次 merge 操作,因此产生一次没意义的提交记录,从而造成了像上图那样的混乱.
- 我们一般用SoruceTree或者命令行中的git pull
- 那么实际上 git pull = git fetch; git merge origin/master; 这两条命令
- 我们期望的情况,如果整洁点:
git pull --rebase = git fetch; git rebase origin/master; (其实讲到这里如果你一个字一个字看的,应该就够了,不过如果没好好看,或者git命令不熟.那么可以继续看下面)
- PS: 老实说我个人使用感觉,两个情况各有各的好处. 本质上没有高下之分,请根据实际情况自行决定
What
-
介绍两个定义: git merge 和 git rebase
- git merge
git_merge.gif
-
git rebase
git_rebase.gif
How
- 一句话,用git pull的时候: git pull --rebase
- 用SourceTree:
-
修改配置:
-
image.pngimage.png
-
-
在每次拉取的时候,注意根据实际情况选择这个地方
image.png
-
How Good
- 反正就是干净了.别弄太乱大家都舒心.
- 但是也别弄太夸张,保留提交记录和分支结构还是有用的,我个人意见是自己看着来
- 情况1: 如果你不是单开分支进行功能开发,而只是想更新本地代码到最新,那么毫无疑问用git rebase
- 情况2: 相反你是本地开发,而且对git和整个项目逻辑不是十分了解,那么你老老实实用git merge
- 情况3: 你明确知道自己在干什么,而且确定这次提交不会带来太大冲突,可以用git rebase
- 情况4: 要真的玩砸了~ 呃,别来找我.. 去找你们团队里的明白人,应该能很快解决问题
再再次提醒: rebase是危险行为,建议你足够熟悉了git在这么做. ennn~ 要是有洁癖,才考虑用吧!
最后还是附上思维导图[3.9MB]
image.png
