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

Good question.  I'm all ears on this one.

FWIW, that diagram is just a guide -- some common sense and processes that fit your release model also need to be applied.

@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

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...

>> 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.

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.

>> >> 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?

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

   Petr

Thanks Petr.

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