Question

I’m new to Git and to branching. Within our team, we have a bunch of websites that require simple maintenance (adding a new page, fixing some links, etc). The commits would normally contain all of the requested functionality. I am not sure if we should create a branch, or if we can just commit to master? After all, the commits are named and make it clear what we have done. I feel that branches actually create more complexity for such simple tasks. Or am I mistaken?

Answer 1

As a rough guideline:

Commits exist to update the state of a branch, and branches exist as alternative views of your codebase.

If it makes sense that your changes can be seen as moving “forward in time” of the master branch, then you should use commits only. If you are going to do something that is an “alternate reality” of the master branch, you should make a different branch.

In this case, if I understand your situation, I would guess you’re really truly updating the state of your codebase, so I would just commit your changes.

In this respect Git is similar to any SCM. What makes Git different with branching is that branches are very easy to create and (somewhat) easy to merge. That means that a common workflow is to branch master into a work in progress for a new feature, then make your edits. When you’re satisfied, you can merge your branch into master. This is just an improvement on straight commits – you are creating an “alternate reality” of an unstable master, improving it, then merging it back into the real master – but the net effect is the same: your commits in the alternate reality end up landing in master as if you had always made them there. The end goal of all this runaround is that your commits show a linear march through time of changes.