In git, why do I need to work on a branch instead of the main branch?

Question

I continue to read about how you always need to work with a different branch than the main one. As soon as I complete my work, I will combine them. Why is this better than just working on the main branch?

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

Answer 1

The main advantage of working in a branch is that you can commit to an isolated function while maintaining the ability to fix it on the main server. You can also do things like "squash" does with rebase -i if you think that multiple commits should really appear as one commit for other users.

You can also work with several experimental functions at the same time. You can later decide to abandon this function or implement it differently, and you can simply delete this branch without cluttering up your main story.

I often have several experimental function branches in any given project. Even in order to quickly write down some thoughts in the form of code, they are very useful.

Answer 2

Here is one example that often happens to me:

Suppose you are working on a feature that is extensive, so it is going to take a lot of commits. You are about halfway there, so the code is unstable, but it goes well.

Now a critical error has been found in the production version of the code (presumably your lead branch). If you make a mistake against the leading branch, how do you fix it and push the fix without pushing the broken incomplete code?

If you worked on your new feature in a branch that is not a wizard, you can simply simply switch to the main branch, fix the error, and pop out the code. Then return to your function branch and continue.

The ability to do this on my own is enough so that I can make a branch at any time when I have gained something.

Answer 3

Other answers gave some good points, but there is another big one: what if you publish the work in a central repository that others also refer to? Perhaps by clicking, perhaps by request, but the result is what you do. It actually helps to stick to a publishing convention only from your workshop.

As you said, you can think of the host as the "last known working version", but you can also think of it as "my last stable version." If this is the only one from which you publish, then you know that you can never do something crazy, but also that you can do these crazy things in any other industry. You have fluency to amend commits, distribute them, rebuild branches around, all of the ways that Git provides to correct the inevitable flaws that we make during development. And you never have to think: "Hmm, have I already done this job?" - You do not, since it is not yet at your workshop. You can also try something, coding-wise — hack, complete a partially finished job, move between ideas no matter what you like — and be sure that you will never accidentally show it to anyone else until say "I finished" and combine it into a master.

The key part here is the concept of publishing your work. If it was your own repository, if you understood that your main branch was broken in some way, this is just not convenient for you. But as soon as other people are involved, you too can communicate with them.