无法在 Git 的 master 分支上工作的原因
所以，我对 git 相当陌生，在过去的几周里我读了一些书，我读到一些人说 master 分支不应该改变，而应该分支然后合并到。
我很高兴能够与分支合作，但想知道不在主分支上工作的原因是什么？
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.
I'm happy enough to work with branches but was wondering for the reasons behind not working on the master branch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
其他人已经提出了不直接在
master中进行更改的很好的案例，我同意他们的观点。然而，总是提倡这样的工作流程有时会让刚接触 git 的人相信它是不必要的复杂，所以我想提供一个对立点。如果您有一个单人或非常小的团队，并且您的开发是高度线性的，即您很少一次处理多于一件事，并且每个功能通常在开始下一个功能之前完成，那么不这样做确实没有什么好处。直接从
master工作。如果需要的话，可以很容易地随时返回并添加分支。我强烈建议您了解功能分支工作流程，但如果您觉得在您的情况下这只是添加额外的步骤而不给您购买任何东西，我保证我不会告诉 git 警察。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.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.git（官方 git 存储库）为例。有几个分支，最值得注意的是：
所以，
master包含很可能结束的代码在 git 的下一个版本中。next包含经过测试的代码，可能会合并到master分支中。pu（建议的更新，iirc）包含相当新的（可能是）未经测试的代码。pu被认为不稳定，将根据 junio 的喜好进行重置和重新设置。next可能会在发布后或发布周期内重置，但这种情况不太常见。master是一成不变的，在推送并公开后就不再改变。您会看到，如果认为有价值，则更改将从
pu合并到next以及从next到master并且不要打碎东西。分支
maint用于修复错误，这也适用于旧版本的 git。maint通常合并到next和/或master。您可以检查 http://git.kernel.org/?p=git/ 上的分支git.git;a=摘要
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.
that way code in master will almost always build without problems, and can be mostly used directly for releases.
let's take git.git (the official git repository) as an example. there are several branches, most noticable:
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 themasterbranch.pu(proposed updates, iirc) contains quite new (and probably) untested code.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.you see, that changes will get merged from
putonextand fromnexttomasterif they are deemed worthy and don't break stuff.the branch
maintis used to make bugfixes which should also apply to older versions of git.maintis usually merged tonextand/ormaster.you can inspect the branches on http://git.kernel.org/?p=git/git.git;a=summary
对于像 Git 或 Mercurial 这样的 DVCS（分布式版本控制系统），您需要考虑的一件事是“发布”工作流程 (与分支工作流程正交）。
当你只有分支时，你会问自己它们代表什么开发工作。
如果
master旨在表示稳定的代码，例如 knittl 详细信息://stackoverflow.com/questions/5713563/reasons-for-not-working-on-the-master-branch-in-git/5713627#5713627">他的回答，那么是的，您需要从master分支/合并到master。但是，当您可以克隆/推/拉（即发布到不同的存储库，它们本身可以有不同的目的）时，那么“
master”可以在不同的存储库中发挥不同的作用。master通常代表最稳定的代码。master和一些用于紧急修复的修补程序维护分支。master分支，从一个推送重写到另一个推送，只是为了通过一个仅监视所述master分支的钩子来运行一些静态分析代码测试仓库。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).
When you have only branches, you will ask yourself what development effort they represent.
If
masteris meant to represent stable code, like knittl details in his answer, then yes, you need to branch from/merge tomaster.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.masterusually representing the most stable code.master, and some hotfix maintenance branch for urgent fixes.masterbranch, rewritten from push to push just in order to run some static analysis code by a hook which monitors only saidmasterbranch for that test repo.当双方都进行提交时——这意味着在本地存储库和上游（例如来自其他团队成员）——可能会发生提交冲突。这意味着文件，特别是行都被两者编辑过。在这种情况下，需要进行一些手动合并处理。
master分支用于在无法访问上游（移动使用或网络故障）时拥有代表上游的本地分支。当有代表上游更改的本地分支时，进行合并解析和其他操作要容易得多。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.不知道我的理解是否正确，我是git新手。
我认为当你拥有多个功能时，生活会变得更轻松。假设你有一个项目，并且致力于功能 A，然后你实现功能 B。
现在可能会发生这样的情况，你认为整个功能 A 是一个错误，并且您想要一个仅包含功能 B 但没有功能 A 的项目版本。
如果一切都在主人身上，这个任务就很棘手。
如果每个功能都在自己的分支上，那么这个任务很简单：
您采用旧的主版本（没有 A 和 B）。
您合并分支 B。
完毕。
Not sure if my understanding is correct, I am new to 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.
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.
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.