Re: [Orekit Developers] Using git-flow branching model?

[Guilhem Bonnefille <guilhem.bonnefille@c-s.fr>]

Le 25/08/2017 à 10:24, MAISONOBE Luc a écrit :
>
> Sébastien Dinot <sebastien.dinot@c-s.fr> a écrit :
>
>
>>
>> To avoid oversight, you can add the following lines in your
>> ~/.gitconfig:
>> ------------------------------------------------------------------------
>> [merge]
>>     ff = no
>> ------------------------------------------------------------------------
>>
>
> I have set up this configuration parameter, however, it has a nasty
> side effect.
>
> The attached image shows what just happened to me after having synched
> my workspace with
> the master repo, in order to include Maxime latest fix.
>
> On my own workspace (the blue line on the left), I created a local
> branch fixing issue 355,
> 3 days ago (commit 18c6856), merged it to my local develop branch
> (which with --no-ff created
> a merge commit 4ac5f8e), and pushed my local develop branch to origin
> (the master repo on
> orekit.org).
>
> Then I created a local branch fixing issue 356, 2 days ago (commit
> a177f45), merged it to my
> local develop branch (which with --no-ff created a merge commit
> 73fd58a), and pushed my local
> develop branch to origin.
>
> Then Maxime created a local branch fixing issue 354, yesterday (commit
> 04e4b61), merged it to
> his local develop branch (which with --no-ff created a merge commit
> a769ff7), and pushed his
> local develop branch to origin.
>
> So far, so good.
>
> At this level, my local develop branch was still at commit 73fd58a, so
> I had to synched my
> copy to take Maxime fix into account. At this level, I would have
> prefered *this* merge
> to be a fast-forward and to directly jump to a769ff7 instead of adding
> yet another merge
> 57a789a. As this spurious commit is only on my local repo, I will
> remove it manually and
> make sure my local develop branch head point to commit a769ff7.
>
> To conclude, enforcing ff = no in git configuration ensures you don't
> miss merge commit,
> but does it too well, and sometimes even when you do not want it.
>
> I tried to use ff=only (equivalent to --ff-only), but it seems to act
> the same as -ff
> when merging an issue fixing branch back, so it is not what we want. I
> don't know if it
> is possible to enforce git to insert merge commits when the merged
> branches have different
> names.
>
> We will have to be carefull and either set ff=no and remove the extra
> merge commit
> manually or not configure merge automatically and take care to insert
> these merge
> commits for the issue fixing and feature branches ourselves.
>

Using gitflow, you have to:
- use --no-ff when merging a feature branch onto develop branch
- use --ff-only when updating/syncing (aka pulling) a shared branch
(like develop or master)

The simplest way to ensure this process is to document all command in
all situations.
The reference gitflow documentation
(http://nvie.com/posts/a-successful-git-branching-model/) try to do
this. But it is incomplete as there is no fetch or pull command
described. However, this is fundamental to avoid unecessary merge
commits: you have to update develop branch before merging your
terminated feature onto it.
So, at least, a documentation of all commands in all situations is
necessary to avoid such situation.

An other approach is to use tools to handle the gitflow. I have no
experience on this, but I know there is some extensions for this (for
example https://danielkummer.github.io/git-flow-cheatsheet/) and some
GUI implement this model (for example GitKraken
https://www.gitkraken.com/). But, as I said, I never used these tools (I
like knowing what I do and I accept spending lot of time reviewing and
reworking my commit history) so I don't know their side-effects.

An other approach can be to use tools like GitLab or GitHub. Such tools
allow to merge the branches directly online. Doing this, we are
necessarily merging the lastest versions of published branches.

OTH

begin:vcard
fn:Guilhem Bonnefille
n:Bonnefille;Guilhem
org;quoted-printable:CS Syst=C3=A8mes d'Information;Division Espace
adr:;;Parc de la Grande Plaine - 5, rue Brindejonc des Moulinais - BP 15872;Toulouse Cedex 05;;31506;France
email;internet:guilhem.bonnefille@c-s.fr
title:Architecte
tel;work:05 61 17 62 84
url:http://www.c-s.fr/
version:2.1
end:vcard