Version control is necessary, but using it well is an art. Today I am going to give an overview of two Git commands that I found helpful during software development,
git cherry-pick and
git rebase in interactive mode.
Software development is often a team game. To work within the planned schedule, each developer will implement features in their own feature branches. But sometimes there are changes that everyone wants!
git cherry-pick is a Git command that lets the developer pick a commit and apply it their branch. This command comes in handy when you want to use features implemented by other developers but your branch isn’t built off their branch. This comes in handy when you need just one change they made, but don’t want all of their changes right now.
As an example, consider this scenario: an existing bug made it into the main branch. A developer solves it in their branch. They’re still working, but you’re done. Instead of waiting for the fix to make it into the main branch, or creating an entirely new branch just for the fix, you can “cherry-pick” the commit that fixes the bug into your branch.
# Check out the branch you are interested in cherry-picking from % git checkout <interested-feature-branch> # Look for the commit SHA of the commit you want to cherry-pick # Note: Press enter/return to scroll down the list and press q to exit % git log # Check out your branch % git checkout <your-feature-branch> # Cherry-pick the commit to your branch % git cherry-pick <commit-sha>
Git Rebase Interactive
While cherry-picking can be valuable, it can also cause duplicate commits and can lead to unnecessary code conflicts during pull requests. To avoid this, we can “squash” the commits before creating a pull request. To do this,
git rebase in interactive mode. Unlike the standard
git rebase that rebases all commits to the desired branch, you have control over your commit history with an interactive
# Check out your branch % git checkout <your-feature-branch> # Rebase interactively on another branch, e.g. master % git rebase -i <another-branch> # You can also use % git rebase --interactive <another-branch>
git rebase -i will list the commits on the current branch in a vim editor. You can remove or squash commits here.
The following is an example after calling
git rebase -i .
pick 7cb4839 Old commit 1 pick e616408 Duplicate commit pick 79bd7a2 Old commit 2 pick fcaf152 fixup! Old commit 2 pick bdcd3db Add new feature # Rebase 0462d8f..bdcd3db onto 0462d8f (1 command) # # Commands: # p, pick <commit> = use commit # r, reword <commit> = use commit, but edit the commit message # e, edit <commit> = use commit, but stop for amending # s, squash <commit> = use commit, but meld into previous commit # f, fixup <commit> = like "squash", but discard this commit's log message # x, exec <command> = run command (the rest of the line) using shell # b, break = stop here (continue rebase later with 'git rebase --continue') # d, drop <commit> = remove commit # l, label <label> = label current HEAD with a name # t, reset <label> = reset HEAD to a label # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] # . create a merge commit using the original merge commit's # . message (or the oneline, if no original merge commit was # . specified). Use -c <commit> to reword the commit message. # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. #
If you are new to vim, you can go to the duplicate commit line and press
“Squashing” keeps the work on a commit but adds the changes to the commit before it. If you want to squash the
fixup! Old commit 2 commit to the
Old commit 2 commit, you can put your cursor over
squash in the comments and type
yiw, then put it over to the
pick before the
fixup! Old commit 2 commit and replace it by typing
# VIM Definition yiw = yank inner word (inner = the word your cursor is on) viwp = visual + inner word + paste
pick turns into
squash as seen here:
pick 7cb4839 Old commit 1 pick 79bd7a2 Old commit 2 squash fcaf152 fixup! Old commit 2 pick bdcd3db Add new feature
When you are satisfied with the changes, press
esc to make sure you are out of any mode and enter
:wq to save and continue rebasing. If there are merge conflicts, resolve them, and then use
git rebase --continue to finish the rebase. Once you see the following message, you can now push the commits to your remote.
Successfully rebased and updated refs/heads/<your-feature-branch>.
With these Git commands, your commit history will look clean and clear while working in a team.
If you want to learn even more git skills, consider reaching out! At DojoFive, we have talented engineers on hand ready to help you with all aspects of your EmbedOps journey. We are always happy to help with interesting problems that need solving. You can reach out at any time on LinkedIn or through email!