在我们开始查看具体用例之前，以下是提交信息的快速说明。有一个很好的创建、提交和坚持的指南，使用Git更容易与他人合作。Git 该项目提供了一份文件，列出了许多提交补丁的创建提示 — 你可以在文件中 Git 在源代码中读取。Documentation/SubmittingPatches

首先，您的提交不应包含任何空间错误。Git 检查这个问题提供了一个简单的方法 — 运行前提交 ，它可以识别可能的空间错误并为您列出它们。git diff --check 如果该命令在提交前运行，则可以判断是否要提交，这可能会惹恼其他开发人员。

接下来，试着在逻辑上使每个提交都是一个单独的变更集。如果可以的话，试着让你的变化易于消化——不要在五个不同的问题上为整个周末编写代码，然后在周一大规模提交。即使你在周末不提交，你也可以使用周一的临时存储区域将工作分成至少一个问题，每个提交都有一个有用的信息。如果修改了相同的文件，请尝试使用 暂存文件(详细介绍交互式暂存)。无论您执行一次提交还是五次提交，分支顶部的项目快照都是相同的，只要在某个时刻添加了所有更改，因此，当您的开发人员必须查看您的更改时，请尝试使其他开发人员更容易。git add --patch

这种方法还可以在将来需要时更容易地拉出或恢复变更集。重写历史记录描述了许多有用的东西 Git 该技能用于重写历史记录和交互式暂存文件 — 用这些工具帮助制作干净易懂的历史记录，然后把工作发给别人。

最后要记住的是提交信息。养成高质量提交信息的习惯，使用与合作 Git 变得更容易。作为一般规则，您的邮件不得超过约定 50 一行字符的开头，简明扼要地描述变更集，然后空行，再详细描述。Git 项目需要更详细的解释，包括你对变化的动机，并将其实现与以前的行为进行比较 — 这是一个很好的遵循标准。写下你的提交信息：修复错误，而不是修复错误或修复错误。

你可能遇到的最简单的设置是一个私人项目，包括一两个其他开发人员。在这种情况下，私有意味着闭源——外部世界无法访问。您和其他开发人员都有权推送访问存储库。

在这种环境下，您可以遵循类似的使用方法 Subversion 或者其他集中系统可能执行的工作流。您仍然可以获得离线提交和更简单的分支和合并，但工作流程可能非常相似；主要区别在于合并在客户端而不是服务器上。让我们看看两个开发人员开始使用共享存储时会是什么样子。第一个开发人员 John 克隆仓库，变更，并在当地提交。在这些例子中，为了缩短它们，已经替换了协议消息。…

# John's Machine $ git clone john@githost:simplegit.git Cloning into 'simplegit'... ... $ cd simplegit/ $ vim lib/simplegit.rb $ git commit -am 'Remove invalid default value' [master 738ee87] Remove invalid default value  1 files changed, 1 insertions( ), 1 deletions(-) 

第二个开发人员Jessica做同样的事 —— 克隆存储库并提交更改：

# Jessica's Machine $ git clone jessica@githost:simplegit.git Cloning into 'simplegit'... ...$ cd simplegit/
$ vim TODO
$ git commit -am 'Add reset task'
[master fbff5bc] Add reset task
 1 files changed, 1 insertions(+), 0 deletions(-)

现在，Jessica 将她的工作推送到服务器，这工作正常：

# Jessica's Machine
$ git push origin master
...
To jessica@githost:simplegit.git
   1edee6b..fbff5bc  master -> master

在下一个方案中，你将查看较大专用组中的参与者角色。您将学习如何在小组协作处理功能的环境中工作，之后这些基于团队的贡献将由另一方集成。

假设 John 和 Jessica 正在合作开发一个功能（称为“featureA”），而 Jessica 和第三个开发人员 Josie 正在开发第二个功能（例如“featureB”）。在这种情况下，公司正在使用一种集成管理器工作流，其中各个组的工作仅由某些工程师集成，并且主存储库的分支只能由这些工程师更新。在此方案中，所有工作都在基于团队的分支中完成，并由集成商稍后完成。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 共享她的工作，因此她将分支提交推送到服务器。Jessica 没有推送对分支的访问权限 - 只有集成商有 - 所以她必须推送到另一个分支才能与 John 合作：featureAmaster

$ git push -u origin featureA
...
To jessica@githost:simplegit.git
 * [new branch]      featureA -> featureA

杰西卡给约翰发了电子邮件，告诉他她已经把一些工作推到了一个名为的分支上，他现在可以看看了。在等待约翰的反馈时，杰西卡决定开始与乔茜合作。首先，她启动了一个新的功能分支，基于服务器的分支：featureAfeatureBmaster

# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch 'featureB'

现在，Jessica 在分支上做了几个提交：featureB

