理解Git工作流

标签: 理解 git 工作流 | 发表时间:2011-08-05 17:34 | 作者:(author unknown) joyoner
出处:http://www.feedzshare.com

来自: 黑客志 - FeedzShare  
发布时间:2011年08月04日,  已有 2 人推荐


如果你不了解Git背后的设计初衷,那么你正处在危险境地,当然有很多参数可以强迫Git按照你的意愿行事,但这并不是Git被设计的工作方式,这就好比你可以把改锥当锤子使用,并且它也可以完成工作,但这对改锥没什么好处。

下面就让我们来看一个最常见的Git工作流是如何变得没法收拾的。

首先从Master创建一个新分支,在这个分支上完成你的工作,然后将它合并回Master分支。

大多数情况下这不会有什么问题,你都会得到你预期的结果,这是因为在你创建新分支之后,Master的代码已经发生了变化。但是有一天,你合并了一个新特性到Master,不过这次Master的代码并没有发生变化,所以同以往不同,这次Git直接将Master指向了你的特性分支上的最后一个Commit,也就是“fast forwards”(见图),而不是创建一个合并commit。

不幸的是,你的新特性分支可能会包含一些checkpoint commits,这些小的commit保证了你的工作不会意外丢失,但是也让你的代码进入了相对不稳定的状态,现在你已经无法从Master的稳定commit中区分这些不稳定的commit了,一旦需要回滚,你很容易就会陷入灾难之中。

当然你可以添加一条规则:“只要是合并新特性时,都必须使用-no-ff来强制生成一个新的commit。”这样问题就解决了,于是你继续往下走。

直到有一天你在Production发现了一个严重的bug,你需要追踪这个bug是何时被引入的,于是你试图通过bisect来找出答案,但却总是找到那些checkpoint commit,于是你放弃了,并开始手动检查。

最终你将Bug定位到了某个单独的文件上,你想通过blame来查看过去48小时这个文件发生的变化,但是你发现这是不可能的,因为blame报告这个文件已经有几个星期没人碰过了,事实证明blame报告的是你最初的commit,而不是合并时的,你的第一个checkpoint commit在几周之前改变了这个文件,但是这个改变直到今天才被合并进来。

-no-ff标识就这样神奇的破坏了bisect和blame,就像你将改锥当做锤子一样。

重新考虑版本控制

版本控制系统的出现是为了解决2个问题

第一个问题就是帮助你更好的编写代码,你需要同你的团队成员同步代码,并且备份你的工作,通过Email发送压缩文件明显不是个靠谱的办法。

第二个问题就是配置管理,这主要是针对并行开发的管理,比如你需要在开发下一个大版本的同时,继续修复当前production版本存在的bug,配置管理也可以用来查找变更,但是这对于诊断Bug用处不是很大。

通常来说,这两个目的是矛盾的。

当你为一个新特性开发原型时,你应该不断的添加checkpoint commit,尽管如此,这些commit通常会破坏测试。

在一个理想的世界中,你的版本历史中的每次变更都应该是简明并且稳定的,不应该有checkpoint commit这种东西来制造噪音,也不应该有巨无霸,比如10,000行代码的commit,干净的提交历史让你可以很容易的撤销变更,或是在分支之间使用cherry-pick,干净的提交历史也让后期的代码检查和分析变得更简单。尽管如此,维护一个干净的提交历史记录却意味着你需要等待一切都变得完美之后再进行提交。

那么我们应该选择哪种策略呢?经常性的提交,还是保证提交历史干净整洁?

如果你是在一个产品还未发布的2人创业公司工作,干净的提交历史对你带来的好处非常有限,你可以把所有的commit都扔到Master,并在任何你需要的时候进行部署。

然后随着变更的增加,以及团队规模或是你的用户基数的增长,你需要工具和技术来确保所有事情都是经过检查的,这通常包括自动化测试,代码检查,以及干净的提交历史。

特性分支看起来是个不错的选择,它们解决了最基本的并行开发问题,但是在你写代码的时候,你迟早会开始考虑最后的集成问题。

当你的项目变得足够大时,简单的分支/提交/合并策略就变得不再奏效了,作坊式的开发时代已经结束了,你需要一个干净的提交历史。

