There are other additional color-related features which are discussed in the fine documentation that comes with Git.

If you experience problems with colorized output, try adding the following to your ~/.bashrc

R needed for git colours

export LESS="-RIM"

First steps with Git

Getting started with Git for KDE is fairly easy. First, run the following:

git clone <REPOSITORY URL>

The <REPOSITORY URL> for the KDE-Qt repository is discussed on the Qt Prerequisites wiki page.

This creates a local copy of the upstream repository, in your local master branch. Always keep the master branch for tracking the upstream repository, and create other branches to do your work in. That way, it will be straightforward to push selected changes upstream, rather than having to push all your changes every time.

Create a work branch (in this example, called mywork), and change to that branch:

git branch mywork
git checkout mywork

Now change into the git directory and code away. To fetch upstream changes into your local repository, switch to the master branch and run:

git branch master
git pull --rebase

To update another branch from master, without losing changes already committed in the branch:

git checkout mywork
git merge master

To check the status of the repository. use the status sub-command to view the state of the local copy:

Much like svn status, if you change a file once it has been committed, running git status will show that the file was modifed since last commit:

$ echo "new content" > testfile
$ git status

On branch master

Changed but not updated:

(use "git add <file>..." to update what will be committed)

modified: testfile

no changes added to commit (use "git add" and/or "git commit -a")

As the output states, the changes will not be added to the commit before you use git add to add the files to your staging area. The staging area is a temporary location for the changes to be commited, and it basically allows you to select what files you want to include in a commit. If you want to include all changed files to your next commit, the shortcut "-a" for commit can be used to achieve this.

After the files have been added to the staging area, git diff will not show changes to them. To check your changes before doing the commit, you can pass --cached as an option to diff to see them.

To push your changes in the current branch to the upstream repository:

git push

Branches and merging are cheap in Git

When creating changes to the code from the upstream repository that will later get merged back upstream, branches are highly recommended.

To view the current set of branches available, run git branch. The branch with a proceeding '*' is the active one. To create a new branch called "bugfix-branch" for example, run:

If there had been changes made to the branch, git would have automatically tried to merge the changes in the bugfix-branch with the master branch.

Rarely, this can cause a merge conflict. In those cases, manually edit the files that conflict in the master branch, and then do a git commit -a to complete the merge. Git indicates the conflicting lines within the file that cannot be auto-merged.

Viewing the Change log

To view the change log for a given file in the local copy, run git log <FILENAME>.