|
|
| (37 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| == Simple KDE Git Workflow ==
| | {{Out of date|This page that shows up high in search results in 2025 was last updated in 2016 and marked "THIS IS AN INCOMPLETE DRAFT!!!". Instead read '''[[Infrastructure/GitLab]]'''.}} |
|
| |
|
| This Git Workflow is designed to be followed by a new Git user who needs a simple workflow for bug fixes and new features in a manner similar to the old SVN workflow.
| | :''View history if you want to see what it said, but don't bother discussing it.'' |
| | |
| Note that each module may choose to adopt a more complex workflow and you should check with your modules maintainers if this is the case.
| |
| | |
| The worked examples given will be for an imaginary app called KFoo in a git.kde.org repository called 'kfoo'.
| |
| | |
| == Set-up ==
| |
| | |
| This section documents how to set up Git and your code repository for development.
| |
| | |
| === Configure Git ===
| |
| | |
| Follow the [[Infrastructure/Git/Configuration|KDE Git Configuration]] page.
| |
| | |
| === Clone your repository ===
| |
| | |
| You need to copy your 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 [[Getting_Started/Build/Environment|KDE Build Environment]] page for advice on structuring your source directory.
| |
| | |
| If you have a slow internet connection then you may prefer to [[Getting_Started/Sources/Snapshots|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
| |
| | |
| == Basic Actions ==
| |
| | |
| This section documents basic actions that are performed within your workflow.
| |
| | |
| See also the [[Infrastructure/Git/Recipes|KDE Git Recipes]] page.
| |
| | |
| === Create a Work Branch ===
| |
| | |
| By default when you first create a repository clone there is only a single local branch called 'master'. It is not good practice to do development in master, it is better kept clean for reference. Instead all work should be performed in a new local branch, even bug fixes.
| |
| | |
| To see what local branches you have:
| |
| | |
| git branch
| |
| | |
| To see all local and remote branches:
| |
| | |
| git branch -a
| |
| | |
| To create a new local branch:
| |
| | |
| git branch <new-branch>
| |
| git checkout <new-branch>
| |
| | |
| This will create a new branch based on whatever local branch you were already in, i.e. that includes all the history of the original branch, which can be useful in building a hierarchy of dependent changes.
| |
| | |
| You may prefer to base your new branch on a remote branch such as the master branch of the central repository so you can integrate any new development. This is called 'tracking' and is recommended for most branches:
| |
| | |
| git branch --track <local-branch> <remote-branch>
| |
| | |
| For our KFoo example:
| |
| | |
| git branch --track new-bar-feature origin/master
| |
| | |
| === Commit Your Changes ===
| |
| | |
| === Push Your Changes ===
| |
| | |
| == Local Feature Development ==
| |
| | |
| This example workflow is for locally working on new features in unstable branch and pushing them to the central repository.
| |
| | |
| This workflow is only recommended for small features or where you are the only developer on a project.
| |
| | |
| == Remote Feature Development ==
| |
| | |
| This example workflow is for working on new features in a feature branch hosted on the central repository.
| |
| | |
| This workflow is recommended for larger features or where there are many developers on a project.
| |
| | |
| == Local Bug Fixing ==
| |
| | |
| This example workflow is for locally fixing bugs in both the stable and unstable branches and pushing them to the central repository.
| |
| | |
| In Git, stable branches are just regular branches that have special meaning to a project and a possibly a special naming scheme to distinguish them. For example, the KFoo app may have the following branches on the central repository:
| |
| | |
| origin/master
| |
| origin/feature/hot-new-stuff
| |
| origin/feature/cool-newer-stuff
| |
| origin/release/1.0
| |
| origin/release/1.1
| |
| origin/release/2.0
| |
| | |
| Making bug fixes to stable branches is thus fundamentally the same as working on a feature branch, but with the added step of needing to add the bug fix to the stable branch as well.
| |
| | |
| Two workflow's are described here, a basic workflow for small apps or where bug-fixes are infrequent, and an advanced workflow for larger apps or more frequent bug-fixes.
| |
| | |
| === Basic Bug Fix 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 bug-fix-2.0 origin/release/2.0
| |
| git checkout bug-fixes
| |
| | |
| However, switching between unstable and stable branches inside a single Git repository can lead to large rebuilds if the unstable branch has diverged too much from the stable branch. On a small app this overhead may be small enough to not be a problem in this case you would just use the feature workflow.
| |
| | |
| This workflow uses the [[http://techbase.kde.org/Infrastructure/Git/Configuration#Multiple_Work_Branches|git-new-workdir script]] to create separate work directories and builds for stable and unstable branches. This depends on you setting different up KDE Environments for the separate builds.
| |
