在 Git 中不在 master 分支上工作的原因

Reasons for not working on the master branch in Git

提问by Mark Williams

So, I'm fairly new to git and I've after a bit of reading around over the last couple of weeks I've read a few people saying that the master branch shouldn't be changed but rather branched from and then merged to.

所以，我对 git 还很陌生，在过去几周阅读了一些资料后，我读到一些人说不应该更改 master 分支，而是应该从分支分支然后合并到.

I'm happy enough to work with branches but was wondering for the reasons behind not working on the master branch?

我很高兴与分支一起工作，但想知道不在 master 分支上工作的原因？

采纳答案by knittl

i guess the usual reasoning is, that the master branch should represent the 'stable' history of your code. use branches to experiment with new features, implement them, and when they have matured enough you can merge them back to master.

我想通常的推理是，master 分支应该代表代码的“稳定”历史。使用分支来试验新功能，实现它们，当它们足够成熟时，您可以将它们合并回 master。

that way code in master will almost always build without problems, and can be mostly used directly for releases.

这样 master 中的代码几乎总是可以毫无问题地构建，并且主要可以直接用于发布。

let's take git.git (the official git repository) as an example. there are several branches, most noticable:

我们以 git.git（官方 git 存储库）为例。有几个分支，最引人注目的是：

• master
• next
• pu
• maint

• 掌握
• 下一个
• 浦
• 维护

so, mastercontains code which is very likely to end up in the next release of git. nextcontains tested code, which will potentially be merged into the masterbranch. pu(proposed updates, iirc) contains quite new (and probably) untested code.

因此，master包含很可能会出现在下一个 git 版本中的代码。next包含经过测试的代码，这些代码可能会被合并到master分支中。pu（建议的更新，iirc）包含相当新的（并且可能）未经测试的代码。

puis considered unstable and will be reset and rebased to junio's liking. nextmight get reset after a release or during a release cycle, but this is less common. masteris set in stone and never changed after it's been pushed and made publicly available.

pu被认为是不稳定的，将根据 junio 的喜好进行重置和重新定位。next可能会在发布后或在发布周期期间重置，但这种情况不太常见。master一成不变，在推送并公开发布后从未改变。

you see, that changes will get merged from puto nextand from nextto masterif they are deemed worthy and don't break stuff.

你看，如果它们被认为是有价值的并且不会破坏东西，那么这些更改将从putonext和 from nextto合并master。

the branch maintis used to make bugfixes which should also apply to older versions of git. maintis usually merged to nextand/or master.

该分支maint用于修复错误，这也适用于旧版本的 git。maint通常合并到next和/或master。

you can inspect the branches on http://git.kernel.org/?p=git/git.git;a=summary

你可以在http://git.kernel.org/?p=git​​/git.git;a=summary上检查分支

回答by Karl Bielefeldt

Other people have made very good cases for not making changes directly in master, and I agree with them. However, always advocating workflows like this sometimes leads people new to git to believe it is needlessly complex, so I wanted to provide a counterpoint.

其他人提出了很好的案例，不直接在 中进行更改master，我同意他们的观点。然而，总是提倡这样的工作流程有时会让刚接触 git 的人相信它不必要地复杂，所以我想提供一个对立的观点。

If you have a one-person or very small team and your development is highly linear, i.e. you rarely work on more than one thing at a time and each feature is usually completed before starting the next, there really is little to no benefit to not work directly out of master. It is very easy to go back and add a branch at any point should the need arise. I highly recommend being aware of the feature branch workflow, but if you feel in your case it's just adding extra steps without buying you anything, I promise I won't tell the git police.

如果您有一个单人或非常小的团队，并且您的开发是高度线性的，即您很少一次处理多于一件事，并且每个功能通常在开始下一个功能之前完成，那么不这样做真的几乎没有好处工作直接出来master。如果需要，可以很容易地返回并在任何时候添加分支。我强烈建议您了解功能分支工作流程，但如果您觉得在您的情况下它只是在不购买任何东西的情况下添加额外的步骤，我保证我不会告诉 git 警察。

回答by VonC

The one thing you need to consider with a DVCS (Distributed Version Control System) like Git or Mercurial is the "publication" workflow (orthogonal to the branching workflow).

对于像 Git 或 Mercurial 这样的 DVCS（分布式版本控制系统），您需要考虑的一件事是“发布”工作流（与分支工作流正交）。

When you have only branches, you will ask yourself what development effort they represent.
If masteris meant to represent stable code, like knittldetails in his answer, then yes, you need to branch from/merge to master.

当您只有分支时，您会问自己它们代表什么开发工作。
如果master是为了表示稳定的代码，例如他的回答中的knittldetails ，那么是的，您需要从/合并到.master

But when you can clone/push/pull (that is publish to different repos, which can have different purposes in themselves), then 'master' can play a different role from repo to repo.

但是当您可以克隆/推/拉（即发布到不同的存储库，它们本身可以具有不同的用途）时，那么“ master”可以在不同的存储库中扮演不同的角色。

• a development repo can have many branches, with masterusually representing the most stable code.
• a deployment repo can have only master, and some hotfix maintenance branch for urgent fixes.
• a local test repo can have only one masterbranch, rewritten from push to push just in order to run some static analysis code by a hook which monitors only said masterbranch for that test repo.
• ...

• 一个开发仓库可以有很多分支，master通常代表最稳定的代码。
• 部署存储库只能有master，以及一些用于紧急修复的修补程序维护分支。
• 一个本地测试仓库只能有一个master分支，从 push 到 push 重写，只是为了通过一个钩子运行一些静态分析代码，该钩子只监控master该测试仓库的所述分支。
• ...

回答by Daniel B?hmer

When doing commits on both sides -- that means on your local repository and upstream e.g. from other team members -- it can happen that commits conflict. That means files and in particular lines were edited by both. In this case some manual merge handling is necessary.

在双方进行提交时——这意味着在你的本地存储库和上游，例如来自其他团队成员——可能会发生提交冲突。这意味着文件，特别是行都被两者编辑过。在这种情况下，一些手动合并处理是必要的。

The masterbranch is for having a local branch representing upstream when you cannot access upstream (mobile use or network failure). It is much easier to do merge resolving and other stuff when having a local branch representing the upstream changes.

该master分支用于在您无法访问上游（移动使用或网络故障）时有一个代表上游的本地分支。当有一个代表上游更改的本地分支时，进行合并解析和其他事情要容易得多。

回答by AndrzejO

Not sure if my understanding is correct, I am new to git.

不确定我的理解是否正确，我是 git 新手。

I think it makes life easier when you have several features.Let's say you have a project, and work on feature A, then later you implement feature B.

我认为当你有几个功能时，它会让生活更轻松。假设你有一个项目，并在功能 A 上工作，然后你实现功能 B。

Now it can happen, that you decide that the whole feature A was a mistake, and you want to have a version of your project with only feature B, but without A. If everything is on master, this task is tricky.

现在可能发生的情况是，您认为整个功能 A 是错误的，并且您希望拥有一个只有功能 B 而没有 A 的项目版本。如果一切都在掌握中，那么这个任务就很棘手。

If each feature is on its own branch, then this task is easy: You take the old master version (without A and without B). You merge branch B. Done.

如果每个特性都在自己的分支上，那么这个任务很简单：你使用旧的主版本（没有 A 和 B）。您合并分支 B。完成。