向一个项目贡献
在接下来的情形中，你会看到大型私有团队中贡献者的角色。 在你将学习到的这种工作环境 中，小组基于特性进行协作，这些团队的贡献将会由其他人整合。
让我们假设 John 与 Jessica 在一个特性上工作，同时 Jessica 与 Josie 在第二个特性上工 作。 在本例中，公司使用了一种整合-管理者工作流程，独立小组的工作只能被特定的工程师 整合，主仓库的 master 分支只能被那些工程师更新。 在这种情况下，所有的工作都是在基 于团队的分支上完成的并且稍后会被整合者拉到一起。
因为 Jessica 在两个特性上工作，并且平行地与两个不同的开发者协作，让我们跟随她的工作 流程。 假设她已经克隆了仓库，首先决定在 featureA 上工作。 她为那个特性创建了一个新 分支然后在那做了一些工作：
# Jessica's Machine
$ git checkout -b featureA
Switched to a new branch 'featureA'
$ vim lib/simplegit.rb
$ git commit -am 'add limit to log function' [featureA 3300904] add limit to log function 1 files changed, 1 insertions(+), 1 deletions(-)
在这个时候，她需要将工作共享给 John，所以她推送了 featureA 分支的提交到服务器上。
Jessica 没有 master 分支的推送权限 - 只有整合者有 - 所以为了与 John 协作必须推送另一 个分支。
$ git push -u origin featureA ...
To jessica@githost:simplegit.git
* [new branch] featureA -> featureA
Jessica 向 John 发邮件告诉他已经推送了一些工作到 featureA 分支现在可以看一看。 当她 等待 John 的反馈时，Jessica 决定与 Josie 开始在 featureB 上工作。 为了开始工作，她基 于服务器的 master 分支开始了一个新分支。
# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master Switched to a new branch 'featureB'
向一个项目贡献
$ vim lib/simplegit.rb
$ git commit -am 'made the ls-tree function recursive' [featureB e5b0fdc] made the ls-tree function recursive 1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files' [featureB 8512791] add ls-files
1 files changed, 5 insertions(+), 0 deletions(-)
Jessica 的仓库看起来像这样：
Figure 10. Jessica 的初始提交历史
她准备好推送工作了，但是一封来自 Josie 的邮件告知一些初始工作已经被推送到服务器上的
featureBee 上了。 Jessica 在能推送到服务器前首先需要将那些改动与她自己的合并。 然后
她可以通过 git fetch 抓取 Josie 的改动：
$ git fetch origin ...
From jessica@githost:simplegit
* [new branch] featureBee -> origin/featureBee
Jessica 现在可以通过 git merge 将其合并到她做的工作中：
$ git merge origin/featureBee Auto-merging lib/simplegit.rb Merge made by recursive.
lib/simplegit.rb | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
有点儿问题 - 她需要将在 featureB 分支上合并的工作推送到服务器上的 featureBee 分支。
她可以通过指定本地分支加上冒号（:）加上远程分支给 git push 命令来这样做：
向一个项目贡献
$ git push -u origin featureB:featureBee ...
To jessica@githost:simplegit.git
fba9af8..cd685d1 featureB -> featureBee
这称作一个 引用规格。 查看 [_refspec] 了解关于 Git 引用规格与通过它们可以做的不同的事 情的详细讨论。 也要注意 -u 标记；这是 --set-upstream 的简写，该标记会为之后轻松地 推送与拉取配置分支。
紧接着，John 发邮件给 Jessica 说他已经推送了一些改动到 featureA 分支并要求她去验证 它们。 她运行一个 git fetch 来拉取下那些改动：
$ git fetch origin ...
From jessica@githost:simplegit
3300904..aad881d featureA -> origin/featureA
然后，通过 git log 她可以看到哪些发生了改变：
$ git log featureA..origin/featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 Author: John Smith <[email protected]>
Date: Fri May 29 19:57:33 2009 -0700
changed log output to 30 from 25
最终，她合并 John 的工作到她自己的 featureA 分支：
$ git checkout featureA Switched to branch 'featureA'
$ git merge origin/featureA Updating 3300904..aad881d Fast forward
lib/simplegit.rb | 10 +++++++++-1 files changed, 9 insertions(+), 1 deletions(-)
Jessica 想要轻微调整一些东西，所以她再次提交然后将其推送回服务器：
向一个项目贡献
Jessica 的提交历史现在看起来像这样：
Figure 11. 在一个特性分支提交后 Jessica 的历史
Jessica、Josie 与 John 通知整合者在服务器上的 featureA 与 featureBee 分支准备好整合 到主线中了。 在整合者合并这些分支到主线后，一次抓取会拿下来一个新的合并提交，使历 史看起来像这样：
Figure 12. 合并了 Jessica 的两个特性分支后她的历史
许多团队切换到 Git 是因为这一允许多个团队并行工作、并在之后合并不同工作的能力。 团 队中更小一些的子小组可以通过远程分支协作而不必影响或妨碍整个团队的能力是 Git 的一个 巨大优势。 在这儿看到的工作流程顺序类似这样：
向一个项目贡献
Figure 13. 这种管理团队工作流程的基本顺序