REBASE
Rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch.
In other words, Rebasing is the process of combining or moving a sequence of commits on top of a new base commit. Git rebase is used to maintain the linear project history.
To sum it briefly, when you conduct a git rebase, you’re saying that you want your changes to be based on what other developers have already done.
git rebase <branchname>
Here you can see that main branch has its head on m3.
Feature branch has its head on merged.
After rebasing, the main branch heads move to merged. And all the commits of feature/main branch is visible in a linear way.
Stash
Suppose a developer is working on a feature in a branch and he needs to pull changes from some other developer’s branch or if he has to work urgently on some other feature, but the feature he is currently working on is incomplete and he cannot commit the partial code of the currently working feature. To add the new feature, he have to remove his current changes and store them somewhere else. You can store your incomplete changes by using git stash.
In Short, Stash is used to store your temporary work.
git stash will saves our previously written code and then returns to the last commit for a fresh start and it will not affect the existing modification.
git stash
Some more functionality of git stash:
git stash pop -> removes the changes from the stash and reapplies the changes in the working copy.
git stash apply -> only reapplies the changes in the working copy without removing the changes from the stash.
git stash drop -> drop the most recent stash changes or deletes a stash from a queue.
Squash
Squashing is a technique to combine multiple commits into a single commit based on our commit history.
With the help of squashing you can clean your branch history and can maintain an organized commit timeline. It is used before pulling requests or merging feature branches.
Suppose we have released version1 and after that we wanted to add new features for the version2 release. We have fixed some of the bugs which were found in version1 and had many commits piled up after our version1 release.
So, for merging those multiple commit into a single commit. We will use the below command:
git merge --squash <branch> -> Squashing multiple commits into a single.
git rebase -i HEAD~n -> Squashing Last n Commits.
git merge --squash <branch> Example:-
In the below snapshot, the branch is feature branch and latest commit is f7.
For the main branch, the last commit was merged as you can see below.
We have done squashing of commits of feature branch
When you will do "git status", you can see the file is in modified state. We need to commit it. Here, we have m4 as our commit. And lastly it got merged to master with a single commit i.e. m4.
git rebase -i HEAD~n Example:
Cherry-pick
Cherry-picking is a technique for choosing a commit from a branch and applying it to another branch.
Suppose we are working in "Test_branch" and have two commits. Let's say C1 and C2. Now for "main" branch, we don't want C2.
If we merge Test_branch to main branch then the both commits will get merged.
So, if we want a particular commit of one branch to merge it to another branch then we do cherry-picking.
git cherry-pick <commit_id>
We are picking f7 commit of feature branch and applying it to test branch.
When to use git cherry-pick?
Suppose a developer fails to recognize which branch he is currently on, and by mistake, he commits to another branch instead of committing to the main branch. Now to fix it, he has to first run git show, then save the commit, check out the main branch, apply a patch there, and commit with the same commit message.
So, this can be done automatically by git cherry-pick command.
git fetch vs git pull
git fetch command fetches all the changes from the remote repository to the local repository without bringing the changes into the working directory.
git pull on the other hand brings the copy of the remote directory changes into the working directory.
git restore
git restore command helps to unstage or even discard uncommitted local changes.
On the one hand, the command can be used to undo the effects of git add and unstage changes you have previously added to the Staging Area.
On the other hand, the restore command can also be used to discard local changes in a file, thereby restoring its last committed state.
git restore filename -> If you want to discard uncommitted local changes in a file. However, you cannot undo this!
git restore --staged filename -> To only unstage a certain file and thereby undo a previous git add.
git clean
The Git Clean command is used to clean the untracked files in the repository. If we want to remove the unwanted files then we can use the clean command in Git.
By cleaning git you improve the performance of git and the size of the repository will be decreased.
The use of the Git Clean command is as follows:
git clean -n: to dry run.
git clean -f: forcefully file deletion.
git clean -f -x: delete .gitignore files
git clean -f -d: delete the untracked directories.
git clean --dry-run: to know which files/directories are going to be cleaned.
git clean --ignored: remove the files which are ignored by git.
git remote prune <Alias name of remote repository>: once the remote branches are deleted or no longer needed, we can use this command to remove references to those branches from the local repository.
git dirt
In Git, a working tree is said to be “dirty” if it contains modifications which have not been committed to the current branch . This means that the working directory has changes that are not yet staged or committed.
If files have been updated in the working directory after they were updated in the index, then the working directory is considered “dirty” . The index is also known as the “staging area” and is a place where files will be stored when you have changed them, want to commit them, but haven’t done a commit yet.
amend
This option enable the user to amend the last commit.
If user do not specify commit message with "-m" option. Then they will be prompted with the message of previous commit command by default.
amend command doesn't create a new commit but edits the last one.
git commit --amend
git ref
A ref is an indirect way of referring to a commit. You can think of it as a user-friendly alias for a commit hash. This is Git’s internal mechanism of representing branches and tags.
Refs are stored as normal text files in the .git/refs directory, where .git is usually called .git.
git reflog
git reflog records almost every change you make in your repository, regardless of whether you committed a snapshot or not.
You can think of it as a chronological history of everything you’ve done in your local repo. To view the reflog, run the bellow command:
git reflog
Output of git reflog:
git blame
git blame displays the details of the author who last modified or added each line of a code in a given file along with the commit id of modification.
The commit id can be used with the git log command to get the details of the commit.
git blame <filename>
git patch
git patch enables us to create a patch file from a feature in one branch and apply it in another branch.
Suppose you are working on a project. The main project is in the "main" branch and you are working on a feature in separate branch say "Test_branch" and make all the changes to this branch. Then create a "patch" file which can be used in the "main" branch to add that particular feature you worked on.
git format -patch <branch we want to apply patch> -o <location of patch file> -> This will create patch file.
git am <patch file> -> To apply patch.
Conclusion
In Conclusion,
We have seen about:
\> git rebase
\> git stash
\> git squash
\> git cherry-Pick
\> git restore
\> git fetch vs git pull
\> git clean
\> git dirt
\> git commit --amend
\> git ref/reflog
\> git blame
\> git patch
👆The information presented above is based on my interpretation. Suggestions are always welcome.😊
~Smriti Sharma✌