Git commands

# Four stages of Git repositories

Git Basics

#1 git init

  • This locally initializes a database in the folder .git. Your repository is entirely stored within this .git folder.
  • HEAD file : points to the current branch or commit ID you are currently on within your Git repository
  • The config file stores information about your repository’s local configuration.

Repository’s History

#2.1 git log

  • look at the history of this repository
  • This shows you a default history of the repository. Page through it a few times by hitting space or down. You will see how far it goes back. Hit q to stop viewing it, and return to the command line.

#2.2 git log --oneline

  • Another way to view the log is one line per commit, which is much more concise and useful for many purposes

#2.3 git log --oneline --graph

  • Now you get a visual representation of the history. you can parse the graph which could be tricky but It is helpful if you ever have to figure out what went on in a repository’s past.

#2.4 git log --decorate --graph --oneline --all

Repository’s Status

#3 git status

  • provides info like the current state, next steps to do and untracked files if any.

Add Files to a Repository

#4 git add

  • This tells Git to start tracking files in local index.

Committing Changes to a Repository

#5 git commit

  • Tells Git to take a snapshot of all added content at this point.
  • example git commit -m “git commit message”

Simultaneous add and commit

#6 git commit -a -m

  • This allows you to add and commit the files using one command

Clone a Repository

#7 git clone

  • Helps you create copies of Git repositories to work on.

#8.1 git reset

  • helps you return to a previous or known state
  • When you make mistakes in your local repository, instead of deleting the entire repo and re-clone, all that’s needed is a hard reset
  • By default, Git will recover whatever has been added to the index/staging area and place it in your working directory

#8.2 git reset — mixed

  • The --mixed flag takes items out of their added status but keeps them altered in the current working folder

#8.3 git reset --hard

  • will remove all local and added changes, reverting your checkout to a just-cloned and committed state.
  • So --hard not only takes items out of their added status, but they also make the working tree state consistent with what was last committed. You can effectively lose your changes with the --hard flag

Git Branching

#9.1 git branch <feature branch name>

  • creates a new branch with given name

#9.2 git brnach

  • list your branches and current branch you are in

Detach Head

  • Know how you can switch between different commits either in the same branch or across branches.
  • The HEAD pointer can be moved to an arbitrary point. In fact, git checkout does exactly this. You can specify a reference (like master or newfeature) or a specific commit ID.

#10.1 git checkout <commit>

you will find below text

Note: checking out ‘37e973ab66afae881d207dc59f578448f76501d6’.
You are in ‘detached HEAD’ state.

You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b <new-branch-name>
HEAD is now at <commit>

  • A detached HEAD sounds like a bad thing and can be bewildering upon seeing it.
  • It just means that your Git repository’s HEAD pointer (which is where Git currently thinks it is) is not pointed at a branch at the moment. Instead, it’s pointed at a commit ID, i.e., the HEAD is detached from a branch. There might be a branch pointed at that commit (git log — decorate will tell you this), but your HEAD is not pointed at it.

Points to remember:

  • A branch is a pointer to the end of a line of changes.
  • A tag is a pointer to a single change.
  • HEAD is where your Git repository is right now.
  • Detached HEAD means you are at a commit that has no reference (branch or tag) associated with it.

Git Merging

Merging is the opposite of branching. When you merge, you take two separate points in your development tree and fuse them together.

  • lets understand of merging with the help of a visual example.


  • In this diagram, the repository is currently positioned at the tip of master (G). You know this because the HEAD is pointed at G.

Post Merge

  • If you merge the experimental branch into master with a git merge experimental command, you end up with a tree that looks like this

A new change has been made (I). This change merges together the changes made on experimental with the changes made on master.

#11 git merge <experimental>

  • this might merge your changes (experimental branch ) to master branch if not merge conflict.
  • if there is merge conflict, then we need to resolve merge conflict.

