The first thing you need to do is tell Git who you are, so that any subsequent commits record your authorship appropriately. It is possible to do this on a repository-by-repository basis, but it's usually the case you configure this on a global level. (To configure on a per-project level, run inside a repository and without the
$ git config --global user.name Alex Blewitt $ git config --global user.email email@example.com
Note that the email is case sensitive, and some systems will be picky about matching the case exactly. If you set this up at the global level,then you don't need to do this step again.
Adding content to a Git repository is done in two stages; firstly, adding the content itself, and secondly, committing the changeset.
Like other version control systems, you need to add content to a repository to tell it what is under the repository's control. To do this with Git, you use
git add to add one or more files under Git's control:
$ git add file.c file.h docs/
Once files have been added, the changeset can be committed into the repository with
$ git commit
When a set of changes are committed, you have the opportunity to add comments describing the changeset. Unlike CVCS, the commit message is per changeset commit, rather than per file. If you don't specify it on the command line (with the
-m flag) then you'll be put into your editor.
The standard format of a commit message is described in git-commit: conventionally, the first line contains a present tense description of the change, followed by a blank line, followed by more descriptive changes if needed. Conventionally, the last paragraph consists of
Key: Value pairs which can be used to record arbitrary information, such as which issue they are associated with, who signed the change off etc. A commit message may look like:
Handle legacy encodings By default we expect UTF-8; however, we should handle cases where it is not. Bug: 123 Signed-off-by: Alex Blewitt <Alex.Blewitt@gmail.com> Change-Id: Ia2dd79e7d8fd33e9940f7eb9cf68ece2cfcf9e2c
The soft limit of 50 characters for the first line is not enforced, but since some commands show just the first line (in particular,
git log --oneline) then it makes sense to keep to that level. As with other version control systems, the commit message should explain the intent behind the changeset, not the implementation details behind the change (since that can be derived from the diff anyway).
Adding subsequent changes
One difference from Git is subsequent changes to the files also need a
git add. Git has a concept called the index, which we'll cover in a future tip. When you do an add, you're not just adding the file to the repository, but you're adding a specific version of the file to the repository.
To get stated with Git, you can default to using
git commit -a. This has the same effect as adding all previously added files, which may be what you expect initially. Running
git status will tell you what's outstanding.
Come back next week for another instalment in the Git Tip of the Week series