For quite some time this subject was on my mind. It’s weird but true. There are times when using a git branch make more sense. A great example of this would be when you want to create a new feature on the project you’re on. Another would be when you need to fix a reported bug or better yet when your site needs to be fixed right away so you create a hotfix branch.

The great part about using branches is that it can also help keep things fairly organized. Developing in branches also ensures bugs and vulnerabilities don’t make their way to the source code and impact users, since testing and finding those in a branch is much easier. Especially when doing pull requests or when you have automation setup using GitHub Actions, CircleCI, Buddy, or even GitLab CI/CD.

Naming things is hard

In software development, much like a lot of things, giving things a name can be difficult. The name of a function or variable can help when reading the code. There are times when using simple letters makes it really difficult to understand what the code is doing. This is a great segue into thinking about how to name branches when working with version control. I say it this way because there are other version control systems available out there.

One of the methods I’ve come across and do like using is having two branches from which to start from.

  • Main
  • Develop

From there you would create other branches as needed like:

  • Feature
  • Hotfix
  • Issue
  • Release

And of course others which would depend on your desired workflow; not everybody will use those naming conventions either. One variation I’ve see is using prod and stage for the two main branches where one is meant strictly for production, or live, code and the other – stage – meant more for basing any work from so as to keep the primary branch as clean as possible.

Versioned branches

Yes, versions. Using branches can also be useful when you are doing releases because you can better port changes back to that version. You know your starting point and can work from there and you can even run git bisect in a much better way as well because you know where that possible bug was introduced. Using the command will give you a really great way of resolving that pesky little critter or at the very least getting a better idea of when it was introduced.

One of the easiest ways of doing that, of course, would be to have the repo on your local machine. Then you would create the branch with the command:

git checkout -b v15

Super simple, right?

It can be made slightly easier too if you are using a GUI. Personally I haven’t used one in such a long time that I would get lost in the interface. Just be sure to use which ever tool you are most comfortable with in order to get things done.

I’m sure there are other methods of keeping track but this was how I learned.