loading...

Hunt bugs down before they are merged!

Nicolas Mattia on March 07, 2019

I discuss a few reasons why catching bugs in master is more expensive than before they are merged, try to explain why some people think this isn'... [Read Full]
markdown guide
 

I appreciate this article more than many others I’ve read because it comes from experience. I’m just trying to learn git and haven’t really been very involved with it yet.

In your scenario everything is happening with the master branch. New features are merged there and the CI is connected to it. So I get the point of this that bugs should be taken care of before being deployed. I like how you illustrated that. Very easy to understand. I also agree that taking care of bugs before merging is very important and means less mess later.

I do have a question that hopefully you can comment on...

If one goal is to avoid bugs in deployment, then why not have a separate branch for development?

Again I have little experience but I believe something like this:

  • branch master - deployment version connected to CI
  • branch develop - features get merged into this branch; testing is done before a release is merged into master; all new features are branched from here

I'm just genuinely curious because I'm trying to learn and wonder what reasons a workplace may have in choosing a certain workflow.

 

Hey Dan!

I’m just trying to learn git and haven’t really been very involved with it yet.

Nice, you're in for a treat! It's a bit confusing at first. After a while you start realizing how amazing it is.

If one goal is to avoid bugs in deployment, then why not have a separate branch for development?

If you have a branch for development that is not connected to CI, you might run into a lot of issues: it means that people can basically commit anything to that branch, without ensuring that the tests are run!

When you decide to "release" that branch by merging it into the master branch, you'll run the tests, and some might fail. If a test fails there you face the "Hunt" problem I mentioned above: any one of the commits that you added to the development branch -- since the last release to master -- may be the culprit.

Another somewhat related workflow is to have a development branch where tests are run and fork a new branch for each "release". You might add a few features to the development branch, running the tests every time, and (say) once a month fork a branch. This new branch might be release-april-2019.

Quite a few large projects operate this way; those release- branches are basically feature freeze, and no new bugs are introduced. It becomes a bit tricky when bugs are found: you need to first fix them in the develop branch and then "backport" them to the release branches. If the develop branch and the release branch have diverged too much, you may have to implement the fix twice.

Hope that answers your question!

 

Thanks Nicolas, that does answer my question and of course leaves me with more to think about. You are right that git is a bit confusing at first. I understand how it works a lot more now - but the one thing I don't find online much is anything written about weird scenarios that happen when using git with a team. Mostly I have found tutorials and such - which are good to an extent but my mind naturally wonders... "what if this happens...?" Your article has helped to answer some of those questions. Good stuff. Thanks again!

 

And even more expensive if it makes it to production! and Even cheap if you find it during "Design" :)

code of conduct - report abuse