DANGER WILL ROBINSON!!! THIS IS AN INCOMPLETE DRAFT!!!
This workflow is designed to be as close as possible to the KDE SVN Workflow. It is only recommended to be used for the first week or two of using Git with KDE while you become familiar with the basic Git commands. Once comfortable with the basic commands you should then move on to the Feature Branch Workflow.
In particular this workflow will not use git branches or any remote features, all feature work will be in the local master (the Git name for trunk).
The worked examples given will be for an imaginary app called KFoo in a git.kde.org code repository called 'kfoo'.
More detailed information can be found on the main KDE Git page.
This section documents how to set up Git and your code repository for development.
Follow all the instructions on the KDE Git Configuration page, the instructions given below assume you are using the standard configuration.
You need to copy your central code repository from git.kde.org into your local KDE source directory. In Git this process is called cloning.
To clone your project repository:
cd your/source/dir git clone kde:<project>
In our KFoo example:
git clone kde:kfoo
See the KDE Build Environment page for advice on structuring your source directory.
If you have a slow or intermittent internet connection then you may prefer to download a snapshot tarball to bootstrap your clone. You can copy the required command from the projects.kde.org Repository page for your project, but it will be of the form:
wget -c http://anongit.kde.org/<project>/<project>-latest.tar.gz
This section documents basic actions that are performed within your workflow.
See also the KDE Git Recipes page.
Changing code is no different from when using subversion.
If your bug fix is only for unstable master then no special actions are required, just follow the same steps as the feature development workflow above.
If your bug fix is for a stable branch then this cannot be done without using git branches. The steps required will be given below but not explained in any depth. If possible it is recommended you wait until you are familiar with using the Feature Branch Workflow.
The steps detailed below are very inefficient as they use the same build tree and environment for unstable and stable. A more efficient method is detailed in the Feature Branch Workflow.
To make bug fixes on the 2.0 release you could simply checkout a local copy of the origin/release/2.0 branch and make you bug fixes there:
git branch --track stable4.6 origin/KDE/4.6 git checkout stable4.6 <make changes, build, test> git commit -a <make note of sha5 of commit> git pull --rebase git push origin stable4.6:KDE/4.6 git checkout master git cherry-pick -x -e <sha5 of stable commit> <build, test> git pull --rebase git push origin master:master