This article has quick reference to key commands in Git ..
- A commit in Git records the snapshot of your
project. Each commit will have references to previous commits and thus the
history is preserved.
>> git commit
- Branches in Git are incredibly light weight and
are mere references to the commit; there is no storage overhead. Hence Git
Enthusiasts chat the mantra, “branch early, and branch often”.
>> git branch [name] - create a branch
>> gti checkout [name] –
switch to branch
>> gti checkout [name]; git
commit – switch to branch and commit to the newly created branch
- Merging – is the process of combining work
between branches.
>> git merge [name] -> merge the branch [name] to the checked
out branch
- Rebasing is the second way of combining work
between branches, which essentially takes a set of commits, “copies” them and
moves it to selected branch.
>> git rebase [name] ->
rebase the checked out branch to the branch [name]
- Head is the symbolic name for the currently
checked out commit
- Detaching HEAD just means
attaching it to a commit instead of a branch
>> git checkout master
-> HEAD is master branch
>> git checkout C1 -> Head is commit C1
- Git Hashes
Most DVCS
tools, including Git, Mercurial, and Veracity, use cryptographic hashes. There
are many algorithms for computing Git hash and Git uses SHA-1 (Secure
Hash Algorithm)
Git uses hashes in two important ways.
- When you commit a file into your repository, Git calculates and
remembers the hash of the contents of the file. When you later retrieve the
file, Git can verify that the hash of the data being retrieved exactly matches
the hash that was computed when it was stored. In this fashion, the hash serves
as an integrity checksum, ensuring that the data has not been corrupted or
altered.
- Git also uses hash digests as database keys for looking up files
and data.
- Relative Reference
In Git, each commit is referenced
by unique hash and specifying the git by hash is not the most convenient way.
Hence we have relative reference, where you start from somewhere memorable like
a branch or a commit.
Let’s see how caret (^) & tilde (~) help us achieve that
Use ^ to move upward one character at a time
>> git checkout
master^ -> moves the reference (HEAD)
to one level up
>> git checkout HEAD^ ->
moves the reference to one level up
So at this
point, we have moved the reference to two commits up.
Use ~<num> to move number of times
upwards
>> git checkout HEAD~
You can reassign a branch a
commit with –f (by force) option
>> git branch –f master
HEAD~5
Git Reset >> git reset HEAD~1 -> moves the
head revision one level up on our local repository. However this does not
change on the remote branch in DVCS.
Git Revert >> git revert
HEAD-> reverse the changes on the local repository and share the changes
with others. This creates a new commit whereas git reset does not.
>> git cherry-pick <commit 1> <commit 2> <…>
>> git cherry-pick C3 C4 C8
-> copies the commits C3, C4 & C8 to the checked out branch. Note:
each commit may be from same or different branches
Git cherry-pick can be used only when you know git hash (C3, C4 & C8
in the above example). Git interactive rebase comes into picture when you do
not know the git hash.
>> git rebase -i HEAD~4 - -aboveAll -> once you enter the command, git list
the hashes corresponding to 4 revision, which you re-order or remove and
proceed.
>> git commit - -amend
Git Tags are used to permanently
mark historical points (i.e. certain commits like major releases / big merges) in
the project history as “milestones” that can be later referenced like a branch.
They are ready-only. You cannot checkout from a tag and modify.
>> git tag <tag name>
<commit number>
>> git tag v1 c1
>> git describe <ref>
-> where ref resolves to a commit, if not specified, git assumes the
latest checked out commit or HEAD.
The output of the above command is
<tag>_<numCommits>_g<hash>
Where tag is the closest ancestor tag in history, numCommits is how many
commits away that tag is, and <hash> is the hash of the commit being
described.
Like tilde (~),
caret can also have number but this is use to go upwards to parents rather than
commits.
>> git
checkout master^2
>> git
checkout HEAD~; git checkout HEAD^2; git checkout HEAD~2 => can be combined into one command say
git checkout HEAD~^2~2
Git Remotes are nothing but copies of your own
repository on local computer, which have a bunch of great properties out of
which backup, sharing and collaborating are predominant.
Commands to create git remotes:
git clone – Traditional git world, git clone is used to
make your own local copy from remote but here we are using it to create remote repository
out of your local one.
Remote branches are always displayed in the format <remote name>/<branch name>
When you checkout from Git Remote, git commit will not
automatically update the remote branch. Instead git just checkouts the code and
creates a detached HEAD for you.
Remote branches reflect the state of the remote
repositories since you last talked to those remotes.
>> git fetch -> helps you to fetch data from a
remote repository which are missing in local repository and updates the
<remote name>/master to reflect the changes.
It talks to the remote repository through internet (via
protocol like http:// or git://).
It is important to note that Git Fetch does not modify
the user’s local copy or working copy (i.e. master).
>> git pull -> is literally git fetch followed
by git merge (example: git fetch; git merge <remote name>/master ->
Latest code is fetched from the remote master to <remote name>/master on
your local and later merged to local master.
>> git push -> is opposite of git pull, is
responsible for uploading your changes to a
specified remote and updating that remote to incorporate your new commits. It’s
basically a command to publish your work.
git push is literally git fetch followed by git rebase.
Here are 3 different ways to update your local
repository to update the changes from remote before you push your changes to
remote
>> git fetch; git rebase <remote
name>/master; git push
>> git fetch; git merge o/master; git push
>> git pull - -rebase -> shorthand for git pull and rebase
(whereas git pull is just shorthand for a fetch and a merge)
>> git pull; git push
- Why rebase & why not merge while updating
the remote?
Rebasing makes your commit tree look very clean since
everything is in a straight line, hence some developers prefer rebase.
Where Rebasing modifies the (apparent) history of the
commit tree but merge preserves the history, hence some developers prefer
merge.
Remote tracking is property which establishes the
connection between your remote branch, <remote name>/remote branch, which
is set automatically when you clone the git repository.
By default, when you checkout <remote
name>/master, git checks out to a local repository with the same name.
You are free to specify a different name with the following command.
>> git checkout -b NotMaster <remote
name>/master -> this creates a new branch NotMaster to track <remote
name>/master
>> git checkout -b NotMaster <remote
name>/master
>> git branch -u <remote name>/master NotMaster
-> git branch –u is to set tracking on remote branch
>> git branch -u <remote name>/master NotMaster;
git commit; git push.
>> git push <remote name> <place>
>> git push origin master -> Go to the branch named
"master" in my repository, grab all the commits, and then go to the
branch "master" on the remote named "origin." Place
whatever commits are missing on that branch and then tell me when you're done.
The above example is where both the source and the
destination has the same name. Many a times that can be different as well.
<place> will be resolved into <source>:<destination> for
different source and destination. This is commonly referred to as a colon refspec.
Refspec is just a fancy name for a location that git can figure out
>> git push origin master:newBranch -> If the
remote branch does not exist, git will create and move changes from source.
Git fetch arguments is similar to Git Push Arguments except
we are downloading the changes to local.
>> git fetch origin
<source>:<destination>
- Oddities of <source> in git push, git
fetch
>> git push origin :<branch name>
>> git fetch origin :bugFix
Leaving source blank means, sending nothing. In
push sending nothing will delete the destination whereas in fetch, sending
nothing will create a new branch.
>> git pull origin master -> fetches the commits from origin master
and merges it to the currently checkout branch
The above commands are based on my leanings and understanding from the
interactive visual training guide.
