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

[Glenn Ehrlich <Glenn.Ehrlich@kinetx.com>]

Luc,

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.

- 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).
- 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 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.

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