[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

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

Posted on 2011-10-08
14
Medium Priority
?
541 Views
Last Modified: 2012-05-12
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
0
Comment
Question by:pepr
  • 7
  • 6
14 Comments
 
LVL 1

Expert Comment

by:thready
ID: 36936675
Good question.  I'm all ears on this one.
0
 
LVL 40

Accepted Solution

by:
evilrix earned 2000 total points
ID: 36939091
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
 
LVL 40

Expert Comment

by:evilrix
ID: 36939097
FWIW, that diagram is just a guide -- some common sense and processes that fit your release model also need to be applied.
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
LVL 29

Author Comment

by:pepr
ID: 36939671
@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
 
LVL 29

Author Comment

by:pepr
ID: 36939681
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
 
LVL 40

Assisted Solution

by:evilrix
evilrix earned 2000 total points
ID: 36939884
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
 
LVL 29

Author Comment

by:pepr
ID: 36941564
>> 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
 
LVL 40

Assisted Solution

by:evilrix
evilrix earned 2000 total points
ID: 36941800
>> 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
 
LVL 40

Expert Comment

by:evilrix
ID: 36941803
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
 
LVL 29

Author Comment

by:pepr
ID: 36941913
>> >> 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
 
LVL 40

Assisted Solution

by:evilrix
evilrix earned 2000 total points
ID: 36942034
>> 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
 
LVL 29

Author Closing Comment

by:pepr
ID: 36943782
Thanks, evilrix, for sharing the experience.  I will probably have more questions in future.  Have a good time.

   Petr
0
 
LVL 40

Expert Comment

by:evilrix
ID: 36945757
Thanks Petr.
0
 
LVL 29

Author Comment

by:pepr
ID: 37199947
Hi evilrix, I have a new question -- possibly for you.  Please, have a look at http:Q_27466745.html
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

INTRODUCTION Subversion is a fantastic version management and software configuration management tool for teams and individuals to manage software applications. It offers many advantages over it's CVS ancestor such as it's built-in compatibility w…
Introduction This article is the first in a series of articles about the C/C++ Visual Studio Express debugger.  It provides a quick start guide in using the debugger. Part 2 focuses on additional topics in breakpoints.  Lastly, Part 3 focuses on th…
The goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…
The viewer will learn how to use the return statement in functions in C++. The video will also teach the user how to pass data to a function and have the function return data back for further processing.

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question