This page assumes the following:
- The kdelibs repo is kdelibs.git. This is where releases comes from
- The kdelibs repo has branches 'master' and 'X.Y' version number branches
- These branches can not be force pushed
- All other branches *can* be force pushed by default
- This is to encourage pushing of 'work in progress' at all. If force pushing is not allowed or discouraged, it is a disincentive to put work branches on a public repo.
- Branches whose name starts with "shared_" can't be force pushed.
--Tnyblom 11:18, 16 February 2011 (UTC) Better to use the namespace "shared/"
- This is a way to ease collaboration by making it hard to accidentally force push a branch which many people are working on.
- If possible the person who started the branch can force push it.
- Another way of 'locking' branches like this may be better. I just assume there is a good way.
- There would also need to be a convenient way to 'unlock' it
- Merging and merge commits are rare and unnecessary for 'feature branches'/'topic branches'/'work branches' or any other name people might use for the same thing - work that is not yet in a branch where a release will be made from. This workflow advocates rebasing instead, even of public branches, at sensible times.
- If force pushing is disallowed on the main repo, work branches can be put in a kdelibs-work.git repo instead.
Use case: Someone wants to use master for day-to-day use or testing.
git clone kde:kdelibs git checkout master # This use case always uses master. git pull --rebase # Periodically. Really the --rebase isn't needed if this person never makes commits, but consistency is good in case they ever do
Use case: Someone wants to use stable for day-to-day use or testing.
git clone kde:kdelibs git checkout 4.6 # This use case always uses the stable branch. git pull --rebase # Periodically. # Event: KDE 4.7 released git checkout 4.7 # This use case always uses the stable branch. git pull --rebase # Periodically.
Use case: An enthusiatic user wants to get started fixing some bugs
git clone kde:kdelibs git checkout master # Or 4.6 depending on the personal preference and the bug. # Fix bug git commit # Test git pull --rebase # get commits that have been made in the mean-time ... git push # ... and put my commit in there too. # My commit goes in *on top* No need to introduce the merging # concept or a merge commit git pull --rebase # Periodically
Use case: Someone wants to work on a feature that takes longer than half a day and should therefore be in an archived branch.
# Day 0: git clone kde:kdelibs git checkout master # Start feature git checkout -b new_proxy_model git commit git commit git commit git push origin new_proxy_model # Send the new_proxy_model branch and commits # to the kdelibs repo # The next (and Nth) day git checkout new_proxy_model # If not already on the branch. git commit # Discover bug needing fixing in master git checkout master # fix bug git commit git pull --rebase git push origin # Put the bug fix on the public repo (official kdelibs) git checkout new_proxy_model git rebase master # Put my work 'on top' of the latest in master, which includes # the bug fix. # Continue working on feature git commit git commit git push -f origin new_proxy_model # Put my now rebased work into the repo # Do the same thing for as many days as it takes until the feature is done. # On the day the feature is done: git checkout master git pull --rebase # make sure I have the most recent work from the master branch git checkout new_proxy_model git rebase master # put my work on top of the most recent work from the master branch git checkout master git rebase new_proxy_model # Update master to include my work git push origin # Update master on the official repo. Now anyone who pulls master from git # will get my work. git branch -d new_proxy_model # remove the old branch name locally. git push -f origin :new_proxy_model # remove the old branch name on the remote repo.
Use case: Two or more developers want to collaborate on a feature.
# The same as above, except that all interested developers have an agreement that # the branch will not be rebased. This could be enforced by a naming convention # eg, "stable_" and a server side hook preventing forced pushes on those branches. # eg: Alice works on the feature: [email protected]$ git commit [email protected]$ git commit [email protected]$ git push # Bob gets alices work [email protected]$ git pull # Bob does work of his own [email protected]$ git commit [email protected]$ git push # Alice can now get bobs work # Bob fixes a bug in master as above, and pushes that to the public repo # Bob then brings the bug fix into the feature branch he and Alice are working on git checkout collaborative_feature git merge master git push origin collaborative_feature # Anyone who pulls the branch gets the bug fix. # Repeat until the feature is done. # The day it is done: git checkout collaborative_feature # Optionally create a 'clean' stream of commits on top of the current latest in the official master. git rebase master # Either push it to the repo again for review or include it in master now. git checkout master git rebase collaborative_feature git push # The new feature is now in the official master. git branch -d collaborative_feature git push -f origin :collaborative_feature
To keep the branch up to date with master Alice and Bob merge master into their branch whenever they want. They might also decide that they will rebase on every Sunday (or whatever). This is just an agreement between the two of them. Charlie knows that kdelibs branches can be force pushed by default, so he doesn't base any work on the collaborative_feature without letting Alice and Bob know that he wants to be a collaborator.
The rebasing of this long lived feature branch at the end is optional but encouraged.