Another Git branching question -- on the purpose of the master branch.

Hi,

I would like to continue in the Git branching discussion from http:Q_27382249.html.  Firstly, I would like to thank evilrix for the link to "A successful Git branching model" (http://nvie.com/posts/a-successful-git-branching-model/).

My question is related to the master branch in the model.  Have a look at the picture from the article:

 hotfix-branches1.png

It is quite obvious, that the hotfix should be merged to the "develop" branch as we want to fix the bug in all future versions.  However, can it be always merged to the "master" branch?  Think about the situation when the version 2.0 is already in the master.  Then the 1.2.1 cannot be placed there and it must be kept somewhere else.  In other words, how do you solve the situation when more versions must be maintained/fixed in parallel?

Thanks for your time and experience,
   Petr
LVL 30
peprAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

threadyCommented:
Good question.  I'm all ears on this one.
0
evilrixSenior Software Engineer (Avast)Commented:
I don't know about you but my master is always a representation of the most recent stable release. In general nothing gets merge back into it until the next stable release; however, a hotfix is a special case... in its own right a hot fix can be considered a mini-release. It is a release that is nothing more than a fix for a critical bug. In that sense it makes perfect sense to merge it back to master.

I'm not sure I see why you think this is an issue? If you'd already merged version 2 then one would assume that either the same code change applies to that version (in which case it would/should also be in master) or that code has changes such that the patch need not be applied, in that case it doesn't apply to the current release nor master.

Am I over simplifying your question?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
evilrixSenior Software Engineer (Avast)Commented:
FWIW, that diagram is just a guide -- some common sense and processes that fit your release model also need to be applied.
0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

peprAuthor Commented:
@evilrix: I do not want to disagree.  I just want to understand the model.  Better to say, the model must reflect the kind of software.  This way I try to imagine the software that fits with the model.

Our application looks more like this:


branching.png
0
peprAuthor Commented:
Sorry, I wanted to continue...

Actually, we have the master and develop branches being equal (the yellow and the dark blue points are identical).  Also the releaseXXX and the hotfixXXX can be merged the same way.  Then the releases are distinguished from the others only via tags.

The earlier presented model separates the development steps from the releases not by tags only, but by separation to another branch.

I will continue, but I would like to hear your opinions...
0
evilrixSenior Software Engineer (Avast)Commented:
So you never forward port hotfixes? Doesn't that mean if you fix a critical defect in one release it still exists in the next (assuming you've not replaced the code)?

At the end of the day, there is no perfect process for release control. It's all about what works best for the type of product you are developing and what your release cycles are like. The "best practice" for Git branching is just a guide but it won't work for everyone because software development isn't a one size fits all.

I don't think your branching practices would work for us but then we probably operate a completely different development cycle to your company.

We only develop in working branches and once a feature is complete and tested it is merged back into master. We then tag master when we release and only create a branch from that tag if we need to fix anything in the released code whilst development continues in branches from master.

If we fix something in a release branch it is always forward ported back into master. We consider master to be exactly that, the master branch that every thing else derives from. It is the one definitive branch that is always of release quality. We can cut a new release from master at any time.

0
peprAuthor Commented:
>> So you never forward port hotfixes?

Yes, we do.  The image is not complete.  I wanted to emphasize that we need to keep more release branches alive and that it cannot be done only via the master branch.  I just want to collect the experience of others.  I did not chart our branching scheme.  I only tried to draw how the model from the article could be adopted to our needs.  

>> We only develop in working branches and once a feature is complete and tested it is merged back into master. We then tag master when we release and only create a branch from that tag if we need to fix anything in the released code whilst development continues in branches from master.

I probably do not have the "genuine" experience, because we run two separate CVS repositories at two computers (one on mine, the other on the colleagues one).  The differences are sent via e-mail based on our human agreement.  This way, the trunk is actually my trunk, but I consider it shared.  I do work in some branch and then merge the result back to the trunk.  When my colleague sends something new, I do copy/commit it to his branch and only then I merge it to the trunk.  

... and we are only two, which means we are lazy sometimes believing that problems can be solved manually if needed. Well, I am lazy sometimes and do copy/commit the sent sources directly to the trunk.  Also, I do sometimes changes (development) directly in my (private) trunk.  We do not expose the repository to anyone else, so nobody cares where the code came from.

