Installation:

sudo apt-get update

sudo apt-get install git
Configure username and email:
git config --global user.name 'Rajesh'
git config --global user.email "dwdrajesh@yahoo.com"
Setting up git repository locally:
git init <directory> : will create a directory called '.git' at the directory pr
ovided.
Git init first time on a server:
ssh <user>@<host>: login to the server and navigate to the desired directory
git init --bare my-project.git: initialize a bare repo which means the repo does
not have a working directory and hence, no one can edit files or commit changes
to that repo. Also, bare repo is created in a directory with .git file name,
e.g.
ssh <user>@<host>
cd path/above/repo
git init --bare my-project.git: Creates a repo under the directory my-project.gi
t which is bare and is usually for the central directory. Other developers clone
from this repo and can only push changes.
Clone: Copies an existing repo.
git clone URL_of_remote_repo.git <directory> : Clone the repo to the specified l
ocal directory; The URL can be in Github or on local server via SSH.
Note: Clone automatically creates a remote connection called 'origin' that point
s to the original/central repo.
Note: the URL has .git at the end, meaning it is a bare/central repo but the loc
al repo won't have .git (non-bare).
Text editor for commit:
git config --system core.editor <editor> : where, editor is the command to open
the desired editor, e.g. vi or subl.
git config --global --edit : To open the global config file in an editor to edit
manually.
git add (Put files in staging area):
Files are in the working directory. In order to select which files to add to the
.git directory (which is the local repository itself), we can select via git ad
d.
It puts the files in the staging area. After this, they can be committed which m
eans they are added to the repo (.git directory).
So, Working Directory -> git add -> Staging Area; -> git commit -> Local repo (.
git directory).
1. git add <file> or git add <directory>
2. git add -p: Lets you choose which changes in a file to put to the staging are
a
3. git add . : Adds all the modified, new and deleted files in current directory
to the staging area.
Commit:
git commit -m "Message" : Takes a snapshot of the staging area which was updated
after the 'git add <file>' command and updates the project history in the local
repo or .git directory.

git commit -a : Takes a snapshot of all tracked files (those added to staging ar
ea via git add ...)
git status:
To view the status of the local repo (.git directory)
git stash:
Temporarily shelve (stash) the changes made in the working copy if you need to w
ork on sth else and are not ready to commit yet. Helpful to switch context/work.
The current files states are saved in the stash and can be reverted later.
After stashing, commits can be made on new changes without affecting the state o
f files in the stash. Stash can be done any number of times, each one identified
by a number.
1. git stash : Save the uncommitted changes (note: both in staging area and not
in staging area also) but does not save untracked (new files not tracked by Git
and ignored files).
After the changes are saved in stash, you can work on other commits or switch br
anches.
2. git stash
ctory
3. git stash
4. git stash
5. git stash
efault.
6. git stash
tory
7. git stash

pop : Take the top most stash and apply the changes to working dire
list : List all stashes
save "Add sth" : To save stash with a name to identify
pop stash@{2} : To apply changes from stash no. 2 instead of 0 by d
show -p: To view differences of a stash from original working direc
drop stash@{1} : To clear the stash no. 1

Stash is just a commit; the commit is stored at the file: .git/refs/stash

The stashes popped are removed from the file .git/refs/stash

git status: Show staged, unstaged and untracked(new files or ignored files) file
s
NOTE: git status is for staging area and working directory, but git log is for c
ommitted changes only (.git directory).
git log: Show the commits
1. git log -n 3 : Show the top 3 commits (latest 3)
2. git log --oneline : Show each commit on a single line
3. git log --author="dwdrajesh" : Show commits by author dwdrajesh
4. git log abc.c : Show commits that include the file abc.c
5. git log --graph --oneline : Show commits with branch in a tree format
6. git log -p : Show the diffs of each commit; detailed log
HEAD: HEAD refers to the current commit at the current branch.
git checkout : Does 3 things: checking out files, checking out commits and check
ing out branches; The first two are given below:
a. git checkout <commitID> abc.py: downloads the file abc.py based on the commit
ID to working directory and puts it in the staging area.
Note: To again go back to the latest file version: git checkout HEAD abc.py
b. git checkout <commitID> : downloads all files based on the commitID; files no
t added to staging area. NOTE: This puts you in Detached HEAD state.

