RFC: Repository workflow - branches and tags

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Repository workflow - branches and tags

Earnie Boyd
I'm currently thinking about mingw.org-wsl but this may apply to other
repositories as well.

* The master branch is the baseline and should contain only known working code.
* A branch is created that represents the next version release as a
working release, e.g 4.0-dev.
* A tag is created that represents the released version, e.g 4.0.
* The working branch should be merged to the master branch just prior
to release and tagging.
* A feature freeze (typically 2 to 4 weeks prior to planned release
date) would result in a new branch tag representing the next release
+1, e.g. 4.1-dev.
* The working branch should be merged to the master branch just prior
to the feature freeze.
* The master branch should be merged to the next release + 1 branch
just after a new release making it the new working branch.
* The previous working branch is removed from the repository leaving
the current working branch.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Repository workflow - branches and tags

Charles Wilson-8
On 9/27/2012 1:08 PM, Earnie Boyd wrote:

> I'm currently thinking about mingw.org-wsl but this may apply to other
> repositories as well.
>
> * The master branch is the baseline and should contain only known working code.
> * A branch is created that represents the next version release as a
> working release, e.g 4.0-dev.
> * A tag is created that represents the released version, e.g 4.0.
> * The working branch should be merged to the master branch just prior
> to release and tagging.
> * A feature freeze (typically 2 to 4 weeks prior to planned release
> date) would result in a new branch tag representing the next release
> +1, e.g. 4.1-dev.
> * The working branch should be merged to the master branch just prior
> to the feature freeze.
> * The master branch should be merged to the next release + 1 branch
> just after a new release making it the new working branch.
Stop here.
> * The previous working branch is removed from the repository leaving
> the current working branch.
With git, you really should never delete a branch that is publicly
exposed (that is, either pushed to the official public repository, or
exposed on your own machine to allow others to pull directly from your
computer.  Also, and this is important too, you should /never/ rebase a
publicly exposed branch, for much the same reason -- all the commit IDs
change in the rebased branch, and any merged-to branch that has a
reference to the old commit ID...

If you do, then you run into issues with certain commit IDs being
unaccessible except via explicit sha1 checkouts, and leads to all sorts
of problems.

Don't worry too much about branches proliferating. Since from the "home
user's" perspective they are "remote branches" you don't have to track
the old ones (or, if you are tracking one, you can stop tracking it
locally once it goes obsolete) and then they won't clutter your displays
or your commands.

Here's a couple of good links concerning on workflow issues with git, as
used by libtool:

http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00056.html

especially this one (embedded above) on the gnulib list:

http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268

--
Chuck


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Repository workflow - branches and tags

Earnie Boyd
On Thu, Sep 27, 2012 at 6:15 PM, Charles Wilson wrote:

> On 9/27/2012 1:08 PM, Earnie Boyd wrote:
>> I'm currently thinking about mingw.org-wsl but this may apply to other
>> repositories as well.
>>
>> * The master branch is the baseline and should contain only known working code.
>> * A branch is created that represents the next version release as a
>> working release, e.g 4.0-dev.
>> * A tag is created that represents the released version, e.g 4.0.
>> * The working branch should be merged to the master branch just prior
>> to release and tagging.
>> * A feature freeze (typically 2 to 4 weeks prior to planned release
>> date) would result in a new branch tag representing the next release
>> +1, e.g. 4.1-dev.
>> * The working branch should be merged to the master branch just prior
>> to the feature freeze.
>> * The master branch should be merged to the next release + 1 branch
>> just after a new release making it the new working branch.
> Stop here.
>> * The previous working branch is removed from the repository leaving
>> the current working branch.
> With git, you really should never delete a branch that is publicly
> exposed (that is, either pushed to the official public repository, or
> exposed on your own machine to allow others to pull directly from your
> computer.  Also, and this is important too, you should /never/ rebase a
> publicly exposed branch, for much the same reason -- all the commit IDs
> change in the rebased branch, and any merged-to branch that has a
> reference to the old commit ID...
>
> If you do, then you run into issues with certain commit IDs being
> unaccessible except via explicit sha1 checkouts, and leads to all sorts
> of problems.
>

Do you have a reference for this?  I would want to stop the master
from delivering the branch reference on a fresh clone, is that
possible without deleting the branch?

> Don't worry too much about branches proliferating. Since from the "home
> user's" perspective they are "remote branches" you don't have to track
> the old ones (or, if you are tracking one, you can stop tracking it
> locally once it goes obsolete) and then they won't clutter your displays
> or your commands.
>

One reason to keep a development branch would be for a simple patch
for the current version.  I'll need to ponder it more.

> Here's a couple of good links concerning on workflow issues with git, as
> used by libtool:
>
> http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00056.html
>
> especially this one (embedded above) on the gnulib list:
>
> http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268

I've read this once but need to do some rereading to understand it better.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Repository workflow - branches and tags

Earnie Boyd
After Chuck's response I decided to go looking for other ideas.  I
found what I think will work and take care of Chuck's concerns at
http://nvie.com/posts/a-successful-git-branching-model/.  Based on
that write up I've created a develop branch from which all other
branches are to be created.  A release branch will be created for
finalizing the release changes; things like updating the news,
updating the version number, etc.  Just prior to the release the
release branch is merged to the develop branch and then the develop
branch is merged to the master branch.  A feature branch is usually a
local branch but could be a public branch if more than one person is
working the feature or the work plans to span a length of time.  The
feature branch is created directly from the develop branch and merged
back to the develop branch.  A hotfix branch is done as an immediate
release to fix a regression caused by a release.  The hotfix branch
could be created from the develop branch or the master branch but must
always be merged to the develop branch and the develop branch to the
master.  The feature branches would need to rebase after a release and
hotfix are merged to the develop branch.

This brings us to ChangeLog entries.  I tend to like to create the
ChangeLog entry at the time I commit in the feature or bug fix branch.
 This might not be best though and I'm thinking that we should create
a ChangeLog entry at the time of merge to the develop branch.  What we
want to avoid are a bunch of conflicts with the ChangeLog which is why
doing the ChangeLog at the time of merge would be best.  So for
tracking ChangeLog entries we add an entry in .gitignore for
ChangeItem.  ChangeItem is used during the feature development to
record the commits.  Then just prior to the merge to develop you pull
the develop branch changes, rebase the feature branch, make the
ChangeLog entry based on ChangeItem, commit the ChangeLog entry,
change back to develop branch, merge the feature branch, and then push
the develop branch.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Repository workflow - branches and tags

Keith Marshall-3
On 07/10/12 19:40, Earnie Boyd wrote:
> After Chuck's response I decided to go looking for other ideas.  I
> found what I think will work and take care of Chuck's concerns at
> http://nvie.com/posts/a-successful-git-branching-model/.

Interesting read.  A couple of comments:

* It advocates deleting branches, (even release branches), at certain
points in the work-flow.  I completely agree with Chuck on this one;
this has to be a big no-no, for any branch which has ever been shared.
(FWIW, Mercurial branches are permanent; once created and committed,
they can *never* be deleted, other than by deletion of the repository.
OTOH, Mercurial also provides a bookmark feature, which is somewhat
similar to git branches, or CVS branch tags; these *can* be deleted).

* As it's written up, the model doesn't readily support any more that
one actively distributed release at any instance in time.  Making each
release branch permanent would resolve that issue; it would also make
his use of "master", (as an exclusive progression of release points),
redundant, (since the tip of each release branch would represent its
associated release point).  Thus, why not just use "master", as seems
more conventional, as the main development branch, and cut a permanent
release branch at each release point?

> Based on that write up I've created a develop branch from which all
> other branches are to be created. A release branch will be created
> for finalizing the release changes; things like updating the news,
> updating the version number, etc. Just prior to the release the
> release branch is merged to the develop branch and then the develop
> branch is merged to the master branch.

That's not what the article advocates.  It says merge the "release"
branch to "master", and to "develop".  I guess it should make little
difference either way, but if you do away with the redundant use of
"master", (or rather, use "master" as your main development branch), and
keep each release branch permanently, then you can simplify the
work-flow to a single merge from the "release" branch to the "master"
(development) branch, at each release point.

> A feature branch is usually a local branch but could be a public
> branch if more than one person is working the feature or the work
> plans to span a length of time. The feature branch is created
> directly from the develop branch and merged back to the develop
> branch.

No issues there; this is effectively what my "gui-dev" branch in
mingw-get represents.  The only caveat I wish to note: since it's
a published branch -- it exists in origin -- it should remain in
existence permanently.

> A hotfix branch is done as an immediate release to fix a regression
> caused by a release. The hotfix branch could be created from the
> develop branch or the master branch

Hmm.  Logically, a "hotfix" branch should be created from the release
branch to which it relates...

> but must always be merged to the develop branch and the develop
> branch to the master.

...and it should be merged back to the tip of that release branch, when
done.  The tip of the release branch *could* then be merged back to the
development branch, if the issue which the "hotfix" addresses continues
to affect the current state of development.

> The feature branches would need to rebase after a release and hotfix
> are merged to the develop branch.

I find the whole concept of rebasing to be rather scary; if you do it on
a published branch, you're sure to cause grief for someone down the line.

> This brings us to ChangeLog entries...

See my comment in the "mingw.org-wsl .gitignore" thread.

--
Regards,
Keith.

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Repository workflow - branches and tags

Earnie Boyd
On Wed, Oct 10, 2012 at 8:17 AM, Keith Marshall wrote:

> On 07/10/12 19:40, Earnie Boyd wrote:
>> After Chuck's response I decided to go looking for other ideas.  I
>> found what I think will work and take care of Chuck's concerns at
>> http://nvie.com/posts/a-successful-git-branching-model/.
>
> Interesting read.  A couple of comments:
>
> * It advocates deleting branches, (even release branches), at certain
> points in the work-flow.  I completely agree with Chuck on this one;
> this has to be a big no-no, for any branch which has ever been shared.

I can live with it.

> * As it's written up, the model doesn't readily support any more that
> one actively distributed release at any instance in time.  Making each
> release branch permanent would resolve that issue; it would also make
> his use of "master", (as an exclusive progression of release points),
> redundant, (since the tip of each release branch would represent its
> associated release point).  Thus, why not just use "master", as seems
> more conventional, as the main development branch, and cut a permanent
> release branch at each release point?
>

So something like, master->MAJOR.MINOR-dev->do work and commits->test
work->merge to master->prepare release and tag MAJOR.MINOR-rls->create
new MAJOR.MINOR-dev.

clone master
branch MAJOR.MINOR-dev (e.g. 4.0-dev)
checkout MAJOR.MINOR-dev
do work and commits.
checkout master
merge MAJOR.MINOR-dev
prepare release
tag MAJOR.MINOR-rls (e.g. 4.0-rls)
branch next MAJOR.MINOR-dev (e.g. 4.1-dev)

>> A hotfix branch is done as an immediate release to fix a regression
>> caused by a release. The hotfix branch could be created from the
>> develop branch or the master branch
>
> Hmm.  Logically, a "hotfix" branch should be created from the release
> branch to which it relates...
>

So for this we would simply

checkout released MAJOR.MINOR-dev (e.g. 4.0-dev)
do the fix work and commit
checkout master
merge released MAJOR.MINOR-dev
prepare release
tag as MAJOR.MINOR.PATCH-rls (e.g. 4.0.1-rls)

>> The feature branches would need to rebase after a release and hotfix
>> are merged to the develop branch.
>
> I find the whole concept of rebasing to be rather scary; if you do it on
> a published branch, you're sure to cause grief for someone down the line.
>

Here is an excellent article
http://git-scm.com/book/en/Git-Branching-Rebasing explaining it.  But
the caution is to rebase only private branches not the ones on origin.

My workflow above didn't list the pushes to origin, it was assumed to happen.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr