celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject GIT flow
Date Fri, 27 Mar 2015 11:41:09 GMT
Hi all,

With the transition to GIT I think it is also time to discuss how we are
going to use it. In the GIT discuss thread I mentioned GIT-flow, and I
still think it makes sense to use it as describe on [1].
This means:

* Do work on a local feature branch, ideally identified by a issue number.
This also makes sure we have an actual issue to track.
* If needed, this local branch can be pushed, for example when people need
to collaborate on that specific feature.
* When a feature is done, merge it into the develop branch. NOTE: THIS IS
DIFFERENT THEN BEFORE! So we do not push directly to master, only to
* When preparing a release, a release branch is created.
* If the release is done, changing from that branch are merged back to
develop, but also to master. This means that changes made on the release
branche are merged back to develop, so development can continue. But the
merge to master means that master always stays stable.
* [1] also mentions hotfixes, and while they are important, I think we
should always make a release if a hotfix is needed.

So the following branches play a role:

* master: Branch on which the latest release can be found
* develop: Branch on which development is done
* feature/CELIX-###_description: Branch on which a new
feature/bug/patch/... is implemented
* release/v#.#.#: Branch on which a release is done, this includes
packaging, touching up headers and other files etc.
* hotfix/CELIX-###_description: Branch on which a hotfix is made, which
will be based on master. A hotfix (or multiple hotfixes) should result in a
new release.

I'm now using SourceTree, and it has support for gitflow as described above.

As I said, this is how git-flow is described. If there is a (good) reason
to do things differently please reply to this mail!

[1]: http://danielkummer.github.io/git-flow-cheatsheet/

Met vriendelijke groet,

Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message