git 团队中最佳实践_使用Git的团队的6种最佳实践

git 团队中最佳实践

Git对于帮助小型团队管理他们的软件开发过程非常有用，但是有一些方法可以使它更加有效。 我发现了许多对我的团队有帮助的最佳实践，尤其是当新的团队成员加入了不同水平的Git专业知识时。

为您的团队正式制定Git约定

每个人都应遵守分支命名，标记和编码的标准约定。 每个组织都有标准或最佳实践，许多建议可从Internet上免费获得。 重要的是尽早选择合适的约定并以团队的形式遵循。

而且，不同的团队成员在Git上将具有不同的专业知识水平。 您应该创建并维护一组基本的说明，以执行遵循项目约定的常见Git操作。

正确合并更改

每个团队成员应在单独的功能分支上工作。 但是，即使使用了单独的分支，每个人最终都会修改一些通用文件。 将更改合并回master分支时，合并通常不会自动进行。 为了调和两位作者对同一文件所做的不同更改，可能需要人工干预。 这是您必须学习处理Git合并技术的地方。

现代编辑器具有帮助Git合并冲突的功能 。 它们指示文件的每个部分中合并的各种选项，例如是否保留更改，另一个分支的更改或同时保留两者。 如果您的代码编辑器不支持这种功能，可能是时候选择其他代码编辑器了。

经常重新建立功能分支

当您继续开发功能分支时，请经常根据master分支对其进行重新设置。 这意味着要定期执行以下步骤：

   
   

    
    
 
     
     git checkout master
     
     


     
     git pull 
     
     


     
     git checkout feature-xyz  
     
     # name of your hypothetical feature branch 
     
     


     
     git rebase master  
     
     # may need to fix merge conflicts in feature-xyz 
    
    
   
   

这些步骤会在功能分支中重写历史记录 （这不是一件坏事）。 首先，它使您的功能分支看起来像master并进行了所有更新以达到master要求。 然后，您对功能分支的所有提交都会在顶部重放，因此它们会顺序出现在Git日志中。 您可能会在一路上遇到需要解决的合并冲突，这可能是一个挑战。 但是，这是处理合并冲突的最佳方法，因为它只会影响功能分支。

解决所有冲突并进行回归测试之后，如果准备好将功能部件合并回master ，请再执行一次上述变基步骤，然后执行合并：

   
   

    
    
 
     
     git checkout master
     
     


     
     git pull 
     
     


     
     git merge feature-xyz
    
    
   
   

在此期间，如果其他人推动更改以master与您的冲突，则Git合并将再次发生冲突。 您需要解决它们并重复进行回归测试。

还有其他合并哲学（例如，无需重新定级，而仅使用合并以避免重写历史记录），其中一些甚至可能更易于使用。 但是，我发现上述方法是一种干净可靠的策略。 提交历史记录作为有意义的功能序列堆叠在一起。

master分支将散布着同时开发的所有功能中的提交。 如此复杂的历史很难回顾。 确切的提交时间通常并不那么重要。 最好有一个更易于查看的历史记录。

壁球在合并之前提交

在您的功能分支上工作时，可以为较小的更改添加提交。 但是，如果每个功能分支产生50次提交，则在添加功能时， master分支中的最终提交数量可能会不必要地增加。 通常，每个功能分支中只应添加一个或几个提交到master 。 为了实现这一目标， 壁球多次提交到一个或提交的与每一个更详细的消息屈指可数。 通常使用以下命令来完成此操作：

 git rebase -i HEAD~ 20  # look at up to 20 commits to consider squashing 

执行此操作后，会弹出一个编辑器，其中列出了一系列提交，您可以通过多种方式对其进行操作，包括pick或squash 。 选择一个提交意味着保留该提交消息。 压榨意味着将该提交的消息合并到先前的提交中。 使用这些选项和其他选项，您可以将提交消息合并为一个，并进行一些编辑和清除。 这也是摆脱不重要的提交消息的机会（例如，有关修正错字的提交消息）。

总之，保留所有与提交相关联的操作，但在合并到master之前，合并并编辑关联的消息文本以提高清晰度。 在变基过程中不要无意中删除提交。

执行完这样的变基之后，我想最后一次查看git log以进行最终编辑：

 git commit --amend 

最后，由于已重写了该分支的Git提交历史记录，因此有必要强制对远程功能分支进行更新：

 git push -f 

使用标签

完成测试并准备从master分支部署软件后，或者如果出于其他任何原因想要将当前状态保留为重要的里程碑，则请创建Git标签。 分支积累与提交相对应的更改历史记录时，标签是该时刻分支状态的快照。 可以将标签视为无历史记录的分支，也可以将其视为指向创建标签之前特定提交的命名指针。

配置控制是关于在各个里程碑保留代码状态。 能够复制任何里程碑的软件源代码，以便在大多数项目中都可以在需要时进行重建。 Git标签为此类代码里程碑提供了唯一的标识符。 标记很简单：

   
   

    
    
 
     
     git tag milestone-id 
     
     -m 
     
     "short message saying what this milestone is about" 
     
     


     
     git push 
     
     --tags   
     
     # don't forget to explicitly push the tag to the remote 
    
    
   
   

考虑一种方案，其中与给定Git标签相对应的软件已分发给客户，并且客户报告了问题。 尽管存储库中的代码可能会继续发展，但通常需要回到与Git标签相对应的代码状态，以准确地再现客户问题以创建错误修复程序。 有时，较新的代码可能已经解决了该问题，但并非总是如此。 通常，您需要签出特定标签并从该标签创建分支：

   
   

    
    
 
     
     git checkout milestone-id        
     
     # checkout the tag that was distributed to the customer 
     
     


     
     git checkout 
     
     -b new-branch-name  
     
     # create new branch to reproduce the bug 
    
    
   
   

除此之外，如果它们对您的项目有益，请考虑使用带注释的标记和带符号的标记。

使软件可执行打印标签

在大多数嵌入式项目中，从软件版本创建的结果二进制文件具有固定名称。 不能从其文件名推断与该软件二进制文件相对应的Git标签。 在构建时将标签“嵌入标签”以将任何将来的问题精确地关联到给定的构建是很有用的。 可以在构建过程中自动嵌入标签。 通常，在代码编译之前，将git describe generate的标记字符串插入到代码中，以便生成的可执行文件将在启动时打印标记字符串。 当客户报告问题时，可以指导他们向您发送引导输出的副本。

结论

Git是一个复杂的工具，需要花费一些时间来掌握。 无论他们的专业知识水平如何，使用这些实践都可以帮助团队使用Git成功进行协作。

翻译自: https://opensource.com/article/20/7/git-best-practices

git 团队中最佳实践