Today, I will go through some important git commands that are necessary for collaboration with teams. These Git Commands are important for beginners to learn before they become a part of a coding team in a company. But if you don’t know anything about GitHub, here is a guide for you to start with.
Must-Learn Git Commands You Should Know
I will cover different merging strategies and how to fetch and revert changes safely, and finally, I will teach you how to selectively add commits from one branch to the main branch without merging the branch entirely! You’ll be well-equipped to work in a team environment after you know and master these tricks.
It’s a fun topic, so let’s get into that.
1) Merge
Merging in Git is the process of combining changes from different branches into one branch. It’s a fundamental feature that allows multiple developers to work on separate parts of a project simultaneously and then merge their changes together.
Let’s suppose we have a branch called “new-feature” and the main branch is called “main”. We branched from the second commit of the main as follows:
After continuing working on the “new-feature” branch, we decided to merge it into the main. We can achieve that by the following commands:
git checkout maingit merge new-feature -m “merging commit”
2) Rebase
Sometimes, adding a merge commit after every merge is a tedious work and can make the git history a little bit confusing. For such a case, we can rebase. Rebase is a powerful feature in Git that allows you to move or combine a sequence of commits to a new base commit.
The purpose is to create a linear history of commits instead of having unnecessary merge commits.
Rebasing basically takes the commits on one branch and applying them after the last commit of another branch. Usually, it’s done by rebasing a feature branch onto the main branch.
Let’s suppose we have a feature branch called “new-feature” and the main branch called “main”. We can rebase onto the main branch by first pulling the latest changes from the remote onto the main branch:
git checkout maingit pull
Then we can apply the actual rebasing:
git checkout new-featuregit rebase main
And the result is as shown in the diagram below:
What happens if there were any conflicts? Git will automatically pause and wait for you to resolve the conflicts and add the resolved files to the staging area and committing them again and continue the rebase process.
So, after it pauses and you resolve your conflicts, you can do the following:
git add resolved_file.txtgit rebase --continue
If at any point in the conflict-resolving process, you decide that it is too complicated to rebase and want to abort the process, you can do:
git rebase --abort
If the rebase is done successfully, you can merge the commits made inside the new-feature branch into the main branch:
git checkout maingit rebase new-feature
Finally you can push the changes but you have to force push since you re-wrote the git history:
git push origin new-feature --force
If you look at the diagrams between the basic merge and the rebase, you can see that basic merge creates a merge commit, while rebasing keeps a linear commit history without the need of unnecessary merge commits.
3) Squash
Squashing allows you to condense multiple commits into one. This is useful for cleaning up your commit history before merging changes into the main branch.
Again, let’s suppose we have a main branch from which we branch into a new branch called “new feature” as shown below:
Now we want to merge the “new feature” branch into the main branch. But instead of doing so as in the basic merge, let’s squash the two commits we made before we merge:
git merge –squash new-featuregit commit -m "Squashed commit message"
This will squash the commits into a single merge commit as shown in the diagram below:
4) Revert Unstaged Changes
You can discard unstaged changes (i.e., revert the file to its state in the last commit) by using this command:
git restore filename
Or you can restore all the files to the latest commit:
git restore
5) Revert Staged Changes
You can use git reset to unstaged changes, which will move the changes from the staging area back to your working directory.
To revert a specific file:
git reset HEAD filename
To revert everything:
git reset HEAD
6) Fetch vs. Pull
Fetch and pull commands are very similar, yet different. Sometimes you want to see what changes people have made to the remote branch but not necessarily to incorporate them into your local branch. That is the “fetch” command. But if you want to fetch and merge the changes on your local branch, that’s “pull”.
In other words, pull = fetch + merge.
Fetching downloads commits from a remote repo to your local clone, but doesn’t merge them. It updates your remote-tracking branches (e.g., origin/main) but doesn’t merge these changes into the working branch.
This is a safe way to see what others have been working on without changing your current files. Many experienced developer prefer to use git fetch instead of git pull because it’s safer and gives more control.
“git pull” on the other hand, first fetches the latest changes from the remote repository and then automatically merges those changes into your current working branch.
It updates your working files and local branch with the latest changes from the remote repository, which can potentially lead to merge conflicts if both you and someone else have made changes to the same parts of the code.
7) Cherry pick!
Believe it or not, “cherry pick” is a git command and it is useful when you want to copy specific commits from one branch to another without merging the entire branch.
git cherry-pick <commit-hash>
To know the hash of the commit, use: git log –oneline
And if you are looking for the latest commit, you can use: git show
What if you want to “cherry-pick” multiple commits at once? You can simply pass different commit hashes, and they will be applied to your current branch.
git cherry-pick <commit-hash-1> <commit-hash-2> <commit-hash-3>
Conclusion
These were some useful, yet uncommon commands in the coding bootcamps. They might not be useful as a solo developer, but for collaboration with teams, they are crucial.
