什么时候应该提交本地仓库而不是远程仓库？ [关闭]

Question

虽然information on how Git works 有很多，但我发现关于它应该如何使用的内容并不多。什么时候应该提交？什么时候应该推动？目前我只是自己编码。

我使用 Github 的部分原因是作为备份，以保护我的硬盘死机。这似乎建议尽可能多地推动。另外，我现在的情况是，我修复了一个错误，但还有另一个错误，该功能仍然无法正常工作。现在是推送到远程仓库的好时机吗？

我真的不明白提交本地 repo 的意义。我想重点是在代码不够好而无法远程推送时跟踪更改？

Answer 1

有很多可用的工作流程，每个工作流程都定义了使用 git 远程和本地存储库的不同方式。

仅举几例：

• 集中式工作流程，
• 功能分支工作流，
• gitflow 工作流程，
• 分叉工作流。

一般来说，请记住，您本地存储库中的任何内容都由您自己进行试验。一旦它在远程 - 即使它只是一个功能分支 - 人们可能会依赖它，因此您可能不会那么容易地重写提交历史。

查看详情here。

Answer 2

理想情况下应该是这些步骤：

1. 应该创建一个单独的分支。
2. 将本地更改推送到此存储库。
3. 完成所有更改后，您应该拉出 master 并将其与您的分支合并。
4. 之后，您应该提交更改。
5. 那么您应该将更改推送到远程。
6. 最后你的分支应该被合并并推送到master中。

我觉得这是very good answer，你也可以参考一下。

Answer 3

有几个用例可以将一些提交保存在本地并且从不将它们推出。没有写一本关于它的书（因为还有更多），以下是我发现自己每天都在使用的两个最大的书：

1. 您不想与其他人分享的实验工作。如果您独自工作，这实际上并不适用，因为如果除了您可以看到远程之外没有人可以看到它只是在本地，还是远程和本地都没有区别。但是，如果您将来包含更多开发人员，或者计划包含更多开发人员，那么养成将部分工作只保留在本地的习惯可能是个好主意。
2. 假设您正在开发一个相对较大的功能，并且需要 100 次提交才能完成。与其推出一堆 100 个混乱的提交（比如“修复错字”、“修复失败的单元测试”、“修复合并冲突”、“重构类 X 以接受可选参数”），不如压缩你的工作到一个提交，然后将其推出。这样，您的 git 历史记录通常更清晰，更易于管理和回顾。如果您想向一个客户/用户而不是另一个客户/用户提供某些功能，这可能特别有用。请注意，压缩可以消除历史记录，但请谨慎使用。