WE DID IT! Thanks everyone who helped us crowdfund Loomio 1.0. We love our community! ×

Define a clear git branching model

Discussion

  • Jason Robinson created a proposal: Define a clear git branching model
    1 year ago
  • Jonne Haß agreed.
    1 year ago
  • Florian Staudacher agreed: I agree, but further details have to be worked out
    1 year ago
  • I think the devil is in the details. What do you call “release ready?” Right now it should not go in master until it passes Travis. What else would we do to certify a release version?

    Loading...
  • Sean Tilley agreed: I think this would definitely be useful for stabilizing devolopment.
    1 year ago
  • Billy O'Connor agreed.
    1 year ago
  • Interesting :) Will defo take a look

    Loading...
  • movilla agreed: Yes please :]
    1 year ago
  • Since I see a consensus here, another question came into my mind we need a decision for IMO: How long to keep branches once they are merged? Delete them right away with the merge? Wait a week? Keep them forever?

    Loading...
  • Flaburgan agreed.
    1 year ago
  • Jonne, is there any reason to keep them after the merge? Personally I cannot see any. I smell a proposal :)

    Loading...
  • Jason Robinson agreed: I guess proposal makers are allowed a vote too :)
    1 year ago
  • Hm maybe so that you can reopen a pull request if the merge got reverted?

    Loading...
  • While I could see potential for keeping old branches around, the problem is that they’re mostly kept around indefinitely, and that creates a fair amount of clutter.

    Honestly, a time limit of a few weeks to a month sounds reasonable. It’s enough time to revert back a feature or bad fix, without cluttering things up too much in the long run.

    Loading...
  • The problem is if they are not cleared straight after merging - who will clear them later? :P

    Loading...
  • I dunno, honestly I wouldn’t mind regularly pruning away branches that have been merged and inactive for more than a month.

    Loading...
  • No harm done if some branches are not cleaned ;)

    Loading...
  • I just forked the project, pulled my fork, fixed a bug, git commit -a’d, git push’d, and made a pull request. Should I have forked and then branched from my fork?

    Loading...
  • Hm well, yes, you should’ve followed https://github.com/diaspora/diaspora/wiki/Git-Workflow ;)
    Btw. looks like we need to rework that document in 8 days

    Loading...
  • Well, https://github.com/diaspora/diaspora/wiki/Git-Workflow is pretty clear. :) Getting set up that way now.

    Loading...
  • Less clutter will come also with better communication I guess. What direction it goes, the core , the modules maybe, and so on. I.e. I get courage to delete a branch if I know my wishes are perceived in the dev community. - Just a thought, hope it was clear what I mean.

    Loading...
  • Steven Hancock agreed.
    1 year ago
  • Dave Yingling agreed: Great idea.
    1 year ago
  • OK cool that this passed, I think with the (hopefully) new semantic versioning will offer much clearer base for not just developers to work on but also podmins on what code to use.

    I might have some time tomorrow to write something on the wiki, I guess we can iron out the minor details there (or discuss here and update wiki). If someone else wants to do it of course feel free (note here would be appreciated of course so we don’t both do it).

    Loading...
  • I would just update our existing git workflow to point at the git flow extension, the branching model blog post, file pull requests against the develop branch, update the changelog and remind to use the right branch naming convention. I think we can work out a release workflow once we have to or once we gathered some experience what steps work best.

    I’m yet not sure if we should configure the repos default branch to master or to develop, what do others think?

    Now who wants the honour to run git flow init? :D

    Loading...
  • Oh and one more thing we have to decide (kinda in between this discussion and the versioning one, I’ll keep it here because git flow wants to now it): Should we prefix our version git tags with the common v or not?

    Loading...
  • I am updating the wiki now, will hopefully have the page updated in an hour or so.

    Btw, the model does change the “do not merge, rebase” rule so I am going to remove that. In my opinion merge –no-ff makes total sense. I’ve always wondered why it isn’t default behaviour.

    As for the version prefix, personally I’d say no, but it’s really just eye candy :)

    Loading...
  • The merge do not rebase rule is about not merging master or develop into a branch, not vice versa. And I think it still makes sense, Merge branch develop into develop are still meaningless inside the develop branch.

    Loading...
  • OK maybe I didn’t get the whole thing, anyway let’s iron the instructions out :)

    Loading...
  • OK I updated the short version and the intro - please guys can you give comments on whether it is on the right track and whether it is clear for anyone with basic knowledge of git?

    I can update the longer version to match once we have agreed on the basic principles.

    Oh and someone with rights to the diaspora github should probably init the git-flow branches (git flow init).

    Loading...
  • That blog post nails it ;)

    Looks quite good already.

    New naming convention would be feature/issuenumber-description or git flow feature start issuenumber-description, where issuenumber is optional if there’s no issue.

    The git flow feature finish is actually done by merging the pull request and not by the contributor.

    I’d phrase it “issue a pull request to the develop branch”, not for.

    Loading...
  • So Jonne you think it’s better that instead of doing “git flow feature finish” the contributor does “git flow feature publish” and then does a pull request for the branch?

    Works for me if no one has objections let’s do that then.

    Loading...
  • That’s out of question actually, letting him merge to his develop branch and PR from there makes it impossible to do more than one concurrent PR per repo. And you'’ve got fun if your PR is rejected.

    Loading...
  • Ok updated and will progress to update the long instructions section then

    Loading...
  • Page updated.

    Btw, how does this model affect testing and Travis etc? Now that development head is on develop branch and master is only for releases.

    Loading...
  • We should build both, develop and master and maybe add both batches to the readme IMO.

    Loading...
  • It’d probably be useful to hit up the Dev list and the stream about changes that we’ve tweaked how we do branching, just so that everyone’s on the same page.

    If you want, I can make an announcement through DiasporaHQ also. :)

    Loading...
  • Okay, Sean announcement time! :D

    Can you please also switch the default branch of the repo to develop over at Github? Thanks!

    Loading...
  • I’ll get right on it. :)

    Loading...
  • DiasporaHQ and GitHub have been updated. I’ll hit up the Dev list, too. :)

    Loading...
  • @Jason excellent work on the wiki page, I think the picture (while it might be a little complicated) does a good job of helping explain the workflow to anyone who isn’t already familiar with git flow.

    Loading...
  • Just a thought - if develop branch is the default for the repository and someone checks it out via “git clone git://github.com/diaspora/diaspora.git”, the default active branch will be develop instead of master.

    Do we really need to set up develop as the default repo (even if it is development head, it doesn’t imho have to be default)? At least if we do then we need to update install instructions as well so that pod installers use master, not develop.

    Loading...
  • Good thinking. We should make the instructions clear to use the master branch to deploy from. I think Hans is working on an install script of sorts for Ubuntu packaging, that might need to be updated to use master branch as well.

    Loading...
  • I’m kinda in between about the the default branch too. The pros are that PRs go by default against it and an IMO nicer looking (more activity) start page if you drop to our repo the first time. Also if you start browsing the code as interested contributor you’ll less likely duplicate work. That git clone one is a big downside though. Since we don’t need to update anyone about it (initial default upstreams keep that way), lets try out how often we run into this, support wise, I’d say.

    Loading...
  • FYI:
    Rackspace sued for hosting GitHub

    Um…this is why I suggested to house the code elsewhere as a backup measure…

    Loading...
  • From a quick look at the patent titles they patented what git does, not what github does. So don’t know where we would be safer. But let us stop about that in this discussion as it’s completely OT ;)

    Loading...

Current decision

Previous decisions

  • Define a clear git branching model

    Closed
    Closed 1 year ago
    Proposed by Jason Robinson 1 year ago
    Outcome

    Accepted and taken in to use - documented at https://github.com/diaspora/diaspora/wiki/Git-Workflow

    Currently AFAIK master is whatever was pushed last by a developer who has rights to push to master.

    We need a better clear branching model that allows anyone to pick out whatever they need, be it a stable branch, the current development head or a feature branch.

    I suggest we follow the clear branching model explained in this post:
    http://nvie.com/posts/a-successful-git-branching-model/

    Some highlights;
    1) Master always contains the release code, in addition releases are tagged
    2) Development head is called the ‘develop’ branch. This is where developers with sufficient access merge pull requests and feature branches
    3) (Optional in future, maybe when things have evolved) Release branches are branched from develop to form candidates for a release
    4) Feature branches are branched from develop to work on larger features

    36% of members stated their position (9/25)

    Positions

    Florian Staudacher I agree, but further details have to be worked out
    Sean Tilley I think this would definitely be useful for stabilizing devolopment.
    movilla Yes please :]
    Jason Robinson I guess proposal makers are allowed a vote too :)
    Dave Yingling Great idea.
    [Show members who have not yet decided]