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

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

Le 25/08/2017 à 12:20, Guilhem Bonnefille a écrit :
>
> 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)

Please, note that you perhaps can add:
[merge]
  ff = no
[pull]
  ff = only

(not tested)

> 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