Common Git Tips



Obtain list of commits

git reflog --oneline
git log --oneline

These commands will also print commit ID - a.k.a. commit hash.

Obtain list of branches created by a user

git for-each-ref --format=' %(authorname) %09 %(refname)' --sort=authorname | grep <username>

Obtain branch hash

git show-ref branch_name

Delete a local/remote branch

Assume that a branch "bugfix/114355" is created to fix a bug. To delete the local branch:

git branch -d bugfix/114355
git branch -D bugfix/114355

'-D' is same as specifying "--delete --force".

To remove the remote branch as well:

git push origin --delete bugfix/114355

Undo last commit

git reset --soft HEAD~1

Roll back repo to a commit

To roll-back the repository to a particular commit, follow these steps.

  • find the hash corresponding to the particular commit by checking the commit logs:
    git log --oneline
  • roll back the repository by resetting the HEAD pointer:
    git reset --hard <commit_hash>

Remove the latest commit entirely

If changes are staged (only "commit" is done)

git reset --hard HEAD^
git reset --hard THE_COMMIT_HASH

If changes are committed (commit and push done)

git checkout HEAD^
git commit --am 'revert'
git push

If this operation needs to be done for a specific file, add "-- filepath" to above command, like

git checkout HEAD^ -- /path/to/file

Note: "--hard" option will completely remove the changes from the staging area also, if intention is to retain those changes in staging area, use "--soft" option instead, in the above commands.

Comparison between two branches

git diff-tree -C -r branch1_hash branch2_hash

List different commits between two branches

To list all commits

git log --left-right --graph --oneline branch1...branch2

To list all commits specific to a file

git log --left-right --graph --oneline branch1...branch2 -- <fileame>

Squashing multiple commits

Warning: Doing this on the remote branch is dangerous because other developers might have pushed their changes on it and squashing would destroy their work too, so please be diligent.

It is always better to squash multiple commits made to your local branch (while implementing a feature or a bug fix), and then push the code to the remote branch. It makes commit history much cleaner and simpler to understand.

Assume that there are 4 commits done on your local branch as part of implementing a bug fix. To squash all these commits into single one, follow these steps.

git log --oneline

This will provide the short history of commits. Decide how many of these are to be squashed. Let's assume the top 4 needs to be squashed.

git rebase -i HEAD~4

In the editor window shown after this, leave the top-most "pick" as is, and change all subsequent "pick" word to "squash". Save the file and exit.

Another editor window will open, showing all the commit messages entered so far. Edit/delete the messages as per requirement. Save file and exit.

git push --force-with-lease origin HEAD

Splitting last commit into multiple commits

This is a slightly tricky situation and should be dealt with extreme care and diligence. Backup all code changes to a safe place before taking any step further. Situation is as follows:

  • Everything is in the context of developer's private bugfix branch.
  • There is a single commit made, which has gone to the remote branch. A Pull Request is also raised for this commit, but it is under review (meaning it is not cleared for further merge yet).
  • Since there are many sub-modules which have code changes, it is desirable to split the single commit into multiple commits, each corresponding to one sub-module.

This was handled using following procedure. AGAIN: BE EXTREMELY CAREFUL!

In local branch:

  • squashed all previous commits for the task into single one (please refer squashing section above).
  • pushed it to the remote branch as well.

Performed git pull to synchronize local and remote branches. Then,

git reset HEAD~
git stash push

The last command stashed all changes, which are now visible due to "git reset".

Since the commit is also on the remote branch, pushed the local changes to remote to remove the last commit from remote branch.

git push origin +HEAD^:bugfix/114355-name-of-the-branch

Make sure local and remote branches are synchronized.

git pull
git stash pop

Last command restored all changes to the local workspace.

Now, for each individual component, following commands were issued.

git add <component_specific_files>
git commit -m "message" <component_specific_files>
git push

This created multiple individual commits instead of a single one.

Rebasing a branch

To rebase feature-branch onto second-branch, using interactive mode:

git checkout feature-branch
git rebase -i second-branch
git push --force-with-lease

Excellent collection of Git commands can be found at GitHub Docs.


 

Comments

Post a Comment

Popular posts from this blog

Security in Linux Kernel - Part 2

Image
  In the previous part of this series, we saw role of LSMs in kernel security. As mentioned earlier, there are eight LSMs available today in the modern Linux kernel. In this part, let's have a look at different main stream LSMs. SMACK Simplified Mandatory Access Control Kernel ( SMACK ) is designed primarily for embedded linux systems with an intention to make it easier for administrators. This was the second LSM (after SELinux) to be accepted in the linux kernel. It appeared in the 2.6.25 kernel release. This is an attribute (label) based simple LSM, and is the default for Linux implementations tuned for Automotive industry. Yama Yama collects system-wide DAC security restrictions that are not handled by the core kernel itself. It offers control over scope of ptrace() system call to control ptrace attachment by processes. Build time configuration option CONFIG_SECURITY_YAMA and runtime option through sysctls can be used to enable this LSM. The ptrace restrictions can be controll...
Read more

Security in Linux Kernel - Part 3

Image
  In this short post we will explore a Linux system call facilitating secure computing. In earlier parts of this series we saw how LSMs protect the kernel. However, LSMs occupy a much deeper position in the call hierarchy and do not offer protection at process level. Additional mechanism is required to provide protection at process level. Need for a system call In Linux, applications programs use a number of system calls, in fact a large number of system calls are available to applications programmer. These processes using system calls expose a large area of the kernel to malicious attacks. Linux offers a mechanism to limit this capability using seccomp system call, thereby reducing the attack surface. seccomp is enabled using prctl() system call with appropriate operation mode. seccomp Modes The seccomp system call works in two modes - strict mode (SECCOMP_SET_MODE_STRICT) and filter mode (SECCOMP_SET_MODE_FILTER). When seccomp is set to first mode, i.e. strict mode , process has ...
Read more

Trusted Platform Module

Image
In the previous article, we discussed end device security and various factors affecting it. There was a fleeting mention about TPM - the Trusted Platform Module. In this installment we will discuss mode about the TPM. Generally, for any device, the safest way to ensure it's integrity is to make sure it always boots from a secured, verified and unalterable source. This forms the logical "root" of the entire boot process. Once the device boots from a trusted source, it further uses it to verify each and every software component it utilizes. Every module checks and verifies integrity of the next module to be loaded thus forming a "chain of trust" which if broken can be easily detected. This chain of trust then can be extended to encompass other devices across and upstream the network hierarchy. In this installment, let's have a deeper look at TPM. What is TPM? TPM is (generally) a chip designed to provide security related functions. It provides functiona...
Read more