基于团队的Git工作流程

时间:2011-10-21 08:41:37

标签: git workflow git-branch git-remote

我最近设置了一个Gitolite Ubuntu服务器,以及存储库和用户(在组内)。对于实际工作的事情,一切都在游动。

在我的Git研究中,我发现了一个特定的Git Model,它以我们想要的方式工作。我们迫切需要一种方法来将修补程序应用于我们当前的源代码,而无需拧紧当前的开发版本。来自“nvie”的这个模型满足了我们所有的需求。

问题是它并没有真正解释使用此模型的远程托管。我们无法弄清楚一些事情。

目前我们认为每次添加新的feature-*分支时,我们都会将其推送到同名的远程分支。但这意味着我们其中一个人将来必须手动拉动它们并确保没有冲突。

我们如何在基于团队的工作流程中使用“nvie”模型?

修改以更清晰

团队中没有人理解两个人如何开发自己的功能。第一个人完成他们的功能并合并到develop。第二个人做什么?存储他们的更改并将develop下拉到他们的分支中,然后应用他们的存储或什么?

我们不确定我们如何能够同时推动开发,而不会覆盖彼此的新变化。

3 个答案:

答案 0 :(得分:1)

引用主题

  

功能分支的本质是它只要存在就存在   功能正在开发中,但最终会合并回来   开发(明确地将新功能添加到即将发布的版本中)或   丢弃(如果实验令人失望)。

     

功能分支通常仅存在于开发人员存储库中,而不存在于   原点。

必须使所有水晶清洁。后来的代码显示相同的样式

  

完成的功能可以合并到开发分支中   他们到即将发布的版本:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

注意推分支,开发,而不是功能分支。您只需根据需要进行合并即可。

答案 1 :(得分:1)

这是一个争论的话题。通过像Git这样的现代工具,可以实现每个功能的分支。之前,由于无法实现粒度级别而感到不满 - 或者说这太难了。

我会探索添加一个可以根据可能未获得QA批准重置的分支 - 集成后的UAC。这对我和其他人来说都很有效。这里有一个非常详细的介绍和之后的讨论。我希望它有所帮助:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

答案 2 :(得分:0)

这个关于atlassian网站的快速教程将是一个很好的开始。

https://www.atlassian.com/git/workflows