我刚开始使用 Git，虽然很容易找到如何在 Git 中执行某些操作，但我很难弄清楚何时在 Git 中执行这些操作。
例如，什么情况下通常会分支一个项目？
我正在考虑为当前项目的每个版本创建一个分支，并在完成后将其合并到主分支中 - 这是常见的做法吗？
6个回答
29
我确信有人会以与我不同的方式做事。然而，这是我遵循的方式:
- 为每个功能创建一个分支（稍后将它们合并回去）
- 为每个漏洞修复创建一个分支
- 让主分支保持清洁，不要使其成为“正在进行中”的工作（WIP）
- Alan Haggai Alavi
2
3我喜欢这个想法：“让主分支保持干净，不要将其变成正在进行的工作 (WIP)”。 - LDK
您是否需要将这些功能分支推送到远程存储库（例如进行错误修复），还是仅在本地创建分支，然后将其合并到本地主干后再推送到远程？ - DD.
10
我不确定您所说的“将当前项目的每个版本分支化”是什么意思。
无论如何，git建议您创建“主题分支”。通过“主题分支”，它意味着在您处理特性/错误时创建一个分支。比方说，我正在处理jQueryUI，并被要求为jQuery Calendar添加一个新功能，允许用户指定不能选择的日期。
如果我在名为master的分支中，我会创建一个叫做“SpecifyDateExclusion”的本地分支，并开始进行更改。与此特性相关的所有代码都将存放在这个分支中。
master
|
|
|___ SpecifyDateExclusion
我在处理这个功能的时候，收到了一个报告，称Opera 10中的日历出了问题，需要立即修复。于是我回到我的主分支并创建了另一个名为Opera10BugFix的分支，开始在其中修复这个错误。
master
|
|
|___ SpecifyDateExclusion
|
|
|___ Opera10BugFix
很快，你可能会有类似以下的分支：
master
|
|
|___ SpecifyDateExclusion
|
|___ Feature1
|
|___ Feature2
|
|___ Feature3
|
|___ Opera10BugFix
|
|___ BugFix1
|
|___ BugFix2
你可能会问，这有什么好处呢？
好处在于它给我在准备发布时带来了灵活性。假设我的下一个版本主要是关于修复漏洞的。
我将从主分支(master)创建一个名为 "InterimBugFix" 的新分支，并合并所有我的漏洞修复分支。
如果我想创建一个包含漏洞修复/功能的混合版本，我将从主分支(master)创建一个名为 "NextVersion" 的分支，并合并我的功能/漏洞修复分支。
Git对于如何管理这些分支非常强大，如果你能想象到什么，Git就可以让你实现。
- SolutionYogi
1
你说你只在发布时合并，这不会导致可怕的合并灾难吗？当代码库在所有分支上都不同，因此会发生冲突。 - Jessica
7
Git最好的一点是它不会强迫你做任何决定。Git最糟糕的一点是它不会强迫你做任何决定。
你的工作流完全由你决定。你是打算合作还是独立开发？你在发布之间有短暂的时间还是长时间？这些限制可能有助于定义适当的工作流程。
我在一个由四名开发人员组成的小团队中工作，每两周进行一次迭代。在周期开始时，我们商定一个范围并针对主干进行开发。我们预计超过两周的任何事情都会被移动（或者从分支开始）（这种情况并不经常发生，我们的范围很紧）。
在两周的周期结束时，我们执行QA测试，标记和发布。开始下一个周期时，那些其他分支将合并回主干。
如果需要修补版本，我们会创建一个分支，提交，QA测试，标记和发布。
对于任何实验性的东西，我们通常会创建一个新分支，并将其与主干隔离开来，直到它适合合并或丢弃为止。
总之，我们的团队在以下情况下会创建分支：
你的工作流完全由你决定。你是打算合作还是独立开发？你在发布之间有短暂的时间还是长时间？这些限制可能有助于定义适当的工作流程。
我在一个由四名开发人员组成的小团队中工作，每两周进行一次迭代。在周期开始时，我们商定一个范围并针对主干进行开发。我们预计超过两周的任何事情都会被移动（或者从分支开始）（这种情况并不经常发生，我们的范围很紧）。
在两周的周期结束时，我们执行QA测试，标记和发布。开始下一个周期时，那些其他分支将合并回主干。
如果需要修补版本，我们会创建一个分支，提交，QA测试，标记和发布。
对于任何实验性的东西，我们通常会创建一个新分支，并将其与主干隔离开来，直到它适合合并或丢弃为止。
总之，我们的团队在以下情况下会创建分支：
- 特性超出我们的迭代周期
- 修补版本
- 实验性特性
- Tate Johnson
2
“develop against master” - 这是否意味着您使用主分支进行开发？ - LDK
非常重要的一点是：Git 没有版本控制工作流。相反，它是一个版本控制工作流程构建工具包。就像使用乐高积木一样，把所有东西组合在一起需要大量的繁琐、艰苦和无聊的工作，但结果将会是令人惊叹的，因为它是你自己的，是你用自己的双手建造的，并且完全按照你的需求定制的。说得好！ - Jörg W Mittag
4
在Web应用程序开发中，我们这样做：
我们维护一个名为“Production”的干净分支。它包含现有的网站上存在的代码。
所有对此进行更改的操作都在任务分支中完成。因此，您可能会看到一个名为Task-13923-add-feature-x的分支。这些分支是从生产分支创建的，并且在合并到生产之前必须将生产分支合并到它们中（因此始终是干净的快进，没有潜在的冲突）。
其他人定期将“Production”分支合并到他们的任务分支中以保持最新状态。
我们维护一个名为“Production”的干净分支。它包含现有的网站上存在的代码。
所有对此进行更改的操作都在任务分支中完成。因此，您可能会看到一个名为Task-13923-add-feature-x的分支。这些分支是从生产分支创建的，并且在合并到生产之前必须将生产分支合并到它们中（因此始终是干净的快进，没有潜在的冲突）。
其他人定期将“Production”分支合并到他们的任务分支中以保持最新状态。
- gahooa
2
你是在有效地合并生产分支，还是在将任务分支变基？我对Git仍然相当新，但后者对我来说似乎更有意义。 - MarioDS
@MarioDS 主要的问题是
Production只会快进。我们通常将当前被接受的代码保留在master中。在推送之前，开发人员总是被要求在master上进行变基 - 这通常会得到一个干净的快进。如果团队足够小，我有时会在测试/上线之前将master变基到production上。这在99%的情况下都能正常工作，并且具有提供非常线性历史记录的好处。如果团队更大，则我会坚持定期将Production合并到master中，以便每个人都有更新的代码。缺点是你会失去线性历史记录。 - gahooa3
如果有疑问，就分支。 分支是很便宜的，而且新分支的信息可以很容易地转移到旧分支上。当一个分支不再有用时，可以轻松地将其删除。
- Norman Ramsey
1
这取决于你的“分支策略”，有很多不同的答案。根据我的经验，最简单的两种是任务/特性分支和发布分支。你使用哪种将取决于你的发布周期如何运作，以及其他因素。
如果你正在持续集成和发布，那么任务/特性分支是有意义的，因为它们可以使“主干”（在其他版本控制系统中称为trunk）保持相对稳定的状态，从而使发布变得容易。但是，如果你有一个更结构化的发布周期，也许发布分支会更有意义，因为它们可以用来更仔细地定义每个发布所添加的内容。当然，混合策略也是可行的。
我通常使用任务/特性分支，这样每个错误或功能请求都会被分支。然后进行工作，并在完成后合并回主干。
- Brenton Alker
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接