Let’s take a look at some Git commands that will allow us to make the most out of this great version control system, particularly in large projects, where pull requests are common and there’s a keen interest in keeping a clean commit history, as thousands of people might be working on the same project at the same time.
rebase
As the name suggests, “git rebase” bases a branch out of another. While the common practice is to perform “git merge feature-branch base-branch”, sometimes we want a cleaner commit history. Perhaps it’s always not so relevant to know how the branches evolved through time, which is why someone would instead use a rebase command.
The rebase command takes a feature branch, finds the last common commit between the feature branch and the base branch, and “plugs” the feature branch onto the tip of the base branch, starting from that last common commit, up to the final commit from the feature branch. That’s where the name “rebase” comes from, the user bases or redefines a feature branch out of the latest changes of a main or base branch. Rebasing is considered an advanced command because it’s similar to performing many commits to a master branch. This implies that other people working on that branch will get their work disrupted by the rebasing. Keeping this in mind is known as the “Golden Rule of Rebasing.”
On the other hand, rebasing is still helpful as it allows for a clean and easy-to-navigate hit commit history. Rebasing is oftentimes done alongside “squashing,” another command which we’ll discuss briefly.
–squash
The squash option can occur in different commands or contexts, most commonly when doing “git merge –squash” or “git rebase -i.” In both cases, squashing gets rid of commits that might not be relevant to a repository’s history, merging a sequence of commits into a single one. Squashing is mostly used when rebasing or merging, so developers can just look at a single commit with a clean message saying “feature X implemented.” Of course, the ideal scenario would be one where these squashed merges are appropriately tested and considered final, so there’s no need to dissect them to find pesky bugs.
–amend
The “git commit –amend” command lets developers merge the previous commit with the current staged changes, all while resulting in a single, new commit. This helps fix quick mistakes in the commit messages. Similar to rebasing, one must avoid amending commits that other developers might be working on, as it will mess up their working tree. The amend option is also used after a rebasing to clean up a branch’s history. Developers may rebase a series of past commits, pause the rebase process by pressing “e” or “edit,” and proceed to make extra changes.
reflog
While it’s possible to rewrite the history of a tree’s commits, there’s always a way to trace back these changes even if they seem impossible to recover. This is the job of “git reflog,” a method to see the Git reference logs, which record most events that take place, even commits that are not referenced by tags or branches. Reflog allows for last-resort solutions, allowing the user to check for HEAD changes through time, making it possible for a simple “git reset” to fix most problems that would otherwise take hours to figure out how to solve.
Source: https://www.atlassian.com/git/tutorials/advanced-overview
