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.