版本控制工作流程

Question

我已经编码了10多年，但是我从未使用过任何版本控制。 我想学习并开始使用GIT，我打算很快阅读Apress ProGIT书。

这个问题不是关于如何使用GIT命令，而是关于在哪些步骤中调用它们的问题。

我经常读到有人说要签出项目，然后将其推送到服务器。

我通常一次处理多个文件，所以我想弄清楚，我每更改一个文件然后点击保存`，是我应该提交该文件的时间，或者更确定，我从事这5个工作今天的文件，在一天结束时我可以提交所有这5个文件？

我知道很多人在GIT中使用命令行，所以我无法想象他们每次更改fil后都会来回走动。

我意识到这听起来很基础，但是记住我从未使用过任何版本控制，所以我有点迷失了，我的意思是所有文章和教程都是关于正确的语法/命令的，并假设您还具有其他版本控制知识（大多数人都这样做）

Answer 1

git或与此相关的任何DVCS的问题是，向上游提交和推送您的提交是完全独立的概念。 例如，如果使用SVN，则提交意味着每个人都可以看到您的更改集，在git中，您无需担心。 随时随地进行提交。 一旦对变更有足够的信心，就将变更推向上游。

这使您可以根据自己的意愿进行提交。 基本上，这可以归结为您和团队的个人工作流程偏好。

一个好的经验法则是，一旦您有了稳定的代码新版本，便要提交，这样，如果有人偶然检出该修订版，则不会破坏任何内容。 （如果您打算执行git bisect ，这在以后也很重要， git bisect是一种高级调试方法，但现在暂时忽略它。）

您可以通过以下示例学习一些非常好的资源：

• http://nvie.com/posts/a-successful-git-branching-model/
• http://gitready.com/

Answer 2

我通常一次处理多个文件，所以我想弄清楚，我每更改一个文件然后点击保存`，是我应该提交该文件的时间，或者更确定，我从事这5个工作今天的文件，在一天结束时我可以提交所有这5个文件？

使用VCS时，最好考虑功能（或解决问题时的修复）方面的变化，而不仅仅是文件。 即使您只更改了一个文件，但引入了完整的新功能，并且如果您在团队中工作，也准备与其他人共享，那么该进行提交了。 另一方面，如果您已经更改了20个文件，但是您仍在实施新功能中，最好将提交推迟到完成为止。

每种方法都有例外，但这是我尝试在工作中使用的一般规则。 其背后的想法是，在任何提交中签出代码后，您或多或少地完成了工作。 当以后需要删除/还原其中一个功能时，为每个功能创建新提交也很有用。 但是，通常您正在开发一项无法一次提交的大型功能。 在那种情况下，我仍然会尝试将此功能分解为较小的部分，并在完成每个部分之后进行提交。

对我来说，例外是通常是刚刚开始的项目，您不太关心未来，因为它才刚刚开始并且项目还没有良好的结构，因此很可能在不久的将来会发生很多变化。 在这种情况下，我的提交有时会变得很大，而且结构也不那么好。

Answer 3

查看此链接： Git初学者：权威的实用指南

我发现它非常有用。 它使我了解它是如何工作的。