在git中，为什么要在分支而不是主分支上工作？

Question

I keep reading about how one should always work on a different branch than the main one. As soon as I get the job done, I merge them. Why is this any better than simply working on the main branch?

The only advantage I see at first glance is that then there is a somewhat safe way of always knowing what is the "last known working version" -- the main branch. Is that the reason?

Answer 1

The primary advantage of working in a branch is that you can make commits for an isolated feature while still being able to make fixes on master. You can also do things like "squash" commits with rebase -i if you feel that multiple commits should actually show up as a single commit to other users.

You can also work on multiple experimental features at the same time. You may later decide to scrap that feature or implement it in another way and you can just delete that branch without cluttering your master history.

I often have a handful of experimental feature branches in any given project. Even for just quickly jotting down some thoughts in the form of code they are very useful.

Answer 2

Here's one example that happens a lot for me:

Let's say you are working on a feature, its an extensive one, so its going to take many commits. You are about half way done, so the code isn't stable, but it's coming along nicely.

Now, a critical bug is found in the production version of the code, (your master branch, presumably). If you have been committing against the master branch, how do you fix it and push out the fix without pushing out the broken unfinished code?

If you had been working on your new feature in a branch that isn't the master, you can easily just switch to the master branch, fix the bug, and push out the code. Then switch back to your feature branch and continue working.

The ability to do that alone is enough for me to make a branch anytime im working on something.

Answer 3

The other answers have made some good points, but there's another big one: what if you publish work to a central repository, which others also access? Perhaps by pushing, perhaps by pull requests, but the upshot is that things that you do get out there. Sticking to the convention of publishing work only from your master branch really helps.

As you said, you can think of master as "the last known working version", but you can also think of it as "my newest stable version". If it's the only one you publish from, then you know that you can't ever do anything crazy to it, but also that you can do those crazy things to any other branch. You have free reign to amend commits, squash them, rebase branches around, all of those ways that Git provide to fix the inevitable oversights we make while developing. And you never have to think, "hm, did I push that work already?" - you haven't, since it's not on your master branch yet. You can also try anything, coding-wise - hack away, commit partially finished work, move around between ideas, whatever you like - and be confident you'll never accidentally show it to anyone else until you say "I'm finished" and merge it to master.

The key part here is the notion of publishing your work. If this were your own private repository, if you realized your master branch was broken in some way, it'd only inconvenience you. But as soon as other people are involved, you could be messing with them too.