Lesser-known git commands that make your job easy

Lesser-known git commands that make your job easy

1) Create the remote branch if it doesn't exist while pushing your commits from the local branch. (SAVES YOU TIME)

We often want to push code to branches and not to master branch. We can use '-u' option of the git push command to create a remote branch if it doesn't exist and also push local commits to the newly created branch.

git push -u origin <localbranch>

This will create a branch with the same name in remote origin and also push the local commits to the newly created branch.

2) How to rename a branch

We can use -m option of command to rename the branch name. Below command renames the branch from to

git branch -m <old_branch_name> <new_branch_name>

3) Recover commits from the deleted branch ( VERY USEFUL WHEN THINGS GO WRONG)

We can recover commits deleted accidentally using reflog command.

git reflog

b656235 (HEAD -> new_ls) HEAD@{0}: checkout: moving from master to new_ls
e8bd479 (new_branch, master, ls) HEAD@{1}: checkout: moving from b656235a77c7d82d4cb949c54bc79d6e94cfe346 to master
b656235 (HEAD -> new_ls) HEAD@{2}: checkout: moving from ls to b656235
e8bd479 (new_branch, master, ls) HEAD@{3}: reset: moving to HEAD~1
b656235 (HEAD -> new_ls) HEAD@{4}: checkout: moving from new_branch to ls
e8bd479 (new_branch, master, ls) HEAD@{5}: checkout: moving from ls to new_branch
b656235 (HEAD -> new_ls) HEAD@{6}: commit: testing reflog
e8bd479 (new_branch, master, ls) HEAD@{7}: checkout: moving from master to ls
e8bd479 (new_branch, master, ls) HEAD@{8}: checkout: moving from old_branch to master
e8bd479 (new_branch, master, ls) HEAD@{9}: checkout: moving from master to old_branch
e8bd479 (new_branch, master, ls) HEAD@{10}: checkout: moving from branch1 to master
e8bd479 (new_branch, master, ls) HEAD@{11}: checkout: moving from branch2 to branch1
e8bd479 (new_branch, master, ls) HEAD@{12}: commit (initial): First Commit
(END)

Reflog shows the history of actions performed on references(branches). Above in HEAD@{6}, I have created a commit b656235. I have deleted the same commit using the reset command in HEAD@{3}. Then recovered it in HEAD@{2} using checkout.

git reflog helps to recover the lost commits.

4) Git aliases. ( SHORTCUTS )

Git alias can be used to shorten the long commands. Below command can be used to show the last commit.

Usage: git config --global alias.last 'log -1 HEAD'

Example: git last

UK7zpAF9-.png

5) Git log variations. ( FEW VARIATIONS)

--oneline can be used to show commits in one line for a quick scan.

git log --oneline

288a345 (HEAD -> ls) add file b
ea61e8f add a file
e8bd479 (new_branch, master) First Commit

-p option can be used to view the file contents and changes made as part of the commit.

Screen Shot 2020-11-18 at 9.11.15 PM.png

6) Git Bisect to binary search against commit history to find the bad commit. (IT'S POWERFUL)

git bisect command can be used to find the buggy commit. Bisect uses binary search over commit.

To initiate the search: git bisect start then mark the commit good or bad using: git bisect good or git bisect bad to reset the search after finding bad commit: git bisect reset

High-Level Flow:

Untitled.jpg

Example: There are six commits

Screen Shot 2020-11-18 at 10.44.29 PM.png

Bisecting:

ertc4ie41.png Start the bisecting using git bisect start Then choose the good and bad commits. I have marked my second commit (888be3) as good. Marked my latest or sixth commit (42a566) as bad.

Bisect suggested me the mid of 2nd and 6th commits, which is the 4th commit. To verify if its a bad /good commit?

As I have said that it's a good commit, then git suggests the mid of 4th and 6th, which is the 5th commit.

I have marked it as bad ( considering that has bad code), hence found our bad commit.

7) Use of --squash to merge multiple commits of the feature branch as a single commit in master.

git merge --squash can be used to create a single commit in master. All the commits in the feature branch are added in master as untracked files and can be committed in master. Then we can review and explicitly commit the changes in master as a single commit. Be aware of not introducing a big commit as it makes debugging difficult.

Please like if this helps you and comment if you have questions or feedback.