Let’s first discuss the difference between git commands namely “git –pull” and “git –fetch“. If we are talking about git pull and fetch then we are working with the Remote repository and want to update the local branches with the remote branches in a different manner. git pull does a git fetch followed by a git merge as depicted in the picture below as follows:
git pull: When you use git pull, git tries to automatically merge. git will merge any pulled commits into the branch you are currently working on. git pull automatically merges the commits without letting you review them first. If you don’t carefully manage your branches, you may run into frequent conflicts.
git fetch: When you do not want to directly merge the changes from the remote repository and want to first review the code, then it is suggested to use git fetch.
Git clone vs fork can be treated as:
- Forking: GitHub Account
- Cloning: Git
When you fork a repository from your GitHub account, you create a copy of the upstream repository but the repository remains on your GitHub account and not on your local machine. Whereas, when you clone a repository, the repository is copied onto your local machine with the help of Git but at this moment has nothing to do with your GitHub account.
- When you fork a repository from your GitHub account, you get a completely independent copy of the repository in your account and now if you clone this repository into your local machine then the upstream for the local repository will not be the original repository but rather your own copy of that repository in your account.
- Therefore, now all of your PUSH and PULL requests from your local git will point to the upstream that is your copy of the repository.
Git Stash
In order to understand this command let us assume for a moment that git doesn’t have a command to stash changes. Suppose you are working on a repository with two branches, A and B. The A and B branches have diverged from each other for quite some time and have different heads. While working on some files in branch A, your team asks you to fix a bug in branch B. You quickly save your changes to A and try to check out branch B with git checkout B. Git immediately aborts the operation and throws the below error stated as follows:
"Your local changes to the following files would be overwritten by checkout … Please commit your changes or stash them before you switch branches."
Note: This is exactly the kind of scenario git stash is designed for.
Git stash saves(stashes) the uncommitted changes in your local machine, which in turn allows you to make changes, switch branches, and also perform other Git operations. You can then reapply the stashed changes when you need them.
git stash: save for later use
Git stash temporarily saves changes you’ve made to your working copy so you can work on something else, and then come back and re-apply them later on. Stashing is handy if you need to quickly switch context and work on something else, but you’re mid-way through a code change and aren’t quite ready to commit.
The git stash command takes your uncommitted changes (both staged and unstaged), and saves them away for later use. Do remember certain important key points listed below as follows:
- The stash is local to your Git repository; stashes are not transferred to the server when you push.
- Git temporarily saves your data safely without committing.
Difference Between Git Merge and Git Rebase?
Git Merge and Git Rebase are both used to combine the changes of branches but in different ways.
Let us consider a scenario, you started working on a new feature in a dedicated branch, then the main branch is updated by other team members with new commits. This results in a forked history, which is very common in Git.
Now, if the commits in the “main” branch are relevant to your feature branch and you want to incorporate those commits into your feature branch. Right now you have the following two options: Merging or Rebasing.
Merging: If we choose the Merge option then “The history of both the branches remain intact” and the existing branches are not changed in any way.
Note: merge executes only one new commit
Rebasing: If we choose the Rebase option then the entire feature branch is moved to begin on the tip of the main branch, effectively incorporating all the commits of the feature branch as new commits in the main branch.
Rebasing re-writes the project history by creating brand new commits for each commit in the original branch.
You must be wondering when to use Merge and when to use Rebase?
A. Use Merge When:
- You want to preserve the complete commit history and the chronological order.
- We want to add changes to a feature branch back into the main branch.
- You want to revert the changes quickly.
B. Use Rebase When:
- You want to squash multiple commits.
- Maintain a streamlined simple commit history.