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     ORgit stash push -m "<stash message>"

To get back the changes you made, use:

git stash apply     ORgit 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>}     ORgit 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     ORgit 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>     ORgit 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!

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.

1. I am a beginner, how should I learn Front-End Web Dev?
   Look into the following articles:

   1. Front End Development Roadmap
   2. Front End Project Ideas

2. Would you mentor me?
   
   Sorry, I am already under a lot of workload and would not have the time to mentor anyone.

3. 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.