文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

这篇帖子的目的读者是初学者,我假设你已经了解关于Git的基本使用(包括commit,push,pull等命令的使用)。

你或许知道怎么将Git运用到日常基本工作中,但是仅仅知道commit、push、pull这些是不能满足软件开发的。

不管你是使用GitHub、Bitbucket、GitLab还是Stash,都要知道一个事实:你必须遵循代码复审的过程以保证您的代码符合最基本的质量标准。

这张帖子将快速引导你如何在项目中运用"开源"工作流。顾名思义,这个工作流一样被运用在大量开源项目中。

第 1 段(可获 1.49 积分)

这种工作流的好处是使得您的工作与其他人完全隔离开来,并减少生产环境中的错误。

但是,朋友:使用最适合你们团队的东西吧,这个过程是允许一些变化的,只要他们能够提高你们团队的生产力。

在"分支"上工作

Git允许您在“分支“上工作,根据git官方文档

"分支"意味着您可以稍微偏离开发主线,继续工作而不干扰主线。

简而言之,"分支"将您当前的工作代码和您队友的分离开来,它有点类似于"平行空间"或者时间轴这样的概念。

第 2 段(可获 1.43 积分)

主线指的是您的master分支(主代码),看看每条分支是如何与主代码分离的,直到达到某一个点:

创建一个新的分支,您只需要使用 git checkout -b <branch_name> 命令:

$ (master) git checkout -b my_new_branch
> Switched to a new branch 'my_new_branch'

一旦创建了一个新的分支,它的工作流是相同的。提交您修改的代码并push(推送)到您的代码库(但不是master分支):

[...] some commits [...]
$ (my_new_branch) git push origin my_new_branch

以上命令告诉git:"嘿,小伙子,上传我本地的工作代码(即提交)到远程(源)同样的分支 my_new_branch 上,如果没有 my_new_branch 分支,请创建它。“如果您想把您的代码上传到远程不同分支上(不是 my_new_branch 分支),使用如下命令即可:

第 3 段(可获 1.65 积分)
$ (my_new_branch) git push origin my_new_branch:my_branch_on_remote

好了,回归正轨。现在退回 master 分支(或者其它分支),您只需要使用不带 -b 参数的 checkout 命令:

$ (my_new_branch) git checkout master
> Switched to branch ‘master’
$ (master) git checkout my_new_branch
> Switched to branch ‘my_new_branch’

您可以和多个人在同一个分支上工作,但是不推荐那样做。保持一人一个分支,即使自己代码弄乱了也不用担心会影响其他人的工作(举个例子,比如在写需要暂时中断部分应用程序的代码时)。

第 4 段(可获 0.98 积分)

但是总有一天您需要将您分支的新特性整合到master上对吗?

代码审查

相对于立刻把您的分支合并到master上,软件开发中一个更好的做法是,在这之前先将您的新代码发给团队其他成员进行检查。

这有利于提高您应用的代码质量,因为更多人将会看到它,也有利于在它进入生产环境之前早点发现改进之处甚至一些细微的问题。

对于初学者来说,这是一种从资深开发者那里学习新东西的极佳方式。

但是如何让别人检查您的代码呢?是叫他们拉取您的分支并亲自检查每一次提交吗?那是不可能的!

第 5 段(可获 1.45 积分)

大多数(如果不是全部)Git 的在线仓库托管服务都有一个友好的特性,使得代码审查变得非常容易。

拉取请求(Pull Requests)

一个拉取请求(在 GitLab 被叫做合并请求)可以被定义成:

拉取请求的作用是告诉其他人你已经推送了一些代码的修改到Github仓库上。一旦拉取请求发出,感兴趣的团体可以对这一系列代码的修改进行审查,讨论潜在的修改,必要时,甚至推送后续的提交。

来源:GitHub help: Using pull requests

这基本上是一种让你的团队成员在 web 界面审查你的代码分支的方式。这种方式允许他们评论这些即将合并至 master 分支的代码。

第 6 段(可获 1.55 积分)

一个对同一分支上的变化进行评论的例子

您可以在 https://help.github.com/articles/using-pull-requests/(链接同上文) 学习如何创建和维持一个拉取请求,每种服务都遵循相同的模式,所以也就没什么神秘的了。

