Define a clear git branching model

Development
1

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

Proposal: Define a clear git branching model

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

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

Votes:

  • Yes: 9
  • Abstain: 0
  • No: 0
  • Block: 0

Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.

3

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?

4

User Gitflow? https://github.com/nvie/gitflow

5

Interesting :slight_smile: Will defo take a look

6

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?

7

Jonne, is there any reason to keep them after the merge? Personally I cannot see any. I smell a proposal :slight_smile:

8

Hm maybe so that you can reopen a pull request if the merge got reverted?

9

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.

10

The problem is if they are not cleared straight after merging - who will clear them later? :stuck_out_tongue:

11

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

12

No harm done if some branches are not cleaned :wink:

13

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?

14

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

15

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

16

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.

17

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

18

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? :smiley:

19

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?

20

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