了解Git（第2部分）－为团队贡献

了解Git（第1部分）-像我五岁一样解释它
→ 了解Git（第2部分）—为团队做出贡献
理解Git（第3部分）—解决冲突（敬请期待！）

实际上，每个大型软件公司和开源项目都使用某种类型的“版本控制”来跟踪随时间的变化。版本控制可以帮助您协调团队合作并查找软件错误。

Git是当今最受欢迎的版本控制系统之一。如果您还不熟悉，请参阅本系列的第1部分中的“像我五岁一样解释”介绍。

本指南涵盖了如何使用git为团队做出贡献-无论是在办公室还是在开源社区中的在线-都是针对初学者的。它将解释从创意到请求请求的整个流程。

第一次描述时，任何术语都会以粗体突出显示。请随时在官方git词汇表或参考指南中查找这些术语以获取更多详细信息。

从树干开始

Git使用了很多“树”类比，因此请做好准备。您可以将您的主要代码库视为树的树干 ????

每次您添加更多更改（又称为commits ）时，您的树就会长得更高，更直。即使删除代码，这仍然被视为更改，并且会导致树增大。就像文本编辑器中的“撤消”历史记录如何保存击键（包括退格键）一样。

默认情况下，Git呼叫中继master 。您可以随心所欲地调用它。除了“ master ”一词外，没有什么特别的。

您可以通过检出特定的“检查点”（如第1部分中所述）在树干上上下移动（相当于在时间上向前和向后移动）。

分支出来

大多数项目积压了要添加的新功能和要修复的错误。当您要解决这些问题之一时，一种方法是将树长高并直接提交到树干（ master ）。这对于小型项目或您是唯一进行更改的项目非常有效，但是如果多个人同时工作怎么办？互相妨碍并最终产生冲突是很容易的。

解决方案是分支。您无需创建主干，而创建自己的个人分支（例如， my-cool-feature而不是master ），然后从那里开始工作。现在，您要使树枝更高而不是树干更高。

可视化分支时，通常将它们横向绘制以节省空间。想象一下，下面是一棵丑陋的树，树梢倾斜，树根在左边。每个圆圈都是一次提交。每个圆圈越靠右，它提交的越晚：

有一个蓝色的树干和一个绿色的树枝。每个提交都有多个提交，从左到右按时间顺序显示。您的分支从提交T2开始。当您在分支机构上工作（提交B1和B2 ）时，其他人直接在主干上工作（提交T3和T4 ）。这些提交还不在您的分支中；您的分支机构已过时，您将很快阅读。

同样，请参阅本系列的第1部分以了解branch和commit命令，或者如果需要更多的可视化效果，请参阅免费的git书。您还可以在GitHub上查看现实生活中的分支可视化，或者在终端中键入git log --all --decorate --oneline --graph 。

提交更改

现在，您可以在分支上进行更改，但最终目标是将它们作为“正式”代码库的一部分重新放回主干。

测试变更后，您需要与团队共享。通常，您将通过请求请求 （PR）或合并请求 （MR）进行操作-它们是同一回事，该术语仅取决于您使用的软件（例如GitHub / Bitbucket / GitLab）。您要求将更改合并并合并 。从现在开始，我将这些称为PR。

有些人对进行首次公关感到不安（我当然做到了），但这确实没什么可担心的。即使代码需要一些工作才能被接受，大多数团队还是乐于收到新的PR。 PR是开源生态系统的重要组成部分。

这是有关如何提交公关的详细说明，以及有关公关礼节的一些建议。对于希望开始为开源做出贡献但不知道从何开始的人们，甚至还有一个“ 仅限初学者 ”社区。

要记住的主要内容是对为什么要进行更改以提供上下文的明确说明。

讨论和修订

提交您的PR后，团队中的其他人将需要仔细检查并留下反馈。他们可以对特定的代码行提出问题并发表评论，或者可以提供有关更改的更一般的反馈。在某些情况下，他们可能会将自己的更改直接推送到您的分支机构，但是通常他们会要求您自己进行更改。

如果您想根据反馈进行更改，只需将更多的提交添加到您现有的分支中，然后再次将其推送到origin分支即可。 PR将自动更新以反映您的更改。

保持最新

如果在接受您的PR之前经过了一段时间，它可能会“过时”，这意味着它基于较旧版本的主干（如前面所示的树）。您的更改可能在一周前生效，但不能保证它们仍然可以与其他更新的主干一起使用。

要了解最新信息，您有两种选择：

您可以使用git merge master “ 合并 ”更改。这将在您的工作中应用中继中的所有新更改。
你可以在“ 之上底垫中使用的变化” git rebase master 。这会将您的工作重新应用到中继上的任何新更改之上。

无论哪种情况，您自己的更改都将保持不变–实际上，您只是将分支移到主干的顶部，以与最新代码保持同步。

不同的团队可能更喜欢一种方法。如果不确定，通常merge起来比较安全。

处理冲突

合并或重新定基时，有时会遇到冲突。这意味着您更改了其他人也更改过的代码行，而git不知道保留哪个版本。

发生这种情况时，许多人会感到恐慌。 git的输出看起来真的很讨厌，带有奇怪的>>>>>>> ======= <<<<<<<符号，您可能会认为您已经破坏了整个过程。不用担心看起来很奇怪，但是经过一点练习，您就会理解它。

这里有太多的方法要介绍，但是请查阅本文以了解冲突如何起作用以及如何解决它们。我还计划在本系列的第3部分中着重处理冲突。

本质上，您只需要删除这些怪异的符号并手动组合它们之间的代码即可。

例如，该行：

print "Hello"

可能会在两个单独的分支上进行更改，从而导致冲突：

>>>>>>>
print "Hello, world"
=======
print "Hello!"
<<<<<<<

解决后的结果可能变为：

print "Hello, world!"

手动将冲突的行合并在一起后，保留分别添加的“世界” 和 “！”。

接受您的更改

解决了所有PR注释并解决了所有冲突后，即可合并您的分支！

代码库的管理员可以通过将分支合并到主干中来接受PR（仅通过按GitHub上的按钮即可），从而使更改正式生效。

下面的Commit T5是一个“合并落实”，将绿色分支中的更改放入主干。

您已经做出了成功的贡献！ ????您可以在https://github.com/pulls查看您曾经提交的所有PR。

如果您觉得本指南有用，请通过多次按tap按钮来提供帮助，以便其他人也可以找到它。

感谢您的阅读，并继续关注第3部分。与此同时，请观看此简单的教程视频，然后解决一些First Timers问题！

From: https://hackernoon.com/understanding-git-2-81feb12b8b26