[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :

Hi Luc, All,

Hi Evan,

On Mon, 2017-07-31 at 11:30 +0200, MAISONOBE Luc wrote:

Hi all,

For some times now, some experienced developer (Sébastien), has urged me to
adopt a better branching model for Orekit. Doing everything in master,
except for a few branches from time to time, is not really good.

What do you think?

I would be fine with trying out a new git strategy. I don't have much experience with the different strategies being discussed, but as long as the chosen strategy is documented well I should be able to make my git history look like whatever you all choose. I tend to prefer a linear history (using `git merge --rebase`) but the other folks on this thread have made some good points in favor of having a branchy history. Is there a concern with having a large number of branches in a single repository or deleting old branches?

There should not be really a problem with lot of branches, it is just
an inconvenience for users running "git branches -a". So I would say
we should delete feature branches once merged, and the "git merge --no-ff"
helps for traceability in this case).

So I think we agree. I will set up a "develop" branch for next version,
with the pom set up to "9.1-SNAPSHOT" as the pom already needs to know
this version during development, to avoid confusion with released branches.

I will also revert the pom setting in master branch to the last release
status, and from now on we should *not* commit to master directly,
but should only merge official release branches there.

I will set up a skeleton documentation about this. At first, it will be
really basic (I am on holidays right now, so should not work much).

best regards,

Best Regards,