[Digikam-devel] thoughts on branches with git

[Marcel Wiesweg]

Hi,

now that we are using git and have merged all branches still coming from SVN, 
we can now readjust habits and have a look at what workflows git allows with 
branches.

Compared to git, SVN never really had branches; we had code in different 
directories, and a very limited merge commoand.
It needs some time to get used to git concepts; in doubt, I always recommend 
to use gitk to get a visual feedback about local and remote branch settings.

git offers a lot of flexibility to do things as you want (but also to break 
things, also in the remote repo). Therefore the following five workflows are 
not exclusive.

1) Simple local changes
You may have noted that "git pull --rebase" does not work as soon as you have 
any local changes. The sequence it then
git stash; git pull --rebase; git stash pop
I always found it cumbersome, but it is a clean solution, to avoid 
intermingling your local changes with rebase conflicts.
I still did not manage to write a bash script for this sequence (which would 
not stash without local changes, and which which would not git-stash-pop when 
the pull-rebase has had conflicts)

2) Local branch
I developed the grouping feature last week using this approach. It was only a 
few days of work, no need to share before it's finished, but neither ready to 
commit the first parts before the rest was finished.
Assuming you have local changes and want to continue your work in a local 
branch now:
git checkout -b myBranch
<commit, work, commit>
You have finished and want to commit. Not by a merge: If you have made, say, 
10 commits, you want to add these 10 commits on top of master, and discard 
your local branch.
In the meantime, master has received new commits. Get latest master and pull:
git checkout master
git pull
Now, rebase your work on top of master. This rewrites your commits.
git checkout myBranch
git rebase master
Then it's time to add all your commits, one by one, to master:
git checkout master
git rebase myBranch
git push
Clean up after you:
git branch -d myBranch
The effect on the remote repository is a linear string of commits, as if 
developed directly on master. Your local branch has never been public.

3) Public branch with rebase.
This concept is very similar to (2): In the end, there will be a linear line 
of commits on top of master, and no branch remain in the remote repository.
The main difference is that the branch lives in the remote repo, and 
development can be shared. At least when development is finished, the commits 
are rebased, which rewrites history: Afterwards, the branch cannot be pushed. 
Anyone who would have based his work on an intermediate commit will be lost.
The branch can be force-pushed though, if allowed on the remote side. That 
means social communication is required when rebasing.
The workflow is described here
http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea#Use_case:_Someone_wants_to_work_on_a_feature_that_takes_longer_than_half_a_day_and_should_therefore_be_in_an_archived_branch.
Note: I dont know if branches are already force-pushable in KDE repos; I 
assume not, and then this does not work!

4) Stable branch
Development continues on master, and a stable branch is branched off.
Backporting of fixed is done using git cherry-pick.

5) Development branch
Development on master is incremental, but large, architectural changes are 
done in a branch, possibly breaking everything. Development time is long. The 
branch will be preserved in history for all times. Over time, changes from 
master are merged intermittently. (This is what we did with the 
development/2.0 branch)

Marcel