Git
From Dcmf
{ Git | Git Setup | Git tasks | Git maintainer tasks }
Contents |
General Information
Git a source control manager being used for Linux kernel development. It has a strong concept of distributed repositories, allowing multiple developers to independently track and share changes. It does not require a backing server, using only the filesystem to manage the repository.
| Manuals | Other |
|---|---|
|
From the Git Homepage:
- Strong support for non-linear development. Git supports rapid and convenient branching and merging, and includes powerful tools for visualizing and navigating a non-linear development history.
- Distributed development. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another. These changes are imported as additional development branches, and can be merged in the same way as a locally developed branch. Repositories can be easily accessed via the efficient Git protocol (optionally wrapped in ssh) or simply using HTTP - you can publish your repository anywhere without any special webserver configuration required.
- Efficient handling of large projects. Git is very fast and scales well even when working with large projects and long histories. It is commonly an order of magnitude faster than most other revision control systems, and several orders of magnitude faster on some operations. It also uses an extremely efficient packed format for long-term revision storage that currently tops any other open source version control system.
- Cryptographic authentication of history. The Git history is stored in such a way that the name of a particular revision (a "commit" in Git terms) depends upon the complete development history leading up to that commit. Once it is published, it is not possible to change the old versions without it being noticed. Also, tags can be cryptographically signed.
- Toolkit design. Following the Unix tradition, Git is a collection of many small tools written in C, and a number of scripts that provide convenient wrappers. It is easy to chain the components together to do other clever things.
Git Theory
Git is not CVS, but it isn't the other side of the world either. These are tips that are helpful to get a good start.
Repositories and branches
To maintain and shares source code state, Git is able to use a loosely connected set of repositories. The tools do not enforce a hierarchical repository structure, so one is free to design the connections in a way that best suites the project. The connections are only regulated by user access permissions.
Local branches are tracked and changed locally. To communicate with other repositories, git tracks remote branches as remotes/${REPO}/${BRANCH}. In Git jargon, the tops of these branches are referred to as Heads. To do development on a remote branch, one must first create a local branch based on the remote one (i.e. git branch math remotes/mike/math). Note: for simplicity, it is generally easiest to name the local branch the same as the remote tracking branch.
Files that track the heads are stored in .git/refs. Local heads are under the heads directory, and remote ones are under remotes. Understanding the layout of the special .git/ storage can sometimes help one to understand the layout of command arguments.
Special names
- "origin" is the default for the name of the remote repository.
- "master" is the default for the name of the primary development branch
- "HEAD" is a special branch that means whichever branch/commit you have currently checked out.
Specifying a commit id
Most generally, commit ids are hexadecimal SHA1 hashes of the patch that uniquely (and non-sequentially) specify the changes that were made. There are several ways to talk about the parents or children of a specific commit id.
How to invoke the git commands
Git commands start with git-* (e.g. git-commit). However, there is also a "git" program that takes the command as an argument. Therefore, these are the same and merely a matter of preference (I prefer the former, since tab completion works better). The "git-commit" style has been deprecated in favor of only the "git commit" style, so the former will eventually cease to work.
git-commit -m "Issue 123: This change is great" git commit -m "Issue 123: This change is great"
