Git Useful Commands
what is git and how its work?
- Git is the most commonly used version control system.
- Git tracks the changes you make to files, so you have a record of what has been done, and you can revert to specific versions should you ever need to.
- Git also makes collaboration easier, allowing changes by multiple people to all be merged into one source.
Feature of git
- Control System: This basically means that Git is a content tracker. So Git can be used to store content — it is mostly used to store code due to the other features it provides.
- Version Control System: The code which is stored in Git keeps changing as more code is added. Also, many developers can add code in parallel. So Version Control System helps in handling this by maintaining a history of what changes have happened. Also, Git provides features like branches and merges, which I will be covering later.
- Distributed Version Control System: Git has a remote repository which is stored in a server and a local repository which is stored in the computer of each developer. This means that the code is not just stored in a central server, but the full copy of the code is present in all the developers’ computers. Git is a Distributed Version Control System since the code is present in every developer’s computer.
lets see the basic git commands that we need for our day to day life :
Configuration — Setting your Git username for every repository on your computer
- git config -global user.name “Firstname lastname”
- git config -global user.email “valid email id”
- git config -global color.ui auto
Git basics commands
- git init -turns a directory into an empty git repository
- git add -adds file to the staging area ( Before a file is available to commit to a repo the file
needs to be added to the git index i.e. staging area) - git commit -m “<commit message” — records the changes made to the files in a local repository
(each commit has a unique ref id i.e. the commit hash(SHA1)) - git status — returns the current state of the repository
- git diff — difference of what is changed but not staged
- git diff — staged — diff of what is staged but not yet commited.
Branching commands
Branch is created to work on a new feature. Every branch is pointed to the latest commit
Branch is referenced by HEAD
- git branch <branch name> — creates a new branch
- git checkout <branch name> — switches to another branch
- git checkout -b <branch name> — ceates a branch and switches to it
- git branch — Lists branches
- git branch -d <branch name> — deletes a branch
- git branch -a — lists local branches as well as remote
- git branch -r — lists all remote branches
- git branch -vv — lists tracking branches
- git merge <branch> -merge the specified branch to the current one
Listing
- git log — lists all commits in current branch’s history
- git ls-files -s — lists all the files in staging area
- ls -ltr — lists all file in a directory
- ls -lart -lists all files in a directory including hidden
- git show — display the recent commit
Tags — Git Tags are static text pointers to specific commit
- git tag v1.0.0 — creates a lightweight tag v1.0.0
- git tag -a v1.0.0 -m “Tag message” — creates an annotated tag v1.0.0
- git tag — lists tags
Remote
- git remote add origin URL — connects remote repo to local repo
- git clone URL — creates a local working copy of an existing remote repository
- git remote — list of remote git servers
- git remote -v — it also displays the fetch and push URL
- git remote show origin — detail information about local repository and remote repository
- git fetch — fetch all the branches from the Git Remote Repo
(doesn’t update your local working directory) - git merge — merge the specified branch to the current branch
(merges the changes of your local git repo toyou local working directory) - git pull — fetch and merge commits from the tracking remote branch
- git push — transmit local branch commits to the remote repository branch
- git push origin -u <new branch> — pushing a branch to the remote repo
Rewrite history
- git reset — hard <commit> — clear staging area, rewrite working tree from specified commit
- git rebase — merges two or more branches together and rewrites history
Temporary Commits
git stash — save modified and staged changes
git stash list — list stashed files
git stash pop — brings changes back to staging area
git stash drop — discard changes from stash stack
Git log options
- git log — displays complete information about all commits on the branch
- git log — oneline — one line view of git log
- git lg — one line view of git log with date and author name
- git log — graph — graph of the commits with detail information of commits
- git log — stat — additional information about changed files
- git log -p — displays the actual changes of the commits
- git log -4 — displays latest 4 commits
- git shortlog -displays list of commits performed by the a particular author in a sorted way
- git shortlog -n -sort quantity of commits by author
- git shortlog -n -s -list of authors and number of commits
- git shortlog -n -s -e list of authors and number of commits and email
Rebasing (git rebase)
Used for merging two or more branches. Do not use it on public branches like master/release as it may be destructive as it rewrites history
Rebasing is a 2 step process
- Rebasing of feature branch on master branch
- Merging of feature branch on master branch (using fast forward merge and no commit will be created)
Pros : History becomes linear as it doesn’t keep history of all commits
Cons : Rewrites history
Reset (git reset)
It is destructive and it rewrites history. By default it performs reset with mixed options.
Revert (git revert)
https://www.atlassian.com/git/tutorials/undoing-changes/git-revert
It reverts specific commit and creates changes in that and creates a brand new commit.
Git reset Vs Git revert
Git Merge
Git merge
will combine multiple sequences of commits into one unified history. In simple word git merge is used to combine two branches.
There are two main ways Git will merge:
Fast Forward
3-way merge
Fast Forward Merge
A fast-forward merge can occur when there is a linear path from the current branch tip to the target branch. Instead of “actually” merging the branches, all Git has to do to integrate the histories is move (i.e., “fast forward”) the current branch tip up to the target branch tip. This effectively combines the histories, since all of the commits reachable from the target branch are now available through the current one. For example, a fast forward merge of some-feature into master
would look something like the following:
example of fast Forword merge ,
3-way merge
However, a fast-forward merge is not possible if the branches have diverged. When there is not a linear path to the target branch, Git has no choice but to combine them via a 3-way merge. 3-way merges use a dedicated commit to tie together the two histories.
example of 3-way merge ,
Merge conflict
If the two branches you’re trying to merge both changed the same part of the same file, Git won’t be able to figure out which version to use. When such a situation occurs, it stops right before the merge commit so that you can resolve the conflicts manually.
Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run git status
:
HOW TO RESOLVE CONFLICTS??
After seeing a conflict, you can do two things:
- Decide not to merge. The only clean-ups you need are to reset the index file to the
HEAD
commit to reverse 2. and to clean up working tree changes made by 2. and 3.;git merge --abort
can be used for this. - Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit or git merge — continue to seal the deal. The latter command checks whether there is a (interrupted) merge in progress before calling git commit.
You can work through the conflict with a number of tools:
- Use a mergetool.
git mergetool
to launch a graphical mergetool which will work you through the merge. - Look at the diffs.
git diff
will show a three-way diff, highlighting changes from both theHEAD
andMERGE_HEAD
versions. - Look at the diffs from each branch.
git log --merge -p <path>
will show diffs first for theHEAD
version and then theMERGE_HEAD
version. - Look at the originals.
git show :1:filename
shows the common ancestor,git show :2:filename
shows theHEAD
version, andgit show :3:filename
shows theMERGE_HEAD
version.
Github link → https://github.com/snehalhingane
Follow me on LinkedIn → https://www.linkedin.com/in/snehal-b-hingane-a4b14217b/