Development/Git/Recipes

Git Recipes

Brief recipes for common use cases.

Working with existing remote branches

Remote branches are branches created on the main KDE repository. These may be a stable branch that you need to do bugfixes on, i.e. the 4.6 release, or a feature branch based on master.

To see what local and remote branches exist:

git branch -a

Create a local branch that tracks a remote branch:

git branch --track <local-branch> <remote-branch>
git checkout <local-branch>

When you want to add your commits to the local branch, first update your local to the current remote state, then push your commits:

git pull --rebase
git push origin <local-branch>:<remote-branch>

Working with stable branches

For kdelibs, kdepimlibs, kde-runtime, kate, konsole and kde-workspace, the remote stable branches are named as follows:

origin/KDE/4.6

For these modules, to set up a local stable branch to track the remote stable branch:

git branch --track KDE/4.6 origin/KDE/4.6
git checkout KDE/4.6

To then push changes to the remote stable branch:

git push origin KDE/4.6:KDE/4.6

In other projects the remote stable branches are named as follows:

origin/4.6

For these modules, to set up a local stable branch to track the remote stable branch:

git branch --track 4.6 origin/4.6
git checkout 4.6

To then push changes to the remote stable branch:

git push origin 4.6:4.6

Creating / Deleting Remote Branches

To create a new remote branch simply push your current branch to it:

git push origin <local-branch>:<remote-branch>

To delete a remote branch is a little obscure:

git push origin :<remote-branch>

Cherry Picking

Cherry picking is a way to copy a single commit from any local or remote branch to your current local branch.

When cherry picking between stable and unstable branches, use the following form:

git cherry-pick -e -x <original-commit>

Note you can add any remote repository to your local clone if cherry-pick from.

Common Options

-e will allow you to edit the commit message to add any extra details and to change the BUG/CCBUG/FIXED-IN messages.

-x will automatically add the original commit number to the end of the commit message to enable better tracing and to simplify merging. Only do this if the original commit was already published in a public repository, e.g. your are forward porting or back porting the patch.

-n will cherry-pick the changes but not commit them to the new branch. This is very use full if you need to do further work on a commit.

Interactive Rebasing

If you have many commits in a branch that you want to clean up before pushing to the central repository, then you can use interactive rebasing to merge, split, delete, re-order or edit them.

To work with all commits to a branch:

git rebase -i <parent-branch>

where <parent-branch> is the branch you want to rebase onto. This is usually the branch that you based the original local branch off or are remotely tracking, but can be any branch you want.

To work with just the last x commits you made to a branch:

git rebase -i HEAD^x

See http://book.git-scm.com/4_interactive_rebasing.html for full details.

Viewing What You've Changed

To see the difference between your tracked but unstaged changes and the current branch (including your not-yet-pushed commits)

git diff
git diff <filename>

To see the difference between your staged changes and the current branch (including your not-yet-pushed commits):

git diff --staged
git diff --staged <filename>