This is a quick reference guide to Git basics. If your completely new to Git or version control, this is not the best reading to spend time on. I suggest progit.org or the quick reference guides from the official git website.
Init
To start tracking a directory:
$ git init
Add
To start version-controlling specific files or a sub-set of files you need to add them to the staging area using the add command:
$ git add . $ git commit -m 'first project commit'
The ‘.’ will add all files in the directory to the staging area. Instead of the ‘.’ which indicates all files in the directory you can write the full path to a file or a glob like pattern like *.c.
But you don’t want to do that some of the time, especially when you have a binary or executable file in the folder. The binary files are called Untracked files. Each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, meaning files that were first places in the staging area. They can be unmodified, modified, or staged. Untracked files are files that will not be version-ed by git.
If you have a class of files which you don’t want Git to automatically add or not show as being tracked when calling status Then you can add those files as rules of Exception Example of such files are log files, object files, and etc.
You can add these class of files to a list of ignored files by typing the pattern in the .gitignore file:
$ cat .gitignore (type the following lines inside the file) *.[oa] #for files ending with .o which are object files *~ #for files that programs like Emacs create as a temporary cache
The .gitignore rules are:
- Blank lines or lines starting with # are ignored.
- Standard glob patterns work.
- You can end patterns with a forward slash (/) to specify a directory.
- You can negate a pattern by starting it with an exclamation point (!).
Commit
To commit changes to the repository, you need to commit the changes made in the staging area:
$ git commit
If you edit the files after adding them (staging the files), then the modified version will not be in the staging area, but the original file that was added last time ,will be in the staging area. Basically the modified version will be in the working directory, and the last time added version will be in the staging area. So a call to commit will not save the current changes. But only after adding the modified file again it will get in the staging area and ready to be committed to the repository.
Status
To see the status of the directory:
$ git status (or followed by –s for short version)
Let’s run a sample example:
$ vim README $ git status # On branch master # Untracked files: # (use "git add ..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track) $ git add README $ git status # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: README #
Diff
If a file is changed in the working directory but not staged, you can view the changes using diff:
$ git diff
and you’ll see the changes indicated with + sign, like so:
diff --git a/readme.txt b/readme.txt index 436fb61..ef8358f 100644 --- a/readme.txt +++ b/readme.txt @@ -1,2 +1,9 @@ what is this project? +It is a python project +
to see changes made in the staging area but not committed use the cached option:
$ git diff --cached
Clone
To get a copy of a project and it’s repository you need to do a clone. This is how you checkout a project in git:
$ git clone [url] ? the url can be ssh/http/https/ftp/git….