Merge conflicts and resolution

  • When you run a merge, Git looks at the branch you are on (here it is master) and the branch you are merging in (experimental) and works out the first common ancestor.
  • It then takes the changes on the branch that you are merging in from that first common ancestor and applies them to the branch you are on in one go.
  • These changes create a new commit, and the git log graph shows the branches joined back up.
  • Sometimes the changes made on the branches conflict with one another. That means the changes altered the same lines.
  • In this case, the D, F, and G of the master changed the same lines as the E and H of experimental.
  • Git doesn’t know what to do with these lines. Instead of putting the D, F, and G in, should it put the E and H in? Or should it put them all in? If it should put them all in, then what order should they go in?
  • By default, Git does not make a decision when this happens. Instead, it tells you that there was a conflict and asks you to “fix conflicts and then commit the result”.
  • if we look the file we will find below content
<<<<<<< HEAD
>>>>>>> experimental

There are three sections here:

  1. The file up to line C is untouched, as there was no conflict.
  2. Then we see a line with arrows indicating the start of a conflicting section. It is followed by the point in the repository that those changes were made on (in this case, HEAD).
  3. Then a line of seven equals signs (=======) indicates the end of a conflicting set of changes. It is followed by the changes on the other conflicting branch (the E and H on the experimental branch).

Resolving merge conflicts

  • What you choose to do here is up to you as maintainers of this repository. You could add or remove lines as you wish until you are happy the merge has been completed, or replace it with something completely different. Git doesn’t care.
  • When you are satisfied, you can commit your change, and the merge has been completed
  • When you are done, you can commit the change, and view the history with the git log command. it will look like below
  • Reading this from bottom to top, you can read commit C and commit H as being merged into the HEAD of master.
# git commit -am "merged exeprimental in"
# git log --all --decorate --oneline --graph
* 010aa36 (HEAD -> master) merged experimental in
| * 2c7b41b (experimental) H
| * 8250b67 E
* | cc45709 G
* | 4fce47c F
* | 4f8df93 D
| /
* d08df08 C
* 6028fe8 B
* 8deec4a A

Git stash

Often when you are working, you want to return to a pristine state but you don’t want to lose the work you have done so far. Traditionally, with other source control tools, you’ve copied files that have changed locally aside, then updated your repository, and then diffed and re-applied the changed files.

  • Git has a concept of the “stash” to store all local changes ready to re-apply at will
[do some work]
[get interrupted]
git stash
deal with interruption]
git stash pop

#12.1 git stash

  • Command for stashing your changes
  • It commits the state of the index and then commits the local changes to the ref/stash branch and merged them as a child of the HEAD on a new refs/stash.
  • It basically stores all the changes you’ve made (but not commit), and it can be re-applied.
  • The stash branch is a special one that is kept local to your repository. The “commit” message WIP on master and index on master is added automatically for you.

Retrieving stash list

#12.2 git stash list

  • you can see stash list.

Popping stashed work

#12.3 git stash pop

  • It “pops” the zero-numbered change off the stash stack and restores the changes I stashed, applied to wherever I’ve ended up

Getting individual stash information

#12.4 git stash show — patch stash@{<ID>}

Apply a specific Stash

#12.5 git stash apply stash@{<ID>}


  • if you apply a git stash, then it remains in the list. git stash pop will then remove the stash item for you.


The reflog gives you references to a sequential history of what you have done to the repository. This can come in very handy when you play with your local repository’s history as you will see here.

#13.1 git reflog

Cherry picking

Cherry-picking is the simplest-to-understand means to move commits around. This is the basis of the more sophisticated movement of commits, such as rebasing and “squashing” commits.

  • Since every commit in Git is a change set with a reference ID, you can easily port changes from one branch to another

Cherry-picking a commit

#13.1 git cherry-pick <commit id>

  • some times cherry-pick might fail because diff cannot be applied easily. you need to resolve the conflict and add the resolved file and commit it.
  • Cherry-picking is often a simple and easier way to move changes between different branches, which can be very useful.
  • There are cases where cherry-picking does not work the way you might expect



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store