Chapter 25

What Else Is There?

In this book we have limited ourselves to the Git concepts and commands that are used in typical project situations in business. The following chapter gives you an overview of what else is there in Git. The commands are not described in detail, but only so far as is necessary for you to grasp the concepts.

Interactive Rebasing—Making the History Better

We have mentioned rebasing many times in this book. It is used to apply changes in commits again and produce new commits, for example if you want to replant a branch.

If you put a lot of emphasis on the commit history, then you can use rebasing to summarize (squash command), split (edit command) or re-sort commits. For this, you call the rebase command with the --interactive parameter. The commit from which the history is to be changed is given as the second parameter. For example, to change the last three commits, use the following command.

> git rebase --interactive HEAD~3

As a result, a text editor will show three commits.

pick 927d33a commit 3 
pick 7d343d0 commit 4 
pick fbe58cb commit 5 

# Rebase 940d0db..fbe58cb onto 940d0db 
# 
# Commands: 
# p, pick = use commit 
# r, reword = use commit, but edit the commit message 
# e, edit = use commit, but stop for amending 
# s, squash = use commit, but meld into previous commit 
# f, fixup = like "squash", but discard this commit’s log message 
# x, exec = run command (the rest of the line) using shell 
# 
# If you remove a line here THAT COMMIT WILL BE LOST. 
# However, if you remove everything, the rebase will be aborted. 
# 

In the text file the commits can be rearranged or changed using the commands listed. After closing the editor Git will process the commits according to the commands.

Attention! The commit history should never be changed after executing the push command. Other team members may already been relying on the “old” commits.

Dealing with Patches

In the Unix world especially, changes are often transmitted via a patch file. In pure Git environments there seldom is a need to work directly with patches. Here changes are replaced by commits. If it is necessary to use patches, Git supports the creation and installation of patches.

Patches can be created with the diff command.

> git diff rel-1.0.0 HEAD >local.patch 

To load the changes into another repository, use the apply command.

> git apply local.patch 

> git commit -m "applied patch" 

Sending Patches by Email

Git also allows you to send commits by patch-mail and import them to another repository. This is a substitute for pull and push. Information from the original commits (authors, dates) is retained. Commit hashes, however, are not.

The format-patch command creates a separate patch file in mbox format for each commit in the specified range. The mbox format is a text file for emails.

> git format-patch rel-1.0.0..HEAD 

0001-a7.patch 
0002-a8.patch 
0003-a9.patch 
0004-a9.patch 

You can now send the files to yourself or use the Git send-email command.

> git send-email --to "mailto:[email protected]"

The recipient can import the emails with the am command to a repository. Here you can select the patches individually or specify all using the wildcard character.

> git am 0*.patch 

Bundles—pull in Offline Mode

The two previous sections discussed transferring patches from one repository to another. If you want to transfer commits, you normally use the pull or push command. However, if there is no direct connection between the computers hosting the two repositories, you can create a bundle. A bundle contains commits and you can use the fetch or pull command against one.

As the first step, create a bundle using the bundle-create command. The bundle will contain all the commits to be transferred.

> git bundle create local.bundle rel-1.0.0..HEAD 

The generated file can then be transferred to another computer by email or with a USB stick. There you can import the commits from the bundle to another repository. The commit hashes will be retained.

> git pull local.bundle HEAD 

Creating An Archive

You can use the archive command to export the contents of a project as an archive without exporting the Git metadata (the .git directory). This command supports the tar and zip formats.

> git archive HEAD --format=tar > archive.tar 

> git archive HEAD --format=zip > archive.zip 

> git archive HEAD --format=tar | gzip > archive.tar.gz 

You can also pack only individual subdirectories into an archive.

> git archive HEAD subdir --format=tar > archive.tar 

You can also create an archive of a remote repository using the --remote parameter.

Graphical Tools for Git

In this book we have worked exclusively with the command line. However, Git also ships with two graphical tools. One of them is the Git GUI, which can create commits. You use the gui command to open it (See Figure 25.1).

> git gui

Figure 25.1: A graphical tool for creating commits

There is also GITK, another graphical tool you can open with the gitk command. This one can handle the history (See Figure 25.2).

> git gitk –all

Figure 25.2: A graphical tool for viewing the history

Viewing A Repository with A Web BrowserGitWeb is a tool for viewing and searching a Git repository in the browser (See Figure 25.3). GitWeb shows all the commits and branches in the repository. You can look at the files in a commit and examine the changes. With GitWeb you can also search for files and commits.

To start and stop GitWeb, use the instaweb command.

> git instaweb start

> git instaweb stop

Figure 25.3: GitWeb

Working with Subversion

Git allows you to clone a Subversion repository (using the svn-clone command). The entire history will be imported. In the Git repository you can create local commits. You can always get the latest version from Subversion (using the svn rebase command). If the local commits need to be exported back to Subversion (using the svn-dcommit command), then a separate Subversion revision will be created for each commit.

> git svn clone http://localhost/projecta/trunk

> git svn rebase

> git svn dcommit

Command Aliases

Repeatedly typing Git commands with a long list of parameters can be quite tedious. With aliases you can minimize the amount of typing. Here you can configure global aliases for all the repositories on the computer or only for the current repository.

The global alias ci, short for commit, is defined as follows.

> git config --global alias.ci commit 

A local alias rema, a shortcut to rebasing with the master branch, is defined as this.

> git config alias.rema 'rebase master'

Then you can use the aliases as normal commands.

> git ci 

> git rema 

Notes on Commits

Commits are immutable in Git. Although you can copy and change a commit, a new commit is later created. If you want to add a comment to a commit, you have notes at your disposal. Notes are mostly used by development tools to highlight commits.

The notes add command creates a new comment in a commit.

> git notes add -m "My Comment" HEAD 

You can display the comment later with the notes show command.

> git notes show HEAD 

Attention! Notes are not automatically transferred to another repository with a pull or a push. Unfortunately, there are no simple parameters for notes to achieve this. The following two commands show an example of how notes are transferred:

> git push origin refs/notes/*:refs/notes/*
> git fetch origin refs/notes/*:refs/notes/* 

Extending Git with Hooks

You can create a hook to fire off certain scripts when a particular action occurs. For instance, it is possible to perform pre-determined checks before the actual commit, like if certain conventions have been adhered to in the commit comment (commit-msg hook).

Sample hooks are stored in the .git/hooks directory of each repository.

Hosting Repositories on GithubGithub (https://github.com) is a service provider for managing Git repositories and making them available on the Internet. Github offers SSH and HTTPS access to the repository.

Creating public repositories is free. For private repositories, you must use the paid version. Many open source projects are now using Github as a development center.

In particular, the pull workflow is well supported. You can clone an existing Github repository within Github. Server-side clones are called forks. You can work as usual on your own fork repository. You can create a local clone and changes are written back via the push command. If you want to transfer commit changes back to the source repository, you can send a pull request to the repository owner through Github. You can then pull and merge the changes using the pull command.