Adopt GitFlow process View as Markdown

26 марта 2012 г. 4:30 пользователь Stas Malyshev
smalyshev@sugarcrm.com написал:

Hi!

Main problem is that our current workflow doesn't allow branch-only
changes. I.e. if you make a bugfix and want to stay it in PHP-5.3 only
you can't merge 5.3 with 5.4 anymore, otherwise your bugfix will go
there.

Why would you want a bugfix to be in 5.3 but not in 5.4? Can you give an
example?
I can see it if the code had substantial change there so bugfix no
longer applies. In this case, I would try the merge, see it fail and
resolve it as "all ours". It shouldn't take longer than 10 mins. Though
it you have ideas how to improve that without disrupting the rest of the
process and the common use case, you are welcome.

For example this commit

http://git.php.net/?p=php-src.git;a=commit;h=8d0760f38a9d3dabb3a31d1d47f85827d27d0db4
by Ilia was intentionally commited in PHP-5.3 only, maybe Ilia will
describe better. It was then accidentally merged into PHP-5.4 by
Hannes (which broke something in PHP-5.4) when he was merging his own
changes which merge made a lot of confusion.

We should really deal with this problem first before diving further,
since it will have great impact on the whole working process with git.
If we can live with simple git merge - it would be simply awesome.

1. use cherry-picking in one repo. This has big downside (as dsp
   pointed) that we can't use git annotate, bisect and other commands
   assuming that commit is introduced in repository only once.

bisect is a bit weird now btw, since it seems to be a bit confused by
5.3-5.4 merge that happened not when it thinks it did - so if you try to
bisect changes in 5.4 branch only, you will get some very old changes
in. You can quickly go through that, marking them as good, but still not
ideal situation.

Yep, already tried bisect and it doesn't seem work good at least for
php-5.3 branch.

Okay, since I'm not too familiar with release process, assume
following (please, correct me if I'm wrong):

• PHP 5.3 can't have features, only bugfixes

True.

• PHP 5.3 can have bugfixes that are merged upstream (PHP-5.4 and
  master) and bugfixes that should stay only in PHP-5.3

Not entirely true - 5.3 code can have bugfixes that aren't merged up,
but that would not be the common case. Example - bugfix regarding magic
quotes or safe mode, which are not in 5.4.

So it's still possible to have not-merged up bugfixes. That means that
we should take that into account.
I'm just trying to figure out our needs to better understand what
needs to be done then.

• PHP-5.4 and master can have bugfixes and features that are merged
  upstream (master) and bugfixes/features that should stay only in
  current branch

5.4-only fixes very unlikely, as master and 5.4 are very close today. If
we ever do big changes in master this is a possibility, as described
above, but still won't be a common case - unless we rewrite our engine
completely, which doesn't seem to be likely.

• All branches are have regular releases

True, except for master.

In gitflow you have 4 branches:

• master - contains only production ready releases, nobody commits here
  directly
• develop - main development branch, all work usually is get merged here
• feature/<name> - feature/bugfix branches for separate bugfixes and
  features. Merged into develop.
• hotfix/<name> - same that feature branches but is urgent and is
  always merged into master and develop. For example, when security
  release is issued, this fix should go into release and into main
  development branch.
• release/<name> - pre-release stability branches, for bug-fixes only.
  Merged into develop and master (making a new release). When you have a
  release branch, you can't commit into develop (so hotfixes go here
  too, if we have release branch).

I don't like that "can't commit into" thing - the main advantage of git
as I see it that you can manage release branch and dev/stable branches
separately and not have the situation of asking people to sit on their
code for 2 months while release is being stabilized.

Sorry, I messed this up. You actually can commit into the develop, new
features go there, while bugfixes should go in release branch. If you
want you can merge release branch into develop anytime you want, it's
just should be done at least once when release branch is closed.

