Define a clear git branching model

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

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

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?

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

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

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

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

Okay, Sean announcement time! :D

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

I'll get right on it. :)

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

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

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