写在最前:鉴于我写的两篇文章,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.png
      image.png

  • 在每次拉取的时候,注意根据实际情况选择这个地方

    
    
    image.png

How Good

• 反正就是干净了.别弄太乱大家都舒心.
• 但是也别弄太夸张,保留提交记录和分支结构还是有用的,我个人意见是自己看着来
  • 情况1: 如果你不是单开分支进行功能开发,而只是想更新本地代码到最新,那么毫无疑问用git rebase
  • 情况2: 相反你是本地开发,而且对git和整个项目逻辑不是十分了解,那么你老老实实用git merge
  • 情况3: 你明确知道自己在干什么,而且确定这次提交不会带来太大冲突,可以用git rebase
  • 情况4: 要真的玩砸了~ 呃,别来找我.. 去找你们团队里的明白人,应该能很快解决问题
• 再再次提醒: rebase是危险行为,建议你足够熟悉了git在这么做. ennn~ 要是有洁癖,才考虑用吧!

最后还是附上思维导图[3.9MB]

image.png