Make a bugfix in 5.3
$ git flow feature start bugfix PHP-5.3 # create a bugfix branch based
on 5.3
$ git flow feature finish -k bugfix 5.3-develop
Bugfix get merged into 5.3-develop - this should be implemented since
gitflow supports only 1 develop branch for now. -k says to keep branch
after finish, since we'll need it to merge upstream

Why would we need bugfix branch in our repo here? I would say keep it in
your own fork, test it, show it off, get it ready - then merge it into
php repo. What is the reason for us to keep halfbaked fix branches in
our repo?

Merge bugfix from 5.3 repo to 5.4
First, rebase branch against 5.4
$ git rebase --onto develop-5.4 bugfix~<num> bugfix
Where <num> is number of commits in your branch. I know it sucks, but
that's how it works :)

I don't like it. Too fragile and too easy to mess up.

In general, this scheme seems quite complex and I don't really see what
the benefit of it would be. Could you explain why would we want to do
this?

Canonical gitflow is very straightforward and clean. Here it seems
complex because I tried to apply it on the fly to PHP needs. PHP adds
complexity because we support several release branches at once, while
in gitflow there's only one release branch in the given moment of
time. That's why my first thought was to divide our release branches
in separate repos, this way we could start use gitflow in its current
state.
Advantages:

• clean separation of release branches, main development and hotfix
  branches
• if you use git-flow tool you don't have to remember what branch
  should you start your feature/bugfix, where to merge when it's ready,
  it's all already thought through and automated, that's really cool
  especially when you make a release

I strongly recommend you to read original article
http://nvie.com/posts/a-successful-git-branching-model/ and spend half
an hour on this hands-on tutorial http://vimeo.com/16018419, so you
can really feel how it works.

No doubt that we can't use gitflow as-is, i.e. we would need to modify
it to suit our needs, but it can realy simplify our life.

Disadvantages:

• Cli oriented toolbox. As Matthew pointed out you can't use git-flow
  with git GUI tools and support on Windows seems not so good
• Written in bash. There was attempt to rewrite it into python, but it
  seems things stopped there about year ago:
  https://github.com/nvie/gitflow/tree/feature/python-rewrite
• Some time (not much) is needed to understand the system

--
Regards,
Shein Alexey

--

I've personally never used the Gitflow utility as I've found it largely
unnecessary. The branching model is really quite simple once you get the
hang of it. Of course, pure Gitflow wouldn't work because we have two main
development branches instead of one and they frequently interact with one
another.

The problem is that merge conflicts could occur if merged changes affect
code that is different between 5.3 and 5.4. And we do NOT want merge
conflicts being resolved on the main develop branch! With this many
people, that could get.... ugly.

The Gitflow model uses a temporary "release" branch to merge develop into
master. What if we took a similar approach with merging changes into both
dev branches? Here's what I'm thinking:

git checkout -b Feature-Name 5.4-develop
(build your feature, commits, etc)
(do a fresh pull on 5.3 and 5.4-- ALWAYS do a pull of any branch you're
about to merge into!!!!)
git checkout 5.4-develop
git merge --no-ff Feature-Name
git checkout Feature-Name
git checkout -b Feature-Name-5.3 Feature-Name
git rebase 5.3-develop
(resolve merge conflicts, if any)
git checkout 5.3-develop
git merge --no-ff Feature-Name-5.3
git branch -d Feature-Name
git branch -d Feature-Name-5.3

Basically, what the above does is creates a temporary "duplicate" branch
for the feature and then rebases that duplicate off of the other version to
be merged into (rebase tends to minimize merge conflicts and make them
easier to deal with than merge IMHO). This way, we're not polluting the
main develop branches in the event of a merge conflict. This also
preserves the original feature branch for the duration of the merge process
in case we need it as a reference point.

So what this means is that we'd be using a "parallel" Gitflow model in
which there are 2 master branches and 2 develop branches (one for 5.3 and
one for 5.4). Merging into each master branch would just follow the
existing Gitflow process from each respective develop, since those two
won't(?) ever need to interact directly.

What do you think? If it sounds confusing let me know and I can throw
together a flowchart that should help illustrate the concept.

--Kris