使用Git分支的开发人员工作流程

Question

我正在阅读这篇文章http://nvie.com/posts/a-successful-git-branching-model/

现在我们有一个中央存储库（源代码库）。每个人都在克隆这个（用技术术语创建一个分支），然后创建自己的分支。

我曾经习惯了svn，这是一种古老的做事方式，作为一个好的小开发者，你经常要检查主人。但是对于Git，我不清楚我们是否应该继续这样做。

让我们说我对原点大师有所了解，而我的同事也有自己的分支用于其他一些功能。我希望我们两个经常做出承诺，以便我们互相改变。

但这是否意味着我们每次提交时都应该合并为主人？或者，我是否应该直接从他的分支机构撤出，我们只有在它准备好发布（或准备推送到QA或其他任何东西）的时候才合并回主人？

另外，如何创建开发人员分支，我们可以将分支合并到某种开发人员存储库中？我不知道这是如何工作的，将原始主人的环境隔离为你不修改的东西（这不是一件容易的事）？那么对于开发者来说，你是否创建了一个名为“开发”的新分支。关闭origin master然后开发人员将他们的更改合并回开发分支，然后在我们开发分支稳定的时候，我们认为我们的开发分支是稳定的，合并回主机并将其推送到Jenkins和Jenkins构建并运行自动化单元测试？你会如何将你的开发部门推向Jenkins？我输了。

Answer 1

回答第一点 - 经常合并到主人身上取决于你的工作流程。 Git有很多不同的工作流程; Git Flow是另一种方法。它有其优点和缺点，具体取决于您的团队如何集成，测试和部署代码。

现在，听起来你有一个主分支和一个分支，你在它被推到掌握之前亲自开发。这可能适用于您的工作流程，但您可能希望了解一些事项：

• 您正在做的工作应该与其他人的工作隔离。如果您发现自己的情况往往并非如此，则需要进一步分解工作，直到可以合理隔离为止。
• 如果您的功能已完成，则只应合并为主人。 不要合并不完整的代码。
• 如果你需要一个地方来整合你和其他同事所做的工作，那么这更像是一个沟通问题而不是其他任何问题;如果master是分支，那么就这样吧。

Git Flow背后的理念是它采用当前掌握的任何东西并将其视为生产就绪代码;也就是说，掌握在主人身上的代码就是那个时刻生产的代码。存在其他工作流程，其中使用tagged commits表示这一事实，这样只有在master上的最后一个标记的提交才是生产中的。

由于我对您的测试环境一无所知，因此我无法说出是否更容易或更难创建主服务器的新分支，专门用于集成点。如果您不希望master中的提交代表可部署的代码，那么继续直接合并到master（但标记您的版本）可以。

我会说这是关于单独的分支，但是：如果你想做单独的分支，那么你将会想要采用GIT Flow背后的大多数原则。了解它对您和您的团队的效果如何。

• master始终可部署
• 开发总是可以掌握
• 主题分支总是可以开发（并且应该是rebased against master）
• 此外，作为一般规则，所有分支都应通过Jenkins进行测试。如果您无法合理地测试所有分支，那么应该测试主要集成点。

Answer 2

您应该尽可能多地合并回主人。例如，许多公司都有一个工作流程，用户可以在其中编写代码，在本地提交代码，然后将其发布以供审核。如果需要进行更改，作者将进行更改，进行另一次提交，并将其发布以供再次审核。当被接受时（通常需要0-2次修订），开发人员将其合并为master。

不经常合并到master是一件非常非常糟糕的事情，因为这意味着会出现一些荒谬的合并冲突。别这么做。

你询问＆＃34;开发者分支机构＆＃34 ;;这就是主人的用途。不使用master作为发布分支，而是使用master作为开发分支，并且无论何时需要发布，都要创建标记。这些类似于分支，但永久指向给定的存储库状态。

如果您需要与尚未准备好的其他开发人员共享工作（即尚未审核），您可以创建另一个远程分支（除了master），并使用它。