Have you gotten accustomed to the basics of git
, but the advanced concepts make you scratch your head?
This article got you covered, not only will it introduce you to the advanced git
concepts, but also show you how to use them in a real-world scenario! Let's dive in.
Stash
Let's first check the definition:
Git stash is a built-in command with the distributed version control tool in Git that locally stores all the most recent changes in a workspace and resets the state of the workspace to the prior commit state.
The stash can be thought of as a temporary storage for the changes you made, but did not commit.
The real-world use case for this feature would be when you are not done working on the changes, but need to pull the updates from the remote repository.
To use stash, you need to add the files to the staging area
git add .
and push it to the stash
git stash push
OR
git stash push -m "<stash message>"
To get back the changes you made, use:
git stash apply
OR
git stash pop
The difference between apply
and pop
is pop
applies the changes in the stash and removes it from the stash too, but apply
keeps the changes in the stash even after applying it.
To view the items in the stash use:
git stash list
If you have multiple stashed changes, you can use the index to select the one you need
git stash apply stash@{<n>}
OR
git stash apply <n>
Get Back Deleted Commits
Ever used the reset
command with the --hard
flag? If you have, it's the right time to freak out, as it completely removes the number of commits specified.
Don't panic, reflog
got you covered! To view the changes, you recently made, run:
git reflog show HEAD
OR
git reflog
You can now view the changes you made recently.
Now you can directly get back the commit using:
git reset --hard <commit hash>
NOTE: If you have any local modifications, the command will destroy it as well, so it would be wise to use the stash before resetting.
Cherry Pick Commits
Need a feature introduced in a commit in another branch, but the branch is not ready to be merged yet? No, you don't have to take the 500-year long nap till the branch is merged!
You can just Cherry Pick the commits you require
git cherry-pick -x <commit hash>
OR
git cherry-pick <commit hash>
It's highly suggested that you do use -x
flag as it will generate a standardized commit message, informing users where it was cherry-picked
from.
Rebase
Rebasing is the process of moving or combining a sequence of commits to a new base commit. The primary reason you would like to use rebase
in your project is to maintain a linear project history, making it much easier to view the logs.
Thus rebase
allows you to work off the latest changes on any branch, even though you started working before the changes were introduced. It also helps you in the case of Fast Forward Merge discussed in the Merge Strategies section.
To rebase, use
git rebase <source branch>
Thus to recreate the example in the image, you would move to the feature branch and run:
git rebase main
Caution
Rebasing creates new commits while rewriting the history. Thus you should avoid rebasing once the branch is pushed to a public repository as it might cause issues where the old commits with new ones and it would look like that part of your project history abruptly vanished.
Merge Strategies
"Why bother learning about the Merge Strategies?" you may ask. My answer would be, I wanted to add 5 concepts instead of 4, so here we are π. PS: Don't forget to drop a β€οΈ for honesty.
This is one of the good-to-know concepts, with little repercussion if you don't know it. It can help you a bit while navigating the commit logs though, where otherwise you might end up wondering how the merge took place without commits.
There are several Merge Strategies:
- Fast Forward
- Recursive
- Ours
- Octopus
- Resolve
- Subtree
The commonly used strategies are Fast Forward and Recursive, which we will be looking at.
Fast Forward Merge
The Fast Forward Merge takes place when the destination branch of the merge does not contain any new commits. In such a case, only the pointer of the branch is moved forward to the required commit. It does not add any new commits!
Example of merging feature on master
Recursive Merge
The Recursive Merge takes place where both the source & destination branches of the merge contain new commits. In such a case, a new commit is introduced in the destination branch, merging all changes.
Example of merging master on feature
You can also force Recursive Merge using:
git merge --no-ff
Wrapping Up
Starting the year with advanced git
skills in your arsenal, you are ready to take on the world!
Happy Developing!
Finding personal finance too intimidating? Checkout my Instagram to become a Dollar Ninja
Thanks for reading
Need a Top Rated Front-End Development Freelancer to chop away your development woes? Contact me on Upwork
Want to see what I am working on? Check out my Personal Website and GitHub
Want to connect? Reach out to me on LinkedIn
I am a freelancer who will start off as a Digital Nomad in mid-2022. Want to catch the journey? Follow me on Instagram
Follow my blogs for Weekly new Tidbits on Dev
FAQ
These are a few commonly asked questions I get. So, I hope this FAQ section solves your issues.
-
I am a beginner, how should I learn Front-End Web Dev?
Look into the following articles: Would you mentor me?
Sorry, I am already under a lot of workload and would not have the time to mentor anyone.Would you like to collaborate on our site?
As mentioned in the previous question, I am in a time crunch, so I would have to pass on such opportunities.
Top comments (8)
Nice article. Just some corrections about stashing:
You don't have to add changes to staging area to be able to stash it.
Example:
Here I have an unstaged file (which is being tracked), a staged file and an untracked file.
If I want to stash all tracked files, I can just do:
If I want to include untracked, I can add
-u
.Thanks for sharing!
Nice article, many thanks for creating this
Glad you found it helpful :)
I would not call it advanded concepts, those are advanced but commands.
If you really want to know advanced git I suggest reading this article:
Becoming a Git pro. Part 1: internal Git architecture
But I'm also not sure if it explain the concepts well.
If you're using the latest git version there's a new merge strategy (which is the default) called ort.
It's premise is that it's smarter with conflicts auto-resolution, I felt no differenve though
Thanks for mentioning, will look into it!