Define a clear git branching model

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.

OK maybe I didn’t get the whole thing, anyway let’s iron the instructions out :slight_smile:

So we’d go like this? http://ctoinsights.wordpress.com/2012/06/29/git-flow-with-rebase/

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

https://github.com/diaspora/diaspora/wiki/Git-Workflow

That blog post nails it :wink:

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.

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.

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.

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

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.

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

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. :slight_smile:

Okay, Sean announcement time! :smiley:

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

I’ll get right on it. :slight_smile:

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

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

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.

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.

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.

FYI:
Rackspace sued for hosting GitHub

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