基于团队的 Git 工作流程
我最近设置了一个 Gitolite Ubuntu 服务器，以及存储库和用户（组内）。一切都进展顺利，真正有效。
在我的 Git 研究中，我发现了一个特定的 Git 模型按照我们想要的方式工作。我们迫切需要一种方法来将修补程序应用于当前的源代码，而不破坏当前的开发版本。 “nvie”的这个模型可以满足我们的所有需求。
问题是它并没有真正解释使用此模型的远程托管。我们无法弄清楚一些事情。
目前，我们认为每次添加完成的新 feature-* 分支时，我们都会将其推送到同名的远程分支。但这意味着我们中的一个人稍后必须手动拉取它们并确保不存在冲突。
我们如何在基于团队的工作流程中使用“nvie”模型？
编辑得更清楚：
团队中没有一个人理解两个人如何开发自己的功能。第一个人完成他们的功能并合并到 develop 中。第二个人做什么？存储他们的更改并将 develop 拉到他们的分支中，然后应用他们的存储或什么？
我们不确定如何同时推进开发等，而不覆盖彼此的新更改。
I've recently setup a Gitolite Ubuntu server, along with repositories and users (within groups). Everything is going swimmingly for things actually working.
In my Git research, I've found a specific Git Model that works in the way we want it to. We were in dire need for a way to apply hotfixes to our current source without screwing the current development version. This model from "nvie" attends to all of our needs.
The problem is that it doesn't really explain remote hosting using this model. And we can't figure out a few things.
Currently we're thinking that every time we add a new feature-* branch which is finished, we'll push it to a remote branch under the same name. But this means that one of us will then at a later date have to have to manually pull them and ensure there are no conflicts.
How can we use the "nvie" model but in a team based workflow?
Edit to be more clear:
None of the team understand how, say, two people can be developing their own features. The first person finishes their feature and merges into develop. What does the second person do? Stash their changes and pull down develop into their branch, then apply their stash or what?
We're unsure how we can be pushing into develop at the same time etc, without overwriting each others newer changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个争论很大的话题。 Git 等现代工具使按功能分支成为可能。以前，人们对此不以为然，因为粒度级别不可能达到——或者说太难做到。
我将探索添加一个分支，您可以根据集成后可能未获得 QA 批准的情况重置该分支 - UAC。这对我和其他人来说效果很好。这是对其的非常详细的描述以及之后的良好讨论。我希望它对您有所帮助：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
This is a huge topic of contention. Branch-per-feature is made possible by modern tooling like Git. Before, it was frowned upon as the level of granularity was not possible - or it was too difficult to do.
I would explore adding a branch that you can reset based upon potentially not getting QA approval - UAC after integrating. This has worked well for me and others. Here is a very detailed account of it and a good discussion after. I hope it helps:
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
引自主题
必须让所有水晶都干净。后面的代码显示相同的风格
注意推送分支，开发，而不是功能分支。您只需根据需要进行尽可能多的合并|推送
Quote from topic
must make all crystal clean. Later code show the same style
Note pushed branch, develop, not feature-branch. You just make as much merge|push, as it needed
Atlassian 网站上的这个快速教程将是一个很好的开始。
https://www.atlassian.com/git/workflows
This quick tutorial on atlassian website will be a great start.
https://www.atlassian.com/git/workflows