即使在打开了一个请求之后,您仍然可以将新的提交推送到您的分支上。您可以通过那种方式获取之前关于您代码的检验,并且在别人检查您已经上传的代码的同时继续对其它部分产生影响。

同时,朋友:记得在请求队友检查之前先检查您自己所拉取的请求,您将会发现很多您之前没有注意到的细节(样式问题,排版等等),并且让您的同事专注于真正重要的东西。

但是,您的代码不在master主分支上对吗?Hold住,我们马上接触到这个问题!

第 7 段(可获 1.79 积分)

重构/修复材料

如果你的队友想要对你的代码进行合理的修改,你必须做这件事(为了代码质量),让我们一起看看经常出现的一种情景:对已经提交的代码添加新的修改。

那么,这是你的示例文件:file_a.example (呵呵,故意这样排版的):

[...]

some_cool_function

some_coler_function

[...]

这是您的提交历史(最新的提交排在前面):

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog
第 8 段(可获 0.85 积分)

有人指出你的some_coler_function函数在名称上有排印错误,现在您必须修正它。

您更新那个文件并提交修复,现在这里是您新的提交历史:

f7f3f6d create file_a class and methods
310154e improve SomeOtherClass code
a5f4a0d update changelog
a412dbb fix typo on file_a

但是朋友,你正在修复刚刚添加到这次(确切的说,是第一次提交)拉取请求中的一些代码...在一次提交中上传创建并修复好的file_a文件会更好点,不是吗?

Git就是这样一个奇妙的工具,它有一个杀手锏允许我们改变之前已经的提交,我们称之为:git交互式重建。

第 9 段(可获 1.28 积分)

所以我们需要合并第一次提交(f7f3f6d 和最后一次提交 a412dbb)。这时候我们就需要用到交互式重建工具了。

$ (some_branch) git rebase -i origin/master

origin/master 参数是我们的起始点。 这基本就是告诉git:“hey, 我们想基于origin/master最后一次提交来重新确定我们当前的分支的起始点!”

你也能使用参数HEAD~4,它的工作机制是:“hey,我们想从当前分支的倒数第4个提交开始重新确定当前分支的起始点”。 查看官方文档,里面有更多细节。

当你执行了上述命令,你的屏幕里会出现如下内容:

pick f7f3f6d create file_a class and methods
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog
pick a412dbb fix typo on file_a
# Rebase 710f0f8..a412dbb onto 710f0f8
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
第 10 段(可获 1.24 积分)

现在我们只需要敲入如下命令!我们想合并提交f7f3f6d和a412dbb。我们将历史纪录重新排下序,如下:

pick f7f3f6d create file_a class and methods
pick a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

让我们将a412dbb提交上的pick标签改成fixup(或者f), 以告诉git:“hey,我们想把这段代码和上面那段合并”:

pick f7f3f6d create file_a class and methods
fixup a412dbb fix typo on file_a
pick 310154e improve SomeOtherClass code
pick a5f4a0d update changelog

保存你的文件!新的提交历史如下:

b7c3f33 create file_a class and methods
1b24ae9 improve SomeOtherClass code
d5ffad3 updates changelog

(当然,由于历史的重写,所以提交的哈希值也会改变)。

想知道其他的类似于将一个提交分割成几个不同的提交等等疯狂的历史操作,请参考GIT官方文档

提醒: 绝不要重写公共分支的提交历史(例如master)。这将彻底地弄混你的团队成员的工作。

最后,我们应该...

第 11 段(可获 1.61 积分)

整合你的代码

团队通常建立最小数量的审查以完成一个拉取请求的合并。一旦你的代码获取了足够多的关注,那就指定一个人去合并它们吧! 你也可以自己去合并这些代码,但是对于一个团队来说这是不必要的。

这就是它!你的代码现在在你的主分支,准备投入到生产吧。

现在,想必你已经明白如何去使用这一被全世界成千上万软件开发团队使用的工作流了!

使用这个工作流,将避免“人们互相踩到脚趾”的情况,也能保证用最少的开发者将代码投入到生产。

如果你的团队没用使用这个模式进行开发,建议你们团队做些改变。因为这种模式的好处是清晰明了的,而且实现这种模式基本不需要花多少力气。

Happy gitting!

第 12 段(可获 1.86 积分)

文章评论