Life-Saving Git Tips

Merge with Style

Merging branches and handling pull requests can be time-consuming. If git diff isn’t quite enough, you can use git mergetool to bring up an editor that will help you sort changes. There are also merge GUIs like Meld that can help you breeze past the inevitable merge conflict.

A relatively basic fix that many developers overlook is the use of git merge --no-ff. If you use the following alias, Git will maintain a history of merging in branches so that you can look back and see past merges.

alias merge = merge --no-ff

Cherry-pick prior commits

Sometimes, you need to pull in changes to a branch without merging all the commits before and after it. For example, someone made a bug-fix several commits ago that you want to merge. How can you merge only one commit while ignoring the rest?

The answer is git cherry-pick. Cherry-picking can ensure that you only merge clean commits into your central repository, and there are only a few steps necessary:

1. Create a new branch off of your master branch.
2. Find the commit hash (the alphanumeric id for the commit) of the commit that you want to merge in by entering the git log command.

1. Use git cherry-pick followed by the commit hash.

To cherry-pick a range of commits, use the following syntax:

git cherry-pick f1b62817d9^..98d2bba6d0

This stages commits f1b62817d9 through 98d2bba6d0. The ^ indicates that the first commit is included. Otherwise, only the commits after the first one will be included.

Completing Pull Requests Locally Using Bitbucket

You’ll sometimes want to pull down a fork locally before merging with your central repository. This allows you to test thoroughly in a local branch without the chance of contaminating your code in production.

Note that this tutorial covers the use of Bitbucket. If you’re using Github, there is a slightly different method that is already well-documented.

We’ll use a pretend repository for this tutorial: the ‘cuttle-repo’ from Cuttlesoft that has been forked by user emilyemorehouse. When following along, you can swap out the URL of the repository with your own.

Since we use Bitbucket, the URL of the base repository is:
https://bitbucket.org/cuttlesoft/cuttle-repo and the forked repository is https://bitbucket.org/emilyemorehouse/cuttle-repo.

A few key pieces of information:

• Pull requests will merge in the entire branch (making branch standards VERY important)
• New commits to a branch with an existing open pull request will also be included
• If accepted, a new pull request on the same branch will pull in all commits from that branch, not just existing ones

Now for a step-by-step guide:

git fetch git@bitbucket.org:emilyemorehouse/cuttle-repo.git feature/new-thing

git fetch https://bitbucket.org/emilyemorehouse/cuttle-repo feature/new-thing

git checkout master
git merge --squash PR/new-thing

git commit
git push

git checkout master
git merge --squash FETCH_HEAD

git commit
git push

Make changes to a pull request before merging

Sometimes you need to quick-fix a pull request before merging. It could be a new bug, an API key accidentally committed, or incomplete documentation. Either way, you can make fixes before merging to keep your repository clean.

git fetch git@bitbucket.org:emilyemorehouse/cuttle-repo.git feature/new-thing

git fetch https://bitbucket.org/emilyemorehouse/cuttle-repo feature/new-thing

git checkout FETCH_HEAD

git commit -m "[#XXXXXX] fixed the thing"<br>[detached HEAD 8bb13a2] [#XXXXXX] fixed the thing<br>1 file changed, 1 insertion(+)

git checkout master
git merge 8bb13a2
git push

Branching-Off

There are several different branching strategies that teams can employ.

• Release Branching keeps each release inside it’s own branch.
• Feature Branching keeps work for a single feature inside a single branch
• Task Branching is even more specific, and involves creating a new branch for every task, usually tied to a project management software like Jira or Pivotal Tracker.

In practice, most teams use a mix of these strategies, but either way, it’s important that everyone on your team is on the same page as far as what should be done in a branch. Generally, any experimental work, new features, or unstable code should be kept in a branch.

If you forgot to checkout a new branch before getting to work, you can use git checkout -b to create a new branch and check it out immediately without losing work.

Commit Constantly

Making frequent, focused commits is one of the most important things you can do to keep your repository in good shape. One logical code change should equal one commit. That way, bugs and merge conflicts are easier to find. Lumping a bunch of changes in a single commit is a great way to get yourself in hot water.

Also, you should always use git diff before committing to make sure you aren’t including any changes by accident, (a diff GUI like diff-so-fancy can help you see changes in greater detail).

Keep Messages On Point

Commit messages make your changes easier to navigate. Make sure that your commit messages indicate what parts of the code were changed, and why.

If you make a mistake in a commit message, use git commit --amend to open up your editor to correct it. Be sure to never amend a commit that has already been pushed up to a shared repository, though.

Fix Mistakes

If you get off-track while using Git, always correct course before pushing or merging with others.

Add Patch Mode

Did you dump too many changes into a single commit? Fear not. You can use “add patch mode” to select chunks of code for their own commits. Enter git add -p to sift through your changes and pick out individual lines for commits. Watch this video tutorial for add patch mode if you need help.

Stash

To switch tasks without committing (maybe to fix an urgent bug), you can use git stash to “stash” a snapshot of your files. You can then switch to another branch, make a commit, switch back, and use git stash apply to return your files to the “stashed” state.

Bisect

If you’re encountering a tricky bug and can’t identify the specific commit which caused it, you can use git bisect to pinpoint that guilty commit. We’d describe it here, but The Practical Dev already has a great tutorial that we will refer you to.

Aliases for Better Commits

# Command
git amend

# Alias 
amend = commit --amend -C HEAD

# Command
$ git addmend

# Alias
addmend = "!f() { git add --all && git amend; }; f"

# Note: uses amend alias

# Command
$ git diffs

# Alias
diffs = diff --staged

Aliases for Reviewing

# Command
$ git hist

# Alias
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short

# Command
$ git yesterday

# Alias
yesterday = "!f() { git --no-pager hist --since=yesterday.midnight --until=today.midnight; }; f"

# Command
$ git today

# Alias
today = "!f() { git --no-pager hist --since=today.midnight; }; f"
# Note: uses hist alias

# Command
$ git latest

# Alias
latest = diff HEAD~1 HEAD

# Command
$ git distance origin
$ git distance upstream master

# Alias
distance = "!f() { git --no-pager log --oneline --graph --first-parent --left-right --no-decorate HEAD...$1/${2:-$(git rev-parse --abbrev-ref HEAD)}; }; f"

# Command
$ git compare branch1 branch2

# Alias
compare = "!f() { git log --oneline --graph --first-parent --left-right --decorate $1...$2; }; f"