There are several reasons to use Git to meet your distributed version control system (DVCS) needs and manage your website's code, including the following:
- Manage your code locally
With Git you can make changes and roll them back, if needed, on a local machine. Huge check-ins are not necessary. An incremental history is kept in your repository. You can work offline with Git on a local machine — you need to be online only to share changes.
- Track changes in your code
A DVCS is built for sharing changes. In Git, this is done by use of a Git user id, a guid. Every change has a guid, which makes it easy to track changes.
- Branch and merge features
Because developers have their own branches, every shared change is similar to reverse integration. The guids make it easy to combine changes and avoid duplicates.
In Git, a repository is a data structure that contains snapshots of files and directory trees, taken at different points in time. As a whole, the repository provides a complete history of the changes made to a project, from its initial commit, or snapshot. With Git, the repositories are distributed; each developer has a complete history of the project and can act as the central repository.
Your local repository consists of three trees maintained by Git:
- Working Directory - Holds the actual files
- Index - Acts as a staging area
- HEAD - Points to the last commit you made
If you're starting a new project, you can initialize a Git repository in the current directory by entering something like the following from the command line:
git init
Typically, one would want instead to check out an existing repository. To do this, you would enter something like the following:
git clone /file_path/repository
This is pretty straightforward. However, you could also use the string provided by GitHub by entering something like this:
git clone username@host:/file_path/repository
After creating a few files, you can check the status of the repositories with the status option like the following, with a message similar to the one that follows:
git status
# On branch master
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# modified_file_1.txt
# modified_file_2.txt
# modified_file_3.txt
This indicates that there are three files in the working directory that Git has not added yet to the Index. You can propose a change or add all three files, in this case, to the Index by executing something like the following:
git add .
At this point, the status result should look different and similar to the following:
git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# new file: modified_file_1.txt
# new file: modified_file_2.txt
# new file: modified_file_3.txt
Finally, to commit these changes, use the commit option. As part of it, one would provide a comment about the commitment, something descriptive. It might look like this:
git commit -m "I'm committing 3 files."
Each snapshot of files in a Git repository is called a commit. In addition to references to file objects, a commit includes an explanatory message, information about the author, and references to the parent, or prior commits. Each commit has an automatically generated name called a ref (that is, a 40-byte hexadecimal SHA1 code).
You may be wondering why you first add files to the Index before committing it to HEAD. This is a two-stage process so that you can work on multiple files without needing to commit all of the files you edited to the repository. Using the preceding examples, if you modified all three files and checked the status, you should see something like this:
git status
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: modified_file_1.txt
# modified: modified_file_2.txt
# modified: modified_file_3.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
Rather than adding all of the files to the Index this time, you can add only the files you have finished:
git add modified_file_1.txt
git add modified_file_2.txt
git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD ..." to unstage)
#
# modified: modified_file_1.txt
# modified: modified_file_2.txt
#
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: whyareyoumodifyingthreefiles.txt
#
Then you can commit just those two files and continue working on the third.
$ git commit -m "I am not awesome enough to commit 3 files."
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# modified: whyareyoumodifyingthreefiles.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
If you're satisfied with the state of your repository, you can create a tag for it. Any commit may be branded with a tag, a human-readable alias. In the Drupal core project, there are tag names for each release (for example, 6.18, 6.19, 7.0-beta1, 7.0-rc-1, etc). Like commits, tags may have an explanatory message stored with them.
To tag the latest commit (HEAD), that is, to label it 0.0.1 for instance, simply enter something like the following:
git tag 0.0.1
You can also tag a specific commit. In order to do so, you will need to obtain the commit id of the commit you wish to tag. You would do this with the log option like so:
git log
commit bb3c86c934f72ada8d276d605f975e46138acaf6
Author: Ms Awesome
Date: some date
I am not awesome enough to commit 3 files.
commit e541b38837e440bdd894c044eb8700293fc68ddb
Author: Ms Awesome
Date: some date
I'm committing 3 files because I'm awesome like that.
You don't have to enter the entire id; the first four characters will suffice if they're unique.
$ git tag 0.0.1 bb3c