git - 你推送每一个提交吗？

Question

我想，如果有人可以给我更多关于使用 git 和远程存储库的详细信息。我还没有使用过远程存储库。

向本地存储库提交较小的更改，这些更改可能不会太震撼世界。什么被推送到远程存储库？每个本地提交？还是已经完成的整体工作，然后与其他人的整体工作合并？如果每个人都推送每个提交，我认为远程存储库的日志一定会令人困惑。

Answer 1

从远程存储库推送和拉取并不像本地提交那么重要。通常每天推拉几次就足够了。就像@earlonrails 所说，更频繁的推送意味着发生冲突更改的可能性更小，但通常这没什么大不了的。

这样想，通过提交到本地存储库，您基本上是在说“我信任此代码。它是完整的。它可以运行。我已经对其进行了测试。我准备好让其他人看到它。” 如果您想在每次提交后推送到远程存储库，那很好，但只要您定期执行，这并不重要。

本地存储库是关于跟踪您的更改以保护您所做的工作。远程存储库用于将工作分发给您的所有队友并跟踪每个人的更改。您的队友需要访问您的代码，但通常并不紧急，可以等到一天结束或您想要推动的时候。

Answer 2

您可以在方便时推送到远程。一次推送一堆提交的唯一问题是您可能需要将更多冲突与更多受影响的文件合并。如果你是 git 新手，我推荐git ready。

遥控器就像本地仓库一样工作，但你必须与他人相处融洽。如果其他人在您推送之前推送到远程。然后，您必须先拉动他们的更改，然后才能推动。如果你们都触摸同一个文件，因为他们的更改首先出现，您需要将这两个更改合并在一起。

Answer 3

我尝试尽可能推送每个本地提交（我使用 Git）。我很少在本地有 2 个或更多提交。否则，存在冲突的风险，解决起来并不那么愉快。

我更喜欢使用变基而不是合并，以保持历史更加线性。如果我在本地有 2 次提交 A 和 B（B 较旧），并且 B 与即将发生的更改发生冲突，则在解决 rebase 上的冲突后，我必须检查 B，检查编译，也许运行测试，然后才切换到 A 并推送所有.

这就是为什么我更喜欢尽快推动我拥有的一切。请注意，这些问题主要出现在与其他几个人处理大型代码库时。

Answer 4

我通常不同意最佳答案和一些评论。提交和推送都不必对代码的质量负责。

在svn时代，每个人都在同一个分支工作。您的代码中的故障很快就会传播给其他人。在这种情况下，你肯定要保证你的代码质量，这就是为什么在许多公司和组织中 svn 被 git 取代的原因。

我们需要弄清楚什么是典型的 Git 工作流程。假设你的 master 分支有一个可行的软件版本。有些人喜欢将 master 分支用作发布分支，而另一些人则将其用作开发分支。不要紧。每当您需要添加功能或修复错误时，您都可以从主（或另一个）分支创建一个分支。该功能应该足够小，可以在不涉及对代码库进行大量修改的情况下进行处理。如果修改较大，应创建多层分支，使分支的最后一层足够小。

如果每个分支都添加一个小功能，那么在同一个分支中工作的可能性不大。如果不止一个人在开发一个功能，那么该团队应该非常小并且经常交流，因此应该很容易解决冲突。如果一个提交或推送有问题，那么只有你或你的小团队会有问题。

那么我们应该在哪里保证代码的质量。我的回答是拉取请求。在 Github 中，您修改代码并提交拉取请求。在您提交拉取请求时，您需要保证您的代码可以编译并通过测试。在 Gitlab 中，您在修改代码之前创建一个合并请求，但使用 WIP 标记（正在进行中）。然后你修改代码。在移除 WIP 标记之前，您需要保证您的代码质量良好。此外，代码审查员将是另一层保护。

冲突应该很少发生在您的分支中，但是当您将分支合并到基础分支时可能会发生冲突。您应该在合并发生之前修复它。

唯一的事情与变基有关。许多开发人员喜欢在提交合并冲突之前重新调整他们的分支，以使 git 提交历史看起来更好。如果你推送到远程并且其他人使用了你的代码，rebase 会导致令人讨厌的问题得到修复。但是，如果您总是在只修复一个小功能的分支上工作，那么无论如何都不会有人想要使用您的分支。另外，我个人不太喜欢变基，因为它会修改历史。

所以我的结论和其他人类似，经常提交，经常推送，但原因不同。