Git的革命性就在于它很好的同时解决了这2个问题,让你在分支上开发新特性时,可以随时提交你的任何变更,并且在随后合并时,你依然可以得到一个干净的提交历史,如果这是你想要的,那么你就应该遵从Git的默认设置。

Git工作流

考虑下这两种类型的分支:公共和私有

公共分支保存着这个项目的权威历史,在公共分支上,每个提交都应该是简明,原子的,并且提交信息应该准确表达变更,同事应该尽可能的保证提交是线性的,并且是永久的,公开的分支包含Master以及Release分支。

而私有分支是属于你自己的,它就相当于你解决问题时候用到的草纸。

将私有分支存在本地是最安全的,如果你需要在你的工作电话和家庭电脑之间同步,最好告诉你的同事你推送的是一个私有分支,以防止他们在这个分支上进行开发。

永远不要把你的私有分支直接合并到任何公共分支上,而应该先使用reset,rebase,squash merges或者commit amending这样的工具清理你的分支。

你可以把自己想象成一个作家,并且将每个commit看做是一本书的章节,作家不会发布第一版手稿,Michael Crichton说过,“好书不是写出来的——而是改出来的”。

如果你使用的是其它系统,你可能会觉得修改历史是不可能的,所有提交就像刻在了石头上一样,是不可改变的,按照这个逻辑,那我们就应该在文本编辑器中禁用撤销功能。

实用主义者一般会直到事情变得不可收拾之时才会注意到问题的存在,对于配置管理来说,我们关心的是全局的变更,checkpoint commit仅仅只是为了方便撤销而保存的缓冲而已。

如果你认为你的公共历史是干净的,那么fast-forward合并不仅很安全,而且很可取,他们保证版本历史是线性的并且非常容易追踪。

而-no-ff参数唯一的作用就是“文档”,有人或许会使用merge commit的消息来表示最后一次合并到production代码中的版本信息,但是这是不对的,你应该使用tag。

根据我修改的代码量,以及修改的时间跨度,还有这个分支偏离Master的程度,我设定了3中基本的工作流。

短期开发

大多数情况都是这样,我通过squash merge来完成清理工作。

假设我创建了一个特性分支,并在接下来的一个小时做了许多checkpoint 提交。

git checkout -b private_feature_branch
touch file1.txt
git add file1.txt
git commit -am “WIP”

在我完成我的工作之后,我会运行下面的命令来完成合并:

git checkout master
git merge –squash private_feature_branch
git commit -v

然后花上一分钟详细的写上这次变更的注释。

大改动

有时一个特性可能需要几天才能够完成,并且包含许多小的提交。

这时我认为我的改动将会被打碎成许多更小的改动,所以squash在这种情况下就拍不上用场了(作为我的一条经验法则,我会问自己”这样有利于代码检查吗?“)

如果我的checkpoint commit包含逻辑上的递增,我可以使用rebase的互动模式。

互动模式非常强大,你可以使用它来编辑老的commit,分割它们,重新排序,在某些情况下,你还可以压缩(squash)它们。

我会在特性分支上执行:

git rebase –interactive master

它会打开一个编辑器,每一行包含一个commit,有SHA1以及commit的message,并且每个commit后面还会跟随一个可以执行的命令列表。

默认情况,每个commit都使用‘pick’,这不会改变commit。

pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

我将这个操作改成了squash,这就会将第二个commit压缩到第一个commit中。

pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar

当我保存并关闭之后,会出现一个新的文本编辑器提示我为这些合并后的commit填写一个commit message,然后一切就绪。

废弃旧分支

如果我的特性分支已经存在了太久时间,并且我需要合并几个分支到我的特性分支以保证它是最新的,这样事情就变得错综复杂了,这时你可以很容易的获取原始的diff并创建一个干净的新分支。

git checkout master
git checkout -b cleaned_up_branch
git merge –squash private_feature_branch
git reset

现在我就有了一个新的分支,既有最近的Master上的commit,又有我上一个分支上的工作,现在我可以手动添加并提交我的变更了。

总结

