Like some other folks here, I am relatively new to git and am trying to
figure out a good workflow for our development team, and appreciate any
thoughts & suggestions.
We have several project teams that require to work in isolation on their
respective branches. (a project here consists of a set of related
features). These project branches may be created at different times and
therefore may be created from different point on the master. At the time
the project branches are created, we do not know the release note, nor
which other projects may be released along with it. Builds occur from the
individual project branches and code is tested in independent environments
for each.
A month or two down the line, the management and business teams decide that
some projects need to be released on a specific date and we then scramble
to merge those projects together into an integration branch from where the
build would occur and subsequently deployed to an integrated environment
for further testing. Developers continue to modify code on their individual
project branches and frequently merge to the integration branch.
x - x - x - x - x - x <-
"integration branch" branch
x - x - x / <- "project B" branch
/ /
x - x - x - x - x - x - x - x - x - x - x - x - x - x - x <- "master" branch
\ \
x - x - x \ <- "project A" branch
x - x - x <- "project C" branch
An issue we frequently face is that a project may need to be pulled out of
the release after it has already been merged into the integration branch
several times. In our currently SCM tool, this is very painful. We normally
resort to creating a new integration branch and merging the remaining
project branches to it, thereby requiring that developers re-resolve all
the conflicts they had already resolved previously on the original
integration branch, a task which is not only very painful but very time
consuming as it is equivalent ot a big bang merge far into the project
schedule, and often delays the project release due to all the additional
work.
Some things we have or are considering to help ease the pain:
1. Implementing feature toggles - This is being discussed with the
development managers but the initial though is that it may be very tough to
implement with the way the code has been structured today. However, this is
still being pursued
2. Use of the BPF workflow (See links below) and "git rerere" - This is
what I am leaning towards. However the workflow and the tools developed
assume that all feature/project branches that are part of a single release
& the integration branch for that release are all branched from the same
point on master, which is not the case in our environment
*Blogs/articles discussing the BPF (Branch-By-Feature) workflow*
- http://dymitruk.com/blog/2012/02/05/branch-per-feature/
-
http://www.acquia.com/blog/pragmatic-guide-branch-feature-git-branching-strategy
-
http://www.ivoverberk.nl/blog/2013/11/08/git-workflow-automated-branch-per-feature/
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
