git 你推动每一个提交吗？

Do you push every single commit?

提问by rynd

I would like, if someone could give me more detail in working with git and remote repositories. I haven't worked with remote repositories, yet.

我想，如果有人能给我更多关于使用 git 和远程存储库的细节。我还没有使用过远程存储库。

To the local repository you commit smaller changes that may not be too world-shattering. What is pushed to the remote repository? Every local commit? Or the overall-work that was done, which is then merged with overall-works of others? I think the log of the remote repository must be confusing, if everyone pushes every commit.

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

采纳答案by acattle

Pushing and Pulling from the remote repository isn't quite as important as your local commits. Typically pushing and pulling a few times a day is sufficient. Like @earlonrails said, more frequent pushes means less likelihood of conflicting changes but typically it isn't that big a deal.

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

Think of it this way, by committing to your local repository you are basically saying "I trust this code. It is complete. It runs. I have tested it. I am ready for other people to see it." If you want to push to the remote repository after every commit, that's fine but as long as you do it on a regular basis it doesn't really matter.

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

Local repositories are about tracking your changes to protect the work you do. Remote repositories are for distributing the work to all your teammates and tracking everyone's changes. Your teammates need access to your code, but usually it isn't urgent and can wait until the end of the day or whenever you feel like pushing.

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

回答by earlonrails

You can push to remote at your convenience. The only problem with pushing a bunch of commits at one time is that you may need to merge more conflicts with more affected files. If you are new to git I recommend git ready.

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

Remotes work just like the local repo, but you have to play nice with others. If other people push to remote before you push. Then their changes will have to be pulled by you before you can push. If you both touch the same file, since their change was in first you will need to merge the two changes together.

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

回答by Dmitry Pavlenko

I try to push every local commit as it is possible (I use Git). Rarely I have 2 or more commits locally. Otherwise, there's a risk of conflict that are not so pleasant to solve.

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

I prefer to use rebase rather than merge, to keep the history more linear. If I have 2 commits A and B (B is older) locally, and B conflicts with upcoming changes, after resolving coflicts on rebase I have to checkout B, check compilation, maybe run tests, and only then switch to A and push that all.

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

That's why I prefer to push everything I have as soon as possble.

这就是为什么我更喜欢尽快推动我拥有的一切。

回答by Yifan Sun

I generally disagree with the best answer and some comments. Neither commits nor push has to be responsible for the quality of the code.

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

In the svn age, everyone works in the same branch. Failure in your code soon propagates to others. In this case, you definitely have to guarantee your quality of code, and that is the reason why svn is being replaced by git in many companies and organizations.

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

We need to make clear what is a typical Git workflow. Suppose your master branch has a somehow workable version of the software. Some people prefer to use the master branch as release branch, while others use it as the development branch. It does not matter. Whenever you need to add a feature or fix a bug, you create a branch from the master (or another) branch. The feature should be small enough to be handled without involving extensive modification to the codebase. In case of large modification, layers of branches should be created, so that the last layer of the branch is small enough.

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

If each branch is to add a small feature, it is not very likely to have many people working in the same branch. If more than one people working on one feature, that group should be very small and communicate very often, and hence, conflict should be easily fixed. If one commit or a push has a problem, only you or your small team will have a problem.

如果每个分支都添加一个小功能，那么在同一个分支中工作的人就不太可能了。如果不止一个人在做一个功能，那么这个团队应该很小并且经常交流，因此冲突应该很容易解决。如果一次提交或推送有问题，只有您或您的小团队会遇到问题。

Then where we should guarantee the quality of the code. My answer is the pull requests. In Github, you modify the code and submit a pull request. By the time you submit the pull request, you need to guarantee that your code can compile and pass the tests. In Gitlab, you create a merge request before you modify the code, but mark with WIP (work in progress). Then you modify the code. Before you remove the WIP mark, you need to guarantee that your code is of good quality. Also, the code reviewer will be another layer of protection.

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

Conflicts should rarely happen in your branch, but it can happen when you merge your branch to the base branch. You should fix it right before that merge happens.

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

The only thing is related to rebase. Many developers like to rebase their branch before submitting a merge conflict to make the git commit history looks better. If you pushed to the remote and others used your code, rebase causes nasty problems to fix. However, if you always work on a branch that only fixes a small feature, no one should want to use your branch anyway. Also, I personally do not really like rebasing as it modifies the history.

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

So my conclusion is similar to others, commit often and push often, but for a different reason.

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