如果你没有遵从Git的默认设置,那么你应该问问自己为什么?

你应该保证公共历史是永久的,原子的,并且易于追踪,而将私有分支看做是临时的,可丢弃的。

因此,理想的工作流应该是:

  1. 从一个公开分支创建一个似有分支。
  2. 经常新的在似有分支上提交你的工作
  3. 一旦你的代码已经完美了,那么清除它的历史
  4. 合并干净的分支到你的公共分支

特别感谢@joshaber以及@jbarnette提供反馈。

————–
本文翻译自”Understanding the Git Workflow”,作者:Benjamin Sandofsky,翻译:@yuanyiz

想和我们一道传播黑客精神?快来加入吧!

无觅猜您也喜欢:
Git 201: 就高了那么一点点
Github第一年教给我的10堂课
我的站立工作实验
GitHub:改变开发者的工作方式,让代码分享更简单
无觅

相关 [理解 git 工作流] 推荐:

理解Git工作流

- joyoner - FeedzShare
来自: 黑客志 - FeedzShare  . 发布时间:2011年08月04日,  已有 2 人推荐. 如果你不了解Git背后的设计初衷,那么你正处在危险境地,当然有很多参数可以强迫Git按照你的意愿行事,但这并不是Git被设计的工作方式,这就好比你可以把改锥当锤子使用,并且它也可以完成工作,但这对改锥没什么好处.

理解Git的工作流程

- - 博客 - 伯乐在线
如果你不理解Git的设计动机,那你就会处处碰壁. 知道足够多的命令和参数后,你就会强行让Git按你想的来工作,而不是按Git自己的方式来. 这就像把螺丝刀当锤子用;也能把活干完,但肯定干的差极了,花费很长时间,还会弄坏螺丝刀. 想想常见的Git工作流程是怎么失效的吧. 从Master创建一个分支,写代码,然后把这个分支合并回Master.

Git 工作流程 - 阮一峰的网络日志

- -
Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去. "工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡. 本文介绍三种广泛使用的工作流程:.

Git 分支管理策略与工作流程

- - IT瘾-dev
Git 是目前世界上最先进的分布式版本控制系统. 它使我们更方便的跟踪,管理和组织代码. 也帮助了我们更好的与其他开发者进行协作开发. 协作开发必须有一个规范来约束各个贡献者的行为. 这个规范就是 Git 工作流程(Git Workflow),也为我们规范各个分支管理策略等行为. Git 工作流程是有关如何使用 Git 以高效协作开发的规则或策略建议,下文这些常见工作流程只是作为指导参考,这些工作流不是一成不变的,我们应该根据自己的项目选择或制定合适自己的工作流.

Git基础

- Wolf - 潘魏增
上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来,希望对一些朋友有用. 如果之前没有接触过Git,wikipedia上面已经有非常好的介绍. pdf格式:http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式:http://panweizeng.com/download/git-basics-meituan.key.

Git-rebase 小筆記

- lepture - YORKXIN×YORKXIN
最近剛好有個機會整理很亂的 Git commit tree,終於搞懂了 rebase 的用法,筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢,但很多 branches 各自開發,總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們,可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ,甚至可以讓 merge 產生的線看起來比較簡單,不會有跨好幾十個 commits 的線.

Git 简明教程

- satoru - python.cn(jobs, news)
Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.

git架构图解

- - CSDN博客研发管理推荐文章
  最近又遇到Git了,发现网络上Git的资料确实不咋滴,难懂不全面. 至于Git是什么我就不多说了,相比svn上手确实更难. 与svn集中版本库相比较,Git被称作分布式版本库,在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树,那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息,而git只在根目录才有,这就决定了svn可以单独拉取某个子目录或者某个文件,而git需要全部拉取.

科普:Git Commit Guidelines

- - IT瘾-dev
降低Review成本,可以明确知道本次提交的改变和影响. 规范整个Team的提交习惯,对技术素养的养成有益. 可以通过统一工具,抽取规范的message自动形成change log. 目前Github的Angular项目,就是完全采用规范的Git Message来进行日常的提交管理和发布管理的,下面是这个项目的Commit记录,和自动根据commit生成的change log.