$ vim lib/simplegit.rb
$ git commit -am 'Make ls-tree function recursive'
[featureB e5b0fdc] Make 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 的存储库现在如下所示： 她准备推动自己的工作，但收到Josie的电子邮件，说一个具有初始“featureB”工作的分支已经作为分支推送到服务器。Jessica 需要将这些更改与她自己的更改合并，然后才能将工作推送到服务器。杰西卡首先获取乔西的变化：featureBeegit fetch

$ git fetch origin
...
From jessica@githost:simplegit
 * [new branch]      featureBee -> origin/featureBee

假设Jessica仍在她签出的分支中，她现在可以将Josie的工作合并到该分支中：featureBgit merge

$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by the 'recursive' strategy.
 lib/simplegit.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

在这一点上，Jessica希望将所有这些合并的“featureB”工作推送回服务器，但她不想简单地推送自己的分支。相反，由于Josie已经开始了上游分支，Jessica希望推动该分支，她这样做：featureBfeatureBee

$ git push -u origin featureB:featureBee
...
To jessica@githost:simplegit.git
   fba9af8..cd685d1  featureB -> featureBee

这称为引用规范。请参阅 Refspec，更详细地讨论 Git refspecs 以及您可以使用它们执行的不同操作。还要注意旗帜;这是 的缩写，它配置了分支以便以后更容易地推拉。-u–set-upstream

突然，杰西卡收到了约翰的电子邮件，约翰告诉她，他已经对他们正在合作的分支进行了一些更改，他要求杰西卡看看它们。同样，Jessica运行了一个简单的程序，从服务器获取所有新内容，当然包括（当然）John的最新作品：featureAgit fetch

$ git fetch origin
...
From jessica@githost:simplegit
   3300904..aad881d  featureA   -> origin/featureA

Jessica 可以通过将新获取的分支的内容与同一分支的本地副本进行比较来显示 John 新工作的日志：featureA

$ git log featureA..origin/featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <xq.com>
Date:   Fri May 29 19:57:33 2021 -0700

Increase log output to 30 from 25

如果Jessica喜欢她所看到的，她可以将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 可能希望对所有合并的内容进行一些小的更改，以便她可以自由地进行这些更改，将它们提交到她的本地分支，并将最终结果推送回服务器：featureA

$ git commit -am 'Add small tweak to merged content'
[featureA 774b3ed] Add small tweak to merged content
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
...
To jessica@githost:simplegit.git
   3300904..774b3ed  featureA -> featureA

Jessica 的提交历史记录现在如下所示： 在某个时候，Jessica、Josie 和 John 通知集成商，服务器上的 和 分支已准备好集成到主线中。在集成商将这些分支合并到主线之后，获取将关闭新的合并提交，使历史记录如下所示：featureAfeatureBee 许多组切换到 Git 是因为这种能力让多个团队并行工作，在流程后期合并不同的工作线。团队中较小的子组能够通过远程分支进行协作，而不必涉及或阻碍整个团队，这是Git的一个巨大优势。您在此处看到的工作流的顺序如下所示：

为公共项目做出贡献有点不同。因为你没有权限直接更新项目的分支，所以你必须以其他方式将工作交给维护者。第一个示例描述了在支持轻松分叉的 Git 主机上通过分叉来贡献。许多托管网站都支持这一点（包括GitHub，BitBucket，repo.or.cz 等），许多项目维护者都希望这种贡献。下一节将介绍那些喜欢通过电子邮件接受贡献补丁的项目。

首先，您可能希望克隆主存储库，为您计划贡献的补丁或补丁系列创建主题分支，并在那里完成工作。序列基本上看起来像这样：

$ git clone <url>
$ cd project
$ git checkout -b featureA
  ... work ...
$ git commit
  ... work ...
$ git commit

当你的分支工作完成，你准备把它贡献给维护者时，转到原始项目页面，点击“Fork”按钮，创建你自己的项目可写分支。然后，您需要将此存储库 URL 添加为本地存储库的新远程站点;在这个例子中，我们称之为：myfork

$ git remote add myfork <url>

然后，您需要将新工作推送到此存储库。最简单的方法是将您正在处理的主题分支推送到分叉存储库，而不是将该工作合并到您的分支中并推送它。原因是，如果您的工作未被接受或被精心挑选，则不必倒带您的分支（Git操作在重新定基和挑选工作流中有更详细的介绍）。如果维护者，或者你的工作，你最终会通过从他们的存储库中提取它来找回它。mastermastercherry-pickmergerebasecherry-pick

无论如何，您都可以通过以下方式推送您的工作：

$ git push -u myfork featureA

一旦你的工作被推送到你的仓库，你需要通知原始项目的维护者，你有希望他们合并的工作。这通常被称为拉取请求，您通常通过网站生成此类请求 - GitHub有自己的“拉取请求”机制，我们将在GitHub中介绍 - 或者您可以运行命令并手动将后续输出通过电子邮件发送给项目维护者。git request-pull

