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

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


Glenn Ehrlich <Glenn.Ehrlich@kinetx.com> a écrit :


Luc,


Hi Glenn,
Wow. Huge topic. I went through this last year when developing the git strategy for a set of tools at KinetX last year. Here’s my observations / advice from that. 

From what I see, with your answer, Sébastien answer and Hank answer,
it seems improving our git strategy is worthwhile.
- Before picking any sort of new git branching model, I found it good to review what my development, testing, QA, release, and maintenance goals were. I asked myself “do I want the ability to continue developing & releasing a 3.y.z line while still allowing formal bug fixes in a 2.y.z line?” vs “do I want everything to go into a cumulatively growing branch/branches?”. This decision point allowed me to see at a glance which git models would work for me vs which ones wouldn’t. It also helped me figure out which discussions had merit vs which ones didn’t. For example, there’s a fair number of people who do not like git-flow and after making this decision point, I was able to understand whether their view point made sense to me or not. (For the record, I did want to have formal x.y.z releases (i.e., semantic versioning, http://semver.org) and I did want to have formal development on a say, 3.y.z line while allowing me to formally make bug fixes in a 2.y.z line; I found git-flow had some good ideas to steal for this but I didn’t adopt it whole hardily). 

I want to be able to release an update of an old version if needed.
As Orekit is used in operational projects, it sometimes (albeit rarely)
that they need a fix or a backport despite not jumping to the last
published version. a typical example is for missions already flying
and using Orekit 7.x; they cannot jump to either 8.0 or 9.0 because
that would imply changing the math library and changing the Java version.

So being at least able to release 7.3 despite we are now at 9.0 is
useful.
- Another decision point I had was, “what do I want my commit history to look like?”. I.e, what do I want my git log to be able to tell me about the state of the repository? For me, I wanted to be able to cleanly see where all the x.y.z branching & feature development was going on and I wanted to cleanly see how all the development was merging along. For me, I decided that lots of git merge –no-ff made sense because I wanted to see the merge points. This tends to make the git history more “messy” but it also allows you to see clearly what’s going on. Another decision point in this is when / how / if you want rebases. If you want super-clean, linear flowing history than you’ll want rebasing and fast forward merges. It all depends on what you want your history to look like. I.e., make your history look like your process. A lot of people like having simpler commit history and a simpler log. Nothing wrong with either approach though. 

I also like seeing the tracks of features introduction, but I often
fall short of doing it properly. I either forget to set up a feature
branch or forget about the --no-ff flag when merging a branch when
I did not forget to create it. So at the end I can only blmae myself
when trying to recover my own tracks and have to read commit messages.

So I am interested in being more consistent and use feature branches
and --no-ff to improve the history.
- I found it super helpful to formally document my process, which included command line examples. This helped me make sure I wasn’t making any mistakes when following my process. - I also found it helpful to write scripts to automate as much as possible. Of course, some models have supporting automation, so that’s an advantage of going with one of those, but you have to be willing to go along with the process it wants to automate for you. - I was initially quite apprehensive about changing my git strategy. What if I choose poorly? I then realized that 1) I could easily try out some various strategies and see how they work, and 2) if I chose poorly, I could just use some tactical branching & tagging to mark a transition point and then change strategies. I actually wound up doing this when I found I needed to support maintenance on a 2.y.z line while moving forward with a 3.y.z line. I just took the lumps, marked stuff in the git repo, adjusted my scripts, updated my formal process document and went forward.
I see Sébastien replied to you while composing my reply, discussing the importance of several release branches, which I discuss above as well, and I can see that what I wound up with is very similar to what Sébastien links to. My opinion, for what it’s worth, is that what he links to would be a good strategy for you to move to. 

Yes, Sébastien link is really interesting. And knowing him and the OTB
project, I am pretty sure everything is already scripted, so it could help
if we could borrow their scripts and Continuous Integration process.
Maybe if I bribe Sébastien with a coffee...

best regards,
Luc



Glenn
On 7/31/17, 2:31 AM, "orekit-developers-request@orekit.org on behalf of MAISONOBE Luc" <orekit-developers-request@orekit.org on behalf of luc.maisonobe@c-s.fr> 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.

    He suggested using git-flow
    (<http://nvie.com/posts/a-successful-git-branching-model/>,
    <https://www.atlassian.com/git/tutorials/comparing-workflows>,
    <https://github.com/petervanderdoes/gitflow-avh/wiki>,
    <https://danielkummer.github.io/git-flow-cheatsheet/>).
The third and fourth link above even propose a few extensions to help using 
    git flow. The third link seems to be the one installed on Debian systems.
What this branching model would imply is that there would be a develop branch 
    that is evolving rapidly and the master branch would be more stable as it
    will change only when releases are made.
External users that want to get the latest released version would therefore be able to retrieve it directly from git, using the master branch. External 
    users that want the latest bleeding-edge version with finished features
    would retrieve the develop branch.
People wanting to set up nightly builds (someone asked for it a few months 
    ago on these lists) could use either the master or the develop branch, or
    even both branches in separate builds, depending on their needs.
Orekit team developers ready to work and contribute on unfinished features 
    would use feature branches, some internal to their private repository in
their work machine, some pushed to the public repository at orekit.org for 
    collaborative work.

    What do you think?

    best regards,
    Luc