📌 Learning objectives:
- Learn to use Git alone
With Git, everything is local, remote operations are only for sharing. You do not have to be connected to Internet or any server to work.
Git has no notion of directories, only files are tracked (technically, contents).
git help
gives general guidelines on Git usage. It can also be applied on a
specific command
:
$ git help [command]
$ git config --global user.name "Your name here"
$ git config --global user.email "[email protected]"
Git stores global configuration settings in ~/.gitconfig
.
Move to your working directory and initialize a Git repository, containing the whole project history:
$ cd /path/to/project
$ git init
Initialized empty Git repository in /path/to/project/.git/
Running git init
in an existing repository will not overwrite things that are
already there.
- Configure your identity
- Create a Git repository named "git-training"
- Inspect its content with the Finder/File viewer/Explorer
git status
gives you many information about your project, i.e. about the
working directory and Git repository:
$ git status
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)
$ touch mars.txt
$ git add mars.txt
$ git commit -m "Add mars.txt"
git add
: adds files to the staging areagit commit
: commits the state of the staging area
The staging area is a place where we can group files together before we "commit" them to Git.
git add
adds files to the staging area.
- When files are new, it enables tracking on these files
- When files are tracked, only the changes are added
git commit
makes the changes of the staging area part of the local Git
repository. A commit message is required.
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you
omit the body entirely); tools like rebase can get confused if you
run the two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
A Note About Git Commit Messages
Each commit is identified by a hash (SHA).
$ git show f7ff9ec81552261105ce8573c14dd46d8a8c2aad
It is a long id but you can usually type the first chars only:
$ git show f7ff9
HEAD
is a special reference to the most recent commit.
git log
displays all the commits of your project. You can also pass a
filename
to filter the commits.
$ git log
commit 2d95be7716feb718d0cd623eb0c778bbf7f512c4
Author: William Durand <[email protected]>
Date: Sun Sep 17 21:17:04 2017 +0200
Add mars.txt
commit 4b24c727e6754b0fcc3245cd53880a100f58981f
Author: William Durand <[email protected]>
Date: Sun Sep 17 21:16:50 2017 +0200
Add README.md
git show <commit>
displays the information of a given commit or the most
recent commit if none specified:
$ git show 4b24c727e6754b0fcc3245cd53880a100f58981f
commit 4b24c727e6754b0fcc3245cd53880a100f58981f
Author: William Durand <[email protected]>
Date: Sun Sep 17 21:16:50 2017 +0200
Add README.md
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e69de29
- Create a file named
README.md
- Add it to the staging area
- Verify that it worked
- Commit this file with the
-m
option - Create a file named
mars.txt
- Commit it with
git commit
(no option)
$ git mv some-file.txt better-name.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: some-file.txt -> better-name.txt
$ git commit -m "Rename some-file.txt to better-name.txt"
$ git rm better-name.txt
rm 'better-name.txt'
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: better-name.txt
$ git commit -m "Delete better-name.txt"
- Create a file named
baz.txt
- Commit it
- Rename this file to
venus.txt
- Commit it
- View the log for this file
git checkout
allows to restore an old version of a file:
$ git checkout <commit> <filename>
It is useful to discard changes in the working directory:
$ git checkout -- <filename>
git reset
can be used to unstage a file:
$ git reset HEAD <filename>
$ git reset -- <filename>
- Create a new file
nope.txt
- Add it to the staging area
- Undo the previous step and see what happens
- Update the content of
venus.txt
- Add this change to the staging area
- Undo the previous step and see what happens
- Update the content of
venus.txt
and commit
git diff <commit>
shows the difference between the last commit and unstaged
changes in the current project:
$ git diff
diff --git a/venus.txt b/venus.txt
index 257cc56..3bd1f0e 100644
--- a/venus.txt
+++ b/venus.txt
@@ -1 +1,2 @@
this is about venus
+bar
To see the difference between staged changes and the previous version of the repository, use:
git diff --staged
- Modify the content of your
README.md
file - Review your changes
- Commit them
Git can be configured with a special .gitignore
file to mask certain files.
You can use wildcards, regular expressions and exact filenames.
Sometimes, you want to exclude all files of a given directory but keep this directory under version control.
Commit a .gitkeep
file into it before ignoring it.
- Create a
.gitignore
file and commit it - Ignore the directory named
result/
- Create this directory and add files into it
- See what happens
- Keep this
result/
directory under version control
git stash
is a nice Git feature that allows you to put a set of changes on
hold and get back to them later.
git stash
takes the state of the staging area and saves it as a "draft"git stash pop
: apply the latest "draft" and remove it from the listgit stash list
: list all your "drafts"