c. git checkout master: To go back to your original changes. Note: Changes made
while checking out a commit are not saved.
Basic flow:
Step 0 : Make some changes in project
Step 1: git log --oneline : To view all commits
Step 2: git checkout <commitID> : to checkout a commit
Step 3: git checkout master : To go back to changes before step 1 .
NOTE: checking out a commit does not change the branch or the current state of t
he project. Even changes made while checking out a commit can be reverted by 'gi
t revert' or 'git reset' after checking out the required branch (master etc) eve
n after altering files in that commit.
However, checking out file only changes the file in the current branch, hence it
is shown in staging area. This can be neglected or reverted by: git checkout HE
AD abc.py (To discard changes caused to abc.py made by checking out an earlier c
ommit).
Detached HEAD: Normally, HEAD points to the master or some local branch but when
an old commit is checked out, HEAD points to the commit itself. Hence, called D
etached HEAD. Changes made here are not saved.
git revert <commitID> : To revert changes introduced by a single commit. Note th
at commits in the middle from the current HEAD to the commitID still exist.
e.g. After a commit, immediately, we can do : git revert HEAD
Revert does not delete the commitID from history, instead adds a new commit tha
t reverts the changes introduced in commitID.
NOTE: NEVER use git reset on shared repos, use only on local branches.
a. git reset : Unlike revert, reset deletes the commits also.
b. git reset abc.py : Remove abc.py from staging area but leave working director
y unchanged. Effectively, it unstages the file only but changes in the file made
are saved. To discard the changes also, 'git checkout -- abc.py'
c. git reset <commitID> : Move the current branch tip backward to the commitID,
but does not change the files that have been modified since commitID. It allows
to stage files one by one for cleaner, atomic snapshots.
For Collaboration:
git remote: To create a bookmark/connection to a remote repo so that it can be r
eferenced using a name rather than the URL.
git remote -v: To view all remote connections (with their URL, -v)
git remote add <name> <URL> : To add a remote connection to the repo at <URL> so
that it can be called using just the <name>
git remote rm <name> : Remove connection to the remote repo with <name>
Note: git clone URL_of_remote_repo.git : will automatically create a remote conn
ection called 'origin' pointing back to the remote repo.
Access/Reference to Remote Repos:
a. HTTP : http://host/path/to/repo.git
b. SSH : ssh://user@host/path/to/repo.git
git fetch <remote> : Download all commits from <remote> repo
git fetch <remote> <branch> : Import all commits from the branch <branch> at <re
mote> repo
e.g. git fetch origin master : To download 'master' branch from 'origin' repo
Fetch will import all the commits but does not change the local development work
.

The fetched content is represented as a remote branch.

To view all remote branches: git branch -r. This will print only the remote bran
ches which are prefixed by the name of the remote repo, e.g.: origin/HEAD or ori
gin/master if the HEAD and master branches belong to 'origin' repo.
To only view the changes in the remote branch without affecting local, use git c
heckout. To apply those changes to local repo, use git merge.

E.g:
git fetch origin : Downloads the central repo's master branch (which will be nam
ed 'origin')
To view the changes in the downloaded 'origin/master' branch : git log origin/ma
ster
To merge these changes with local master: git checkout master; git merge origin/
master
With git pull: git pull <remote> = git fetch <remote> + git merge origin/master
Note: git pull --rebase <remote> will use 'rebase' command instead of 'git merge
'
Rebase vs merge: rebase will prevent unnecessary merge commits and puts your cha
nges on top of others'.
Push:
git push <remote_branch> <local_branch> : To push changes in local branch to rem
ote.
Push creates a local branch in the remote repo.
e.g. git push origin master : To push changes from the local 'master' branch to
'origin' repo.
Pull Request : From Github or similar sites, the developer sends a request to th
e project manager to merge his/her changes from the local 'feature' branch to th
e 'master' branch.
Generally, Feature branches are merged to the 'develop' branch (which is remote)
while 'release' and 'hotfix' branches are merged to both 'develop' and 'master'
branch (both remote).
Forking: In the Forking workflow, developers first push their local changes to t
heir own remote repo and then only send pull request to the project maintainer.
e.g. A is a developer, B is the project maintainer. Both have their personal Git
hub repos and B has access to the official repo.
Fork : To copy the official repo to your personal remote repo.
'A' forks the official repo from B's Github account and then clones to his local
PC.
Then,
'A' creates a new local branch (new_feature_branch) to start working on her feat
ure :
git checkout -b new_feature_branch
Then, 'A' can make changes to the code and write new commits.
'A' then pushes the change to his personal remote repo: git push origin new_feat
ure_branch
Then, 'A' sends a pull request by clicking the appropriate button in Github.

Branch: A new branch means new working directory, staging area and project histo
ry (commits).
git branch: list all branches in your repo
git branch <branch_name> : create a new branch called branch_name (note: creatin
g doesn't checkout that branch)
git branch -d branch_name : delete the branch (only if it is already merged to m
aster)
Note: Creating a new branch only creates a new pointer (which has the same name
as the new branch's name) to the appropriate commit (which will be the branching
/forking point for master and the new branch)
To go to the branch: git checkout branch_name
Detached HEAD: 3 ways of git checkout (file, commit, branch)
HEAD always refers to the current snapshot(either points to the specified branch
or commit)
When checking out a commit, HEAD points to a commit that was before the tip of t
he current branch. Hence, when we add new commits from that commit(HEAD), the ne
w commit cannot be reached by any commit. Hence, detached HEAD.
Solution: Always make a new branch and check out the branch (not a commit only)
when you want to work on a new feature.
Merging branches: git checkout master; git merge new_feature_branch
2 ways of merge:
a. Fast-forward merge: When there is no new commits in the master branch after t
he new feature branch was forked from it. So, the master branch tip can reach th
e tip of the new feature branch.
b. 3-way merge: When the master has been updated with new commits after the new
branch was forked. Git merges the tip of both branches to create a new commit (c
alled merge commit). Hence, it touches 3 commits (master branch tip commit, feat
ure branch tip commit and the newly created merge commit), hence the name 3-way
merge.