Git branching scheme

[Beep6581]

The purpose of adopting this scheme is to prevent "management" of branches from getting in the way of development. Developers should always be able to make and commit changes regardless of whether there is a new release being made.

I hope that together we can make this work.

Note: Renaming remote branches is not possible. To "rename" a branch a new one is created and the old one deleted and the remote is set to track the new one. This is risky, even more so when we have open pull requests. I don't know what to expect in reality, considering we're not just using Git but also GitHub. I took the safe option, which was to branch off as described below and leave the original branches in place for now. We can delete the original branches in the future once we're sure everyone has moved on to the new ones.

Closely based on http://nvie.com/posts/a-successful-git-branching-model/ except what they call "master" we call "releases".

• I created branch gtk2 from master, and branch dev from gtk3.
• As of now, dev is the new default branch. Please ignore branches master and gtk3, as if they were deleted - they will be deleted in the future.
• As of now, all new code should use GTK3.
• I will not merge GTK3 code (from the dev branch) into the GTK2 branch (gtk2), nor vice-versa. The GTK2 life support of RawTherapee has ended, though you are free to commit things to gtk2 if you so desire, but remember that the code will not get merged.
• Features are to be developed in feature branches, e.g. locallabgtk3 and pixelshift_gtk3.
• Feature branches will be merged into the dev branch when they are ready, that means tested and stable.
• The dev branch will be perpetually under development.
• New releases will be assembled in release branches. These branches will have a "release-" prefix, e.g. release-5.1. Release branches will be branched-off from the dev branch. "Assembled" means that we will iron things out in those branches, update the release notes and other docs, update the splash screen, fix bugs as well.
• Bug fixes can be committed directly into the release-5.1 branch and then cherry-picked back into dev.
• When the code in release-5.1 is stable enough, it gets merged into the releases branch. The releases branch at that point gets the 5.1 tag.
• The branch release-5.1 gets deleted.

Q: When I clone the RawTherapee repo, which branch will I find myself in?
A: dev.

Q: I make development builds, which branch do I use?
A: dev.

Q: Why call it "dev"?
A: It's clear that it's development, and it's shorter to type. Furthermore, AboutThisBuild.txt for development builds will show that they come from branch dev - it's very clear that this is not a release.

Q: The "A successful Git branching model" link calls the branch master, you call it releases, why?
A: Two reasons. The first is that we already have a branch called master and I don't want to delete it yet for safety reasons, and I don't want to create a new one using the same name. The second reason is that when a user runs a release, they will see a branch name in AboutThisBuild.txt. It would be appropriate for this branch name to be releases.

Q: Are branches releases and release-5.1 the same thing?
A: No, they are two different branches. release-5.1 is temporary and gets merged into releases and tagged, then release-5.1 gets deleted. Branch releases must never be deleted.

Q: Why delete release-* branches?
A: There is no need for them once they get merged into releases. Commits made directly into them should get cherry-picked into dev if necessary.

Q: Why do I still see master and gtk3 when I do git branch -a?
A: Because I could not "rename" them, I had to create new branches based off of them. These master and gtk3 branches will get deleted in the future, once we're sure that everyone is using the new system. Do not commit anything to the master or gtk3 branches - they are dead.

Q: Will there be merge conflicts using this scheme?
A: Yes. Merging releases back into dev may produce conflicts. Nothing unusual.

Q: Do I need to do anything?
A: Get all updates using git fetch --all. If you are working on any feature branches, do one final merge:
git checkout master && git pull && git checkout yourfeaturebranch && git merge master
Or if your feature branch uses GTK3 then
git checkout gtk3 && git pull && git checkout yourfeaturebranch && git merge gtk3
You may also want to delete the local copy of master and gtk3 from your system so that they don't tempt you, git branch -d master and git branch -d gtk3.

[Beep6581]

5.1-rc1 pushed into releases-5.1 branch. Please revise RELEASE_NOTES.txt, so that I can merge into releases and tag in a few hours.

[gaaned92]

@Beep6581 Do you intend to merge back the releases branch into the dev branch in order to have a dev branch git version containing the 5.1 tag instead the 5.0-r1-gtk3 tag as now?

[Beep6581]

@gaaned92 I already have as soon as I released.

[Beep6581]

Oops, I ran a test-compile and didn't push! Pushed now.

[gaaned92]

OK now. Thank you

[Thanatomanic]

This doesn't seem relevant anymore