该命令获取要将主题分支拉入的基本分支以及希望它们从中拉取的 Git 存储库 URL，并生成您要求提取的所有更改的摘要。例如，如果 Jessica 想要向 John 发送拉取请求，并且她已在刚刚推送的主题分支上完成了两次提交，则可以运行以下命令：git request-pull

$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
Jessica Smith (1):
        Create new function

are available in the git repository at:

  git://githost/simplegit.git featureA

Jessica Smith (2):
      Add limit to log function
      Increase log output to 30 from 25

 lib/simplegit.rb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

这个输出可以发送给维护者——它告诉他们工作是从哪里分支过来的，总结了提交，并确定了新工作要从哪里拉出来。

在你不是维护者的项目中，通常更容易让一个分支像总是跟踪一样，并在主题分支中完成你的工作，如果它们被拒绝，你可以很容易地丢弃它们。将工作主题隔离到主题分支中，如果主存储库的提示在此期间移动并且您的提交不再干净地应用，也可以使您更轻松地重新确定工作的基础。例如，如果您想向项目提交第二个工作主题，请不要继续处理您刚刚推送的主题分支 - 从主存储库的分支重新开始：masterorigin/mastermaster

$ git checkout -b featureB origin/master
  ... work ...
$ git commit
$ git push myfork featureB
$ git request-pull origin/master myfork
  ... email generated request pull to maintainer ...
$ git fetch origin

现在，您的每个主题都包含在一个孤岛中 - 类似于补丁队列 - 您可以重写，变基和修改，而不会相互干扰或相互依赖主题，如下所示： 假设项目维护者已经拉入了一堆其他补丁并尝试了你的第一个分支，但它不再干净地合并。在这种情况下，您可以尝试在 之上重定该分支的基态，为维护者解决冲突，然后重新提交更改：origin/master

$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA

这会将您的历史记录重写为现在看起来像在 featureA 工作之后提交历史记录。 由于您重新设置了分支的基数，因此必须指定 to push 命令，以便能够将服务器上的分支替换为不是其后代的提交。另一种方法是将此新工作推送到服务器上的其他分支（可能称为 ）。-ffeatureAfeatureAv2

让我们再看一个可能的场景：维护者已经看过你第二个分支中的工作，并且喜欢这个概念，但希望你改变一个实现细节。您还将借此机会将工作移动到基于工程的当前分支。您基于当前分支启动一个新分支，压缩那里的更改，解决任何冲突，进行更改，然后将其作为新分支推送：masterorigin/masterfeatureB

$ git checkout -b featureBv2 origin/master
$ git merge --squash featureB
  ... change implementation ...
$ git commit
$ git push myfork featureBv2

该选项将合并分支上的所有工作并将它们压缩到一个变更集中，生成存储库状态，就好像发生了真正的合并一样，而无需实际进行合并提交。这意味着您未来的提交将只有一个父级，并允许您从另一个分支引入所有更改，然后在记录新提交之前进行更多更改。此外，该选项对于在默认合并过程中延迟合并提交也很有用。–squash–no-commit

此时，您可以通知维护者您已经进行了请求的更改，并且他们可以在您的分支中找到这些更改。featureBv2

许多项目已经建立了接受补丁的程序 - 您需要检查每个项目的特定规则，因为它们会有所不同。由于有几个较旧的，较大的项目通过开发人员邮件列表接受补丁，因此我们现在将介绍一个示例。

该工作流程与前面的用例类似 — 您可以为处理的每个补丁系列创建主题分支。不同之处在于您如何将它们提交到项目中。您不必分叉项目并推送到您自己的可写版本，而是生成每个提交系列的电子邮件版本，并通过电子邮件将它们发送到开发人员邮件列表：

$ git checkout -b topicA
  ... work ...
$ git commit
  ... work ...
$ git commit

现在，您有两个要发送到邮件列表的提交。您用于生成可以通过电子邮件发送到列表的 mbox 格式的文件 — 它将每个提交转换为一封电子邮件，其中提交消息的第一行作为主题，消息的其余部分加上提交引入的修补程序作为正文。这样做的好处是，从生成的电子邮件中应用补丁可以正确保存所有提交信息。git format-patchformat-patch

$ git format-patch -M origin/master
0001-add-limit-to-log-function.patch
0002-increase-log-output-to-30-from-25.patch

在本节中，我们介绍了多个工作流，并讨论了作为封闭源代码项目小团队的一部分与为大型公共项目做出贡献之间的差异。您知道在提交之前检查空格错误，并且可以编写出色的提交消息。您学习了如何格式化补丁，以及如何通过电子邮件将其发送到开发人员邮件列表。在不同工作流的上下文中也介绍了合并的处理。您现在已经做好了在任何项目上进行协作的准备。

接下来，您将看到如何解决硬币的另一面：维护Git项目。您将学习如何成为一个仁慈的独裁者或整合经理。