>> If we fix something in a release branch it is always forward ported back into master.

... into master or into develop?

>> We consider master to be exactly that, the master branch that every thing else derives from.
>> It is the one definitive branch that is always of release quality. We can cut a new release from master at any time.

Putting these two together, the master must be derived from the develop.  Then master+develop must be the main branches, not only one of them.

0
evilrixSenior Software Engineer (Avast)Commented:
>> The differences are sent via e-mail based on our human agreement
Sounds like a good case for using Git (amongst other things it can also automatically generate patch e-mails).

>> ... into master or into develop?
Well, if we issue a hotfix we consider that a release so we just treat it as one. The hotfix becomes a release and the release is merged back into master.

>> Putting these two together, the master must be derived from the develop.
We merge development branches back into master once they are of release quality. When we release we tag master. We only branch from master for a release if we need to fix anything. Anything we fix is then merged back into master so it will also be in the next and forth-coming releases. At any one time our master is a release quality branch from which we can cut a new release (although any release cut does go through testing first).

Put another way, everything revolves around our master but we never actually work in master. It is just the definitive branch for all finished and tested changes.
0
evilrixSenior Software Engineer (Avast)Commented:
NB. I should clarify that we don't actually release code to external customers (all our customers are internal) and we don't just have one repo, we actually have about 30+, each for a different product.
0
peprAuthor Commented:
>> >> The differences are sent via e-mail based on our human agreement
>> Sounds like a good case for using Git (amongst other things it can also automatically generate patch e-mails).

Yes.  And it was once the thing that caught my eye when I first looked at Git.

>> Well, if we issue a hotfix we consider that a release so we just treat it as one.
>> ... all our customers are internal

I see.  Then you do not need to manage more version branches.  Once the major number increases, all the earlier versions and modifications can be considered obsolete and they are replaced by the new version, right?  Then the head of the master always contains the most fresh and working version, and separation of the develop branch makes sense.  

On the other hand, once you support more release branches, some of their heads may actually be newer than the master branch.  Then increasing the major number of the version does not cause the other supported release branches obsolete, and the modifications should not be merged to the master.  The changes (fixes) definitely should be forward and/or back-ported but it may not always be done via the merging mechanism.

>> we don't just have one repo, we actually have about 30+, each for a different product.

Is it possible (with Git) to share some repository by more projects in the sense that -- say -- one repository is dedicated to some library, and the library is used by more projects that use the library?
0
evilrixSenior Software Engineer (Avast)Commented:
>> Then you do not need to manage more version branches.
Yeah, we do. Most of what we release goes into production and in a lot of cases these services are running different versions on different production servers. We can't just release things as a drop of a hat because these are mission critical services. New releases can only be pushed as and when the point-product teams are ready.

Whilst our customers are internal our release processes are such that they may as well be external. Everything has versioned and all versions are maintained in release branches. The only difference is we are more able to react quickly in the case that a hotfix of a critical issue is required.

>> once you support more release branches, some of their heads may actually be newer than the master branch
The master always lags behind because we only merge into it once something is ready for release. If we fix anything in a release branch it will be merged back into master if the code is still relevant.

>> but it may not always be done via the merging mechanism.
We always merge... Git makes it simple. In cases where there are merge conflicts we have to resolve them but this doesn't happen too often.

>> Is it possible (with Git) to share some repository by more projects in the sense that
Yes, Git supports sub-projects (similar to SVN externals).
http://book.git-scm.com/5_submodules.html

We don't do this though as it introduces a tight coupling between projects. Instead, each project is built against a packaged version of the library of the minimum version required to support it. In this respect we treat all our libraries as upstream projects and we only build against what has come downstream from the package maintainer (even though that is us).

In dev we generally link against the master version of all our libraries and when a new release is issued a corresponding library release is created where dependencies have changed. If no dependencies have changed we just pin against the previous stable library release.
0
peprAuthor Commented:
Thanks, evilrix, for sharing the experience.  I will probably have more questions in future.  Have a good time.

   Petr
0
evilrixSenior Software Engineer (Avast)Commented:
Thanks Petr.
0
peprAuthor Commented:
Hi evilrix, I have a new question -- possibly for you.  Please, have a look at http:Q_27466745.html
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Version Control

From novice to tech pro — start learning today.