使用这些Git协作策略可以使您的团队更高效地工作。Git非常适合管理软件开发进度的小型团队，但您可以通过多种方式提高工作效率。我发现了许多对我的团队有帮助的最佳实践，尤其是当不同Git级别的新人加入时。在您的团队中正式制定Git约定，每个人都应遵循分支命名、标记和编码。每个组织都有自己的规范或最佳实践，网上可以免费获得很多建议，但尽早选择正确的规范并在团队中遵循它们很重要。同时，不同团队成员的Git水平参差不齐。您需要创建和维护一组基本指令，这些指令符合团队执行常见Git操作的规范。正确合并更改每个团队成员都需要在单独的功能分支上进行开发。但是即使有单独的分支，每个人都会修改一些公共文件。将更改合并回master分支时，合并通常不会自动发生。可能需要手动解决不同人对同一文件的不同更改之间的冲突。这就是为什么您必须学习如何处理Git合并的原因。现代编辑器具有帮助解决Git合并冲突的功能。它们为同一文件的每个部分提供了多种合并选项，例如是保留您的更改，还是保留另一个分支的更改，或者保留它们。如果您的编辑器不支持这些功能，可能是时候切换到代码编辑器了。经常对你的功能分支进行变基当你继续开发你的功能分支时，经常对它进行变基：rebasemaster。这意味着经常执行以下步骤：gitcheckoutmastergitpullgitcheckoutfeature-xyz#Assumedfeaturebranchnamegitrebasemaster#Mayneedtoresolvemergeconflictsonfeature-xyz这些步骤在你的功能分支上重写历史（这不是一个坏事）。首先，它使您的功能分支获取当前在master分支上的所有更新。其次，您在功能分支上的所有提交都将在该分支的历史记录之上重写，因此它们会按顺序出现在日志中。您可能需要一路解决合并冲突，这可能是一个挑战。然而，这是解决冲突的最佳时机，因为它只影响你的特性分支。解决所有冲突并进行回归测试后，如果您准备好将功能分支合并回主分支，请在多次执行上述变基步骤后进行合并：gitcheckoutmastergitpullgitmergefeature-xyzinmeantime，如果其他人也将与你的冲突的更改推送给master，那么Git合并将再次发生冲突。您需要修复它们并重新运行回归测试。还有其他的合并哲学（例如，只使用合并而不使用变基来防止重写历史），其中一些甚至可能更简单、更容易使用。但是，我发现上述方法是一种简洁可靠的策略。提交历史日志将按有意义的功能序列排列。如果使用“纯合并”策略（如上所述，没有定期变基），那么master分支的历史将穿插所有同时开发的功能的提交。如此混乱的历史，难以追溯。确切的提交时间通常并不那么重要。最好有一个易于查看的历史日志。在合并之前压缩提交当您在功能分支上进行开发时，即使是很小的更改也可以算作一次提交。然而，如果每个功能分支产生五十次提交，那么随着新功能的添加，主分支中的提交数量最终会不必要地膨胀。一般来说，每个特性分支应该只添加一个或几个commit到master。为此，您需要将多个提交压缩为一个或多个具有更详细信息的提交。通常使用如下命令完成：gitrebase-iHEAD~20#查看二十个可以squashed的commit执行该命令时，会弹出commit列表的编辑器，可以选择pick或者squashincludeEditit几种方法，包括壁球。“选择”一个提交意味着保留该提交。“压缩”一个提交就是将该提交合并到前一个提交中。使用这些方法，您可以将多个提交合并为一个提交，对其进行编辑和清理。这也是清理不重要的提交信息（例如，有错别字的提交）的机会。综上，保留所有commit相关操作，但在合并到master分支之前，合并编辑相关信息，明确意图。小心不要在rebase过程中意外删除提交。执行完rebasing等操作后，再次查看git日志，做最后修改：gitcommit--amend最后，由于改写了分支的Git提交历史，必须强制更新远程分支：gitpush-f使用标签当您完成测试并准备好将软件从master分支部署到现场时，或者由于某种原因您希望将当前状态保留为里程碑时，创建一个Git标签。对于已经积累了一些变化和相应提交的分支，标签是该分支在那个时刻的快照。标签可以被认为是没有历史记录的分支，或者是直接指向创建标签之前的提交的命名指针。所谓“配置控制”，就是保存代码在不同里程碑的状态。大多数项目都要求能够在以前的里程碑处复制软件源代码，以便在需要时可以重建它们。Git标签为每个代码里程碑提供了唯一的标识符。标签很简单：gittagmilestone-id-m"shortmessagesayingwhatthismilestoneisabout"gitpush--tags#不要忘记显式推送标签到远程考虑软件版本对应的情况GittaghasDistributedtoacustomer,客户反映有问题。尽管存储库中的代码可能一直在继续开发，但很多时候需要回退到Git标签对应的代码状态，才能准确重现客户问题，以便进行修复。有时新代码可能已经解决了这个问题，但并非总是如此。通常你需要切换到一个特定的标签并从该标签创建一个分支：gitcheckoutmilestone-id#切换到分发给客户的标签gitcheckout-bnew-branch-name#创建新的分支以重现错误另外，考虑使用AnnotatedMarkup和SignedMarkup如果它们对您的项目有帮助的话。让软件在运行时打印标签在大多数嵌入式项目中，从代码版本构建的二进制文件都有一个固定的名称，因此无法从其名称推断出相应的Git标签。在构建时“嵌入标签”有助于将未来发现的问题与特定构建精确关联。标签可以在构建过程中自动嵌入。通常，gitdescribe生成的标签字符串会在代码编译之前插入到代码中，这样生成的可执行文件在启动时就可以输出标签字符串。当客户报告问题时，您可以指示他们将启动的输出发送给您。总结Git是一个复杂的工具，需要时间来掌握。使用这些实践可以帮助团队成功地使用Git进行协作，无论他们的知识水平如何。
