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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

Maybe a stupid question, but how do I check out the needed libraries for  
digiKam?
I found the digikam, kipi-plugins and the *-docs repos, but none of the  
lib repositories.

The only thing I found is a repo for libkface and libkipi.
Do I need to checkout all those libraries one-by-one now, or is there some  
kind of container repository?

Andi


On Sat, 05 Mar 2011 16:17:02 +0100, Marcel Wiesweg <[hidden email]>  
wrote:

> 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
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Maybe a stupid question, but how do I check out the needed libraries for
> digiKam?
> I found the digikam, kipi-plugins and the *-docs repos, but none of the
> lib repositories.
>
> The only thing I found is a repo for libkface and libkipi.

All libraries have now been migrated, it's always kde:libxy

> Do I need to checkout all those libraries one-by-one now, or is there some
> kind of container repository?

Yes, there is:
git clone kde:digikam-software-compilation
./download-repos
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel