什么Git分支模型适合你？ [英] What Git branching models work for you?

问题描述

我们公司目前正在使用一个简单的中继/发布/修补程序分支模型，并希望了解哪些分支模型最适合您的公司或开发过程。

1. 工作流程/分支模型

   
   
   

   以下是我见过的三个主要描述，部分相互抵触或不足以理清我们遇到的后续问题（如下所述）。因此，我们的团队迄今默认不是很好的解决方案。你在做更好的事情吗？
   
   

   
   
   • gitworkflows（7）手册页 （nvie）一个成功的Git分支模型
   
   
   • （reinh）敏捷团队的Git工作流程
   
   



2. 合并vs rebasing（纠结vs顺序历史）

   
   
   

   如果一个 pull --rebase 或者等到合并回主线直到你的任务完成了？我个人倾向于合并，因为这保留了一个任务开始和完成的基础的视觉插图，我甚至更喜欢 merge> --no-ff 来达到这个目的。但是它也有其他的缺点。还有很多人还没有意识到合并的有用特性 - 它不是交换（合并主题分支到主并不意味着将主合并到主题分支中）。
   

3. 我正在寻找自然的工作流程

   
   
   

   有时候会发生错误，因为我们的程序没有用简单的规则捕捉特定的情况。例如，早期版本所需的修补程序当然应该基于下游，以便可以将上游合并到所有必需的分支（这些术语的用法是否足够清楚？）。然而，在开发人员意识到它应该放在更下游之前，修正会让它进入主服务器，并且如果这已经被推送（更糟糕，合并或基于它的东西），那么剩下的选项是樱桃采摘，其相关的风险。你使用了哪些简单的规则？同样在这里，包括一个主题分支的尴尬必然排除其他主题分支（假设它们从共同基线分支）。开发人员不想完成一项功能，开始另一项功能，就像他们刚写的代码不再存在一样

   以避免造成合并冲突（由于樱桃选择）？
   
   
   

   创建合并冲突似乎是一种肯定的方式， ，他们再也不能合并了？在任何一个分支中应用相同的提交还原（如何做到这一点？）可能会解决这种情况？这是我不敢推动大部分基于合并的工作流程的原因。

如何分解成专题分支



我们认识到，从主题分支组装完成的集成是非常棒的，但我们开发人员的工作往往没有明确定义（有时很简单， ），如果一些代码已经进入了一个misc主题，那么根据上面的问题，它不能再被带出去吗？你如何处理定义/批准/毕业/发布你的主题分支？ 当然是可爱的。





但是我们根本无法将事情解决得足够多来解决这个问题 - 任何建议？
集成分支机构，插图？




以下是相关问题列表：








• Git用于内部开发的工作流描述 公司Linux内核开发的Git工作流程


• 你如何维护开发代码和生产代码？（感谢日是 PDF！）


• git发布管理


• Git Cherry-pick vs合并工作流程
a>

• 如何樱桃选择多个提交


• 你如何将选择性文件与git-merge合并？
如何选择一系列提交并合并到另一个分支

• < a href =https://stackoverflow.com/questions/855266/reinh-git-workflow> ReinH Git工作流程


• git工作流程，用于进行修改，永远不会推回原点 切里 - 合并


• 适用于组合操作系统和私有代码的Git工作流程


• 使用Git维护项目


• 为什么不能Git合并文件修改与修改父/主。


• Git分支/重新设计良好实践


• 瓦en会git pull --rebase让我陷入困境？
大型团队如何使用DVCS？ Plastic SCM在任务驱动的开发上写的内容，如果Plastic不是您的选择，研究 nvie的分支模型和他的支持脚本。


解决方案

DVCS需要实现的新开发人员最烦恼的特性是关于发布流程：





• 您可以导入（取/拉）任何远程您需要
  
• 您可以发布（推送）任何您想要的（裸）回购




<因此，您可以遵循一些规则来简化您的问题：




