Agree on a branching model for development

[malexmave]

I would prefer if this repository would not descend into chaos, file conflicts and edit anarchy. So, I propose the following:

Branching Model

• master: The current stable version. Everything works the way it is supposed to, no unfinished features, "production ready" (in the long run).
• development: The current development version, initially branched from master, merges back into master for new releases. All features are finished and working in here. This branch is used to create new feature branches and to gather in all finished features for the next release version (in the long run).
• feature/[featurename]: Branches from development, merges into development. Each feature has its own branch, each branch is used by only one person (or more, if they coordinate and prevent conflicts together). These branches may contain unfinished or untested code. They are merged back into development once the feature is finished and tested (NOT BEFORE!).

This branching model allows for multiple people to work on different features, using the same files, without getting conflicts or problems with the unfinished features of other people. It was adopted from this blog post and slightly modified.

Hotfixes / Bugfixes

If you have found a bug that is a simple fix without any risk, you may fix it directly in development. If it requires a larger fix and should be rolled out into master instantly ("Hotfix"), create a branch titled hotfix/x.y (x.y being the version number after the hotfix has been applied) from master (!), fix the bug, merge back into master, tag (see below), then merge back into development and notify your fellow coders to merge the fix into their branches.

Tags

Each new release (usually a merge into master) will be tagged with its version number (git tag -a version-x.y), ideally GPG-signed (git tag -a -s version-x.y). The tag message should contain information about new features and fixes in the new version.

Commits

Each commit (no matter which branch) should contain a meaningful commit message. We are already doing a good job with that, let's keep it up.

Good: "Changed xyz.jsm to support new feature Y". Bad: "did some work".

Merges

There are two kinds of merges, for lack of a better word I'll call them "up" and "down".

Merging "up" is merging from a feature branch into development, or from development into master. This should be done only if the conditions outlined farther up apply (features finished and tested).

Merging "down" is merging from development into a feature branch. This can be done to take advantage of the work of someone else that has already made its way into development, but was not present when you started your branch. This can be done at all times, since code in development is, by definition, considered stable.

All kinds of merges should be done using the --no-ff-flag, for the reasons outlined in this article (see "Incorporating a finished feature on develop").

New Policy: Merging up should always be done using the github pull request system. Just do a Repository-internal pull request, give a short description, and merge it using the button in the pull request (or leave it open for discussion, if desired). This documents merges, gives an overview what has changed (lists commits), and allows for annotation and discussions.

Conclusion

Please feel free to suggest changes to this model. I would like to see it implemented as soon as possible, so everyone can get used to the model. It may seem like overkill for pre-alpha code, but it will pay off in the long run, in time saved not fixing merge conflicts, for example.

[opatut]

While I agree on this model being great, there are a few things I want to discuss:

1. Why signing commits? Whose advantage would it be to bring in code with a false mail address? Even if signed, we have no way of knowing there is no malicious code without checking, and if we do find intentionally inserted malicious code, I guess we can all go to hell. If you so want the public to know you approve of the code, sign the tags, due to the git hash mechanism you sign the whole history with it.
2. What about small development fixes, i.e. small changes to the development branch that other developers require, too, to continue their work?
3. What about hotfixes, i.e. small changes to the development branch that should immediately be published to master?
4. Do you suggest keeping branches after they have been merged to understand what feature they came from, or should the commit messages be enough for that?

[malexmave]

Why signing commits? Whose advantage would it be to bring in code with a false mail address? Even if signed, we have no way of knowing there is no malicious code without checking, and if we do find intentionally inserted malicious code, I guess we can all go to hell. If you so want the public to know you approve of the code, sign the tags, due to the git hash mechanism you sign the whole history with it.

Signing commits is just my pet peeve. I like being able to say with relative certainty that a commit came from me (or another person). While you automatically sign the whole history with signed tags, signing single commits gives you the relative certainty that a commit really came from a team member. This does not mean you do not have to check the code, it just means you know who to ask what the hell was going on when a backdoor is found. It is optional, but I have made it my practice to sign every commit I make.

What about small development fixes, i.e. small changes to the development branch that other developers require, too, to continue their work?

If you know with certainty that it will not break anything, make your two line change in the development branch. If you want to implement a new feature, do it in a feature branch. This distinction was not clarified in the original post, I will add it now.

What about hotfixes, i.e. small changes to the development branch that should immediately be published to master?

If you are sure that no new features have been added to development since the last release, do your hotfix on development and merge into master. If not, branch hotfix-0.2.1 (or whatever version number) from master, do your fix, merge back into master and then merge master into development, notifying everyone to merge the hotfix into their feature branches.

Do you suggest keeping branches after they have been merged to understand what feature they came from, or should the commit messages be enough for that?

I don't even know if it is possible to delete branches on github. If I delete my branch locally, it still exists on GitHub...

But in the case that it is actually possible to delete branches on GitHub, I am not sure what the best practice would be. The guide I linked above suggests deleting the branches, I personally don't do that, in general, but I only work with a single digit of feature branches anyway, so it does not get too confusing either way.

If you find a way to delete a branch on GH, let us know ;-).

[opatut]

it just means you know who to ask what the hell was going on when a backdoor is found

And can put this exact team member into a hellofalot of trouble if an unintentional, signed backdoor is found. Or just some exploit. I won't sign my stuff.

If you find a way to delete a branch on GH, let us know ;-).

git push origin :branch-to-delete

Basically pushes "no reference" to "branch-to-delete". Mind the colon (syntax is from:to, i.e. git push origin blahfeature:feature/blah might be required if you broke your branch naming and don't want to rename).

[malexmave]

Modified the policy to include the use of repository-internal pull requests.

Removed the part about signing commits.

[gnomus]

I agree to the branching Model :)

[zetaron]

Agreeing on branching model.

[opatut]

No objections, no further comments, we spoke about this last monday :arrow_right: accepted and closed.