我希望有人能给我更详细的工作方式，让我了解如何使用git和远程仓库。我还没有使用过远程仓库。
在本地仓库中，您可以提交一些较小的变更，这些变更可能并不太重要。那么推送到远程仓库的是什么？是每个本地提交吗？还是合并了其他人的完整工作后的总体工作？如果每个人都推送每个提交，那么远程仓库的日志会很混乱。
你是否会推送每一个提交？
65
- rynd
1
8使用远程仓库（如果不使用Git，则使用集中式仓库）的另一个重要优点是备份 - 以防本地存储受损。从备份角度来看，频繁地推送可以最小化潜在的数据丢失。 - David Airapetyan
4个回答
64
从远程仓库推送和拉取代码并不像你本地提交那样重要。通常每天推送和拉取几次就足够了。就像 @earlonrails 所说，更频繁的推送意味着冲突变化的可能性更小，但通常这并不是什么大事。
可以这样想，将代码提交到你的本地仓库就相当于在说：“我信任这个代码。它完整且可运行。我测试过了。我已经准备好让其他人看到它。” 如果你想在每次提交后都将代码推送到远程仓库，那么也是可以的，但只要你定期这样做就可以了，没有必要过于频繁。
本地仓库用于跟踪你的更改以保护你所做的工作。远程仓库用于将工作分发给所有团队成员并跟踪每个人的更改。你的团队成员需要访问你的代码，但通常不是非常紧急的，可以等到一天结束或你觉得可以推送时再进行。
- acattle
7
31我不同意你关于本地提交完整性的说法。我经常会在我的分支上本地进行正在进行的工作提交，或者临时提交，目的是在推送之前进行变基和清理（压缩、重新命名、重新排序等等）。在我看来，只有将代码推送到远程仓库才表达了对你所做的更改集的质量和最终性的承诺。 - void.pointer
17如果拥有本地代码库的开发计算机崩溃了，该怎么办？ - Michael Sync
在github出现之前的旧时代，我认为经常提交到版本控制是最佳实践。这也可以防止在开发者的笔记本电脑/机器崩溃时丢失代码。但是呀，自从开始使用git后，我不经常推送了。 - Michael Sync
3我强烈认为源代码控制系统应被视为“手段”，而非“目的”。它是一种工具，而非备份解决方案。我曾见过有人将他们的源代码控制系统当作实际备份解决方案，并提交代码，即使这些代码会导致整个软件崩溃，只因为“我想在周末之前备份我的代码”。此外，尝试阅读这种系统的提交历史是一场噩梦。 - Jerther
1@m.edmondson 不错。除非我所知道的是储藏处被存放在本地。 - Jerther
显示剩余2条评论
19
你可以在方便的时候推送到远程。一次性推送大量提交的唯一问题是可能需要合并更多受影响文件的冲突。如果您是 Git 新手，建议参考 git ready。
远程库与本地库完全一样，但必须要与他人协作。如果其他人在您之前推送到远程，则您在推送之前必须拉取他们的更改。如果您同时修改了同一个文件，因为他们的更改先更新，所以您需要将两个更改合并在一起。
远程库与本地库完全一样，但必须要与他人协作。如果其他人在您之前推送到远程，则您在推送之前必须拉取他们的更改。如果您同时修改了同一个文件，因为他们的更改先更新，所以您需要将两个更改合并在一起。
- earlonrails
2
2"你必须要与他人友好相处" - 我明白了，这就是这个主题的实质。很少有人对我所做的每一个小改变感兴趣。 - rynd
就此而言，我建议使用代码审查工具，如git diff、gitx和gitk。这里有一篇关于git代码审查工具的帖子。http://stackoverflow.com/questions/3713103/best-code-review-tool-for-git/10434975#10434975 - earlonrails
8
我尽可能将本地每个提交都推送（我使用Git）。很少情况下我会有2个或更多的本地提交。否则，存在一些不太愉快的冲突风险需要解决。
我喜欢使用rebase而不是merge，以保持历史线性。如果我有本地的2个提交A和B（B较旧），并且B与即将到来的更改冲突，在解决重复基底上的冲突后，我必须检出B，检查编译，可能运行测试，然后才能切换到A并推送所有内容。
这就是为什么我喜欢尽快推送我拥有的所有内容。请注意，这些问题在处理具有多个其他人的大型代码库时最常见。
我喜欢使用rebase而不是merge，以保持历史线性。如果我有本地的2个提交A和B（B较旧），并且B与即将到来的更改冲突，在解决重复基底上的冲突后，我必须检出B，检查编译，可能运行测试，然后才能切换到A并推送所有内容。
这就是为什么我喜欢尽快推送我拥有的所有内容。请注意，这些问题在处理具有多个其他人的大型代码库时最常见。
- Dmitry Pavlenko
2
你是否真的总是在与其他人一起工作的同一代码上工作，以至于只需要一个或两个提交就足以引入冲突，需要你来解决？ - Burhan Ali
1不是经常发生，但周期性地会出现这种情况（我不能说很频繁），这很令人恼火，所以我更喜欢避免它。90%的冲突都是由Java导入引起的。 - Dmitry Pavlenko
7
我不太同意最佳答案和一些评论。提交和推送都不必为代码质量负责。
在svn时代，每个人都在同一分支上工作。你的代码中的错误很快就会传播到其他人那里。在这种情况下，你必须确保你的代码质量，这就是为什么许多公司和组织正在使用git替换svn的原因。
我们需要明确typical Git workflow。假设你的master分支有一个可用的软件版本。有些人喜欢将master分支用作发布分支，而另一些人则将其用作开发分支。这并不重要。每当你需要添加一个功能或修复一个bug时，你就从master（或其他）分支创建一个分支。该功能应该足够小，可以在不涉及对代码库进行广泛修改的情况下处理。如果有大量的修改，应该创建分支层级，以便最后一层分支足够小。
如果每个分支都要添加一个小功能，就不太可能有很多人在同一个分支上工作。如果有多个人在一个功能上工作，那么该小组应该非常小，并且经常沟通，因此冲突应该很容易解决。如果一个提交或推送出现问题，只有你或你的小团队会有问题。
那么我们应该在哪里保证代码质量呢？我的答案是拉取请求。在Github中，你修改代码并提交一个pull request。在提交拉取请求时，你需要确保你的代码可以编译且能够通过测试。在Gitlab中，你需要在修改代码之前创建一个合并请求，并标记为WIP（work in progress）。然后你修改代码。在移除WIP标记之前，你需要确保你的代码质量良好。此外，代码评审人员将是另一层保护。
冲突应该很少发生在你的分支中，但当你将分支合并到基础分支中时可能会发生。你应该在合并之前立即解决它。
唯一与rebase相关的事情。许多开发人员喜欢在提交合并冲突之前对他们的分支进行rebase，以使git提交历史记录看起来更好。如果你向远程推送了代码并且其他人使用了你的代码，则rebase会造成麻烦的问题。然而，如果你总是在一个只修复小功能的分支上工作，那么没有人应该想使用你的分支。另外，我个人不太喜欢rebase，因为它修改了历史记录。
所以我的结论与其他人类似，经常提交和推送，但出于不同的原因。
在svn时代，每个人都在同一分支上工作。你的代码中的错误很快就会传播到其他人那里。在这种情况下，你必须确保你的代码质量，这就是为什么许多公司和组织正在使用git替换svn的原因。
我们需要明确typical Git workflow。假设你的master分支有一个可用的软件版本。有些人喜欢将master分支用作发布分支，而另一些人则将其用作开发分支。这并不重要。每当你需要添加一个功能或修复一个bug时，你就从master（或其他）分支创建一个分支。该功能应该足够小，可以在不涉及对代码库进行广泛修改的情况下处理。如果有大量的修改，应该创建分支层级，以便最后一层分支足够小。
如果每个分支都要添加一个小功能，就不太可能有很多人在同一个分支上工作。如果有多个人在一个功能上工作，那么该小组应该非常小，并且经常沟通，因此冲突应该很容易解决。如果一个提交或推送出现问题，只有你或你的小团队会有问题。
那么我们应该在哪里保证代码质量呢？我的答案是拉取请求。在Github中，你修改代码并提交一个pull request。在提交拉取请求时，你需要确保你的代码可以编译且能够通过测试。在Gitlab中，你需要在修改代码之前创建一个合并请求，并标记为WIP（work in progress）。然后你修改代码。在移除WIP标记之前，你需要确保你的代码质量良好。此外，代码评审人员将是另一层保护。
冲突应该很少发生在你的分支中，但当你将分支合并到基础分支中时可能会发生。你应该在合并之前立即解决它。
唯一与rebase相关的事情。许多开发人员喜欢在提交合并冲突之前对他们的分支进行rebase，以使git提交历史记录看起来更好。如果你向远程推送了代码并且其他人使用了你的代码，则rebase会造成麻烦的问题。然而，如果你总是在一个只修复小功能的分支上工作，那么没有人应该想使用你的分支。另外，我个人不太喜欢rebase，因为它修改了历史记录。
所以我的结论与其他人类似，经常提交和推送，但出于不同的原因。
- Yifan Sun
1
1这是我个人认为的正确答案。 - EgonBolton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接