• 只有在未推送的情况下重新绑定分支（自上次rebase以来未推）


• 仅推送至裸回购（自Git1.7以来必需）


• 关注 Linus对rebase和merges的建议






现在：



工作流程/分支模型：



每个工作流都有支持发布管理流程，并且针对每个项目。
我可以添加到您提到的工作流中的是：每个开发人员不应该创建一个功能分支，只需要一个当前开发人员分支，因为事实是：开发人员通常不知道他/她的分支究竟会产生什么：一个特征，几个特征（因为它最终变得太复杂了），没有（因为没有准备好及时发布），另一个特征（因为原始的特征变形）。 ..





只有集成商才能在中央回购协议中建立官方特色分支，然后开发人员可以提取这些分支来重新组合或部分工作这符合该功能。





合并vs rebasing（纠结vs顺序历史记录）：



我喜欢我提到的答案（工作流程描述）





我正在寻找自然的工作流程：





修复，它可以帮助将每个修补程序与来自错误跟踪的故障单关联起来，这有助于开发人员记住在哪里（即在哪个分支上，即专门的分支修复）他/她应该进行这样的修改。

然后钩子可以帮助保护中央仓库免受未验证错误修复或从一个人不应该推。 （在这里没有具体的解决方案，所有这些都需要适应你的环境）

strong>




正如 JakubNarębski在<在他的回答中，樱桃采摘应该保留在少数情况下它是必需的。

如果你的设置涉及很多樱桃采摘（即这不是罕见的），那么一些东西是关闭的。




在回复中应用相同的提交（如何执行此操作？）


git revert 应照顾到这一点，但这并不理想。




如何分解成专题分支？




只要一个分支还没有被推到任何地方，开发者就应该重新组织它的提交历史（一旦他/她终于看到开发需要一个更加明确和稳定的形状）到：





• 如果需要的话，有几个分支（一个是明确标识的功能）
  
• 一组连贯的在一个分支内提交（参见修剪Git校验）







正确的程序，如代码审查和毕业？



整合分支专门的集成）回购可以帮助开发人员：





• 在远程集成分支之上重新开发他/她的开发（pull --rebase）


• 本地解决


• 将开发推向该回购


• 检查没有结果的集成商在一团糟;）






Our company is currently using a simple trunk/release/hotfixes branching model and would like advice on what branching models work best for your company or development process.

1. Workflows / branching models

   Below are the three main descriptions of this I have seen, but they are partially contradicting each other or don't go far enough to sort out the subsequent issues we've run into (as described below). Thus our team so far defaults to not so great solutions. Are you doing something better?

   • gitworkflows(7) Manual Page
   • (nvie) A successful Git branching model
   • (reinh) A Git Workflow for Agile Teams

2. Merging vs rebasing (tangled vs sequential history)

   Should one pull --rebase or wait with merging back to the mainline until your task is finished? Personally I lean towards merging since this preserves a visual illustration of on which base a task was started and finished, and I even prefer merge --no-ff for this purpose. It has other drawbacks however. Also many haven't realized the useful property of merging - that it isn't commutative (merging a topic branch into master does not mean merging master into the topic branch).

3. I am looking for a natural workflow

   Sometimes mistakes happen because our procedures don't capture a specific situation with simple rules. For example a fix needed for earlier releases should of course be based sufficiently downstream to be possible to merge upstream into all branches necessary (is the usage of these terms clear enough?). However it happens that a fix makes it into the master before the developer realizes it should have been placed further downstream, and if that is already pushed (even worse, merged or something based on it) then the option remaining is cherry-picking, with its associated perils. What simple rules like such do you use? Also in this is included the awkwardness of one topic branch necessarily excluding other topic branches (assuming they are branched from a common baseline). Developers don't want to finish a feature to start another one feeling like the code they just wrote is not there anymore

4. How to avoid creating merge conflicts (due to cherry-pick)?

   What seems like a sure way to create a merge conflict is to cherry-pick between branches, they can never be merged again? Would applying the same commit in revert (how to do this?) in either branch possibly solve this situation? This is one reason I do not dare to push for a largely merge-based workflow.

5. How to decompose into topical branches?

   We realize that it would be awesome to assemble a finished integration from topic branches, but often work by our developers is not clearly defined (sometimes as simple as "poking around") and if some code has already gone into a "misc" topic, it can not be taken out of there again, according to the question above? How do you work with defining/approving/graduating/releasing your topic branches?

6. Proper procedures like code review and graduating would of course be lovely.

   But we simply cannot keep things untangled enough to manage this - any suggestions? integration branches, illustrations?

Below is a list of related questions:

• What are some good strategies to allow deployed applications to be hotfixable?
• Workflow description for Git usage for in-house development
• Git workflow for corporate Linux kernel development
• How do you maintain development code and production code? (thanks for this PDF!)
• git releases management
• Git Cherry-pick vs Merge Workflow
• How to cherry-pick multiple commits
• How do you merge selective files with git-merge?
• How to cherry pick a range of commits and merge into another branch
• ReinH Git Workflow
• git workflow for making modifications you’ll never push back to origin
• Cherry-pick a merge
• Proper Git workflow for combined OS and Private code?
• Maintaining Project with Git
• Why cant Git merge file changes with a modified parent/master.
• Git branching / rebasing good practices
• When will "git pull --rebase" get me in to trouble?
• How are DVCS used in large teams?

Also check out what Plastic SCM writes on task driven development, and if Plastic is not your choice, study nvie's branching model and his supporting scripts.

解决方案

The most troubling feature new developers to DVCS need to realize is about the publication process:

• you can import (fetch/pull) whatever remote repo you need
• you can publish (push) to any (bare) repo you want

From that, you can respect a few rules to make your questions easier:

• only rebase a branch if it hasn't been pushed (not pushed since the last rebase)
• only push to a bare repo (mandatory since Git1.7)
• follow Linus's advices on rebase and merges

Now:

Workflows / branching models:

each workflow is there to support a release management process, and that is tailored for each project.
What I can add to the workflow you mention is: each developer should not create a feature branch, only a "current dev" branch, because the truth is: the developer often doesn't know what exactly his/her branch will produce: one feature, several (because it ended up being too complex a feature), none (because not ready in time for release), another feature (because the original one had "morphed"),...

Only an "integrator" should established official feature branches on a "central" repo, which can then be fetched by developers to rebase/merge the part of their work that fits that feature.

Merging vs rebasing (tangled vs sequential history):

I like my answer you mention ("Workflow description for git usage for in-house development")

I am looking for a natural workflow:

for fixes, it can help associating each fix with a ticket from a bug tracking, which helps the developer remember where (i.e. on which branch, i.e. a dedicated branch "for fixes") he/she should commit such modifications.
Then hooks can help protect a central repo against pushes from non-validated bug-fixes or from branches from which one shouldn't push. (no specific solution here, all this need to be adapted to your environment)

How to avoid creating merge conflicts (due to cherry-pick)?

As stated by Jakub Narębski in his answer, cherry-picking should be reserved for rare situations where it is required.
If your setup involves a lot of cherry-picking (i.e. "it is not rare"), then something is off.

Would applying the same commit in revert (how to do this?)

git revert should take care of that, but that is not ideal.

How to decompose into topical branches?

As long as a branch as not yet been pushed everywhere, a developer should reorganize its history of commits (once he/she finally see the development takes a more definitive and stable shape) into:

• several branches if needed (one by clear identified feature)
• a coherent set of commits within one branch (see Trimming Git Checkins)

Proper procedures like code review and graduating ?

Integration branches (in a dedicated integration) repo can help the developer to:

• rebase his/her development on top of that remote integration branch (pull --rebase)
• solve locally
• push the development to that repo
• check with the integrator that doesn't result in a mess ;)

这篇关于什么Git分支模型适合你？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！