Life-Saving Git Tips

Does this sound familiar?

It's 5:30 pm on a Friday, and you're glued to the screen. Your team has about a dozen pull requests to deal with, and the client is expecting a demo on Monday. Despite your best efforts, there's still a ton of work to finish. How did this happen?

If you find yourself in this situation over and over again, you might not be using version management to the fullest. For developers with more passion than time, these tips, tricks, and aliases can act as a life preserver when you're drowning in code.

Too busy to read? We understand. Go straight to the TL;DR section, complete with a list of all aliases mentioned.

For Repository Managers

Painless Pull Requests

If you're the one managing a team's central repository, you know how important it is to keep it production-ready. These strategies can help keep your central repository clean and lighten the load when merging pull requests.

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

{
  "name": "core/html",
  "attributes": [],
  "innerBlocks": []
}

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.

3. 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.

{
  "name": "core/html",
  "attributes": [],
  "innerBlocks": []
}

{
  "name": "core/shortcode",
  "attributes": [],
  "innerBlocks": []
}

# amend amend = commit --amend -C HEAD # addmend # Note: uses "amend" alias addmend = "!f() { git add --all && git amend; }; f" # diffs diffs = diff --staged # hist hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short # yesterday # Note: uses "hist" alias to format output yesterday = hist --since=yesterday.midnight --until=today.midnight # today # Note: uses "hist" alias to format output today = hist --since=today.midnight # latest latest = diff HEAD~1 HEAD # distance distance = "!f() { git --no-pager log --oneline --graph --first-parent --left-right --no-decorate HEAD...$1/${2:-$(git rev-parse --abbrev-ref HEAD)}; }; f" # compare compare = "!f() { git log --oneline --graph --first-parent --left-right --decorate $1...$2; }; f" # merge merge = merge --no-ff

You don't necessarily need to use all of these to use Git effectively. More important than any one tip or trick is good communication between team members. If everyone is on the same page as far as when to branch, when to commit, and how to make pull requests, you'll (hopefully) be able to go home on time.

Git can't fix every problem, but the strategies mentioned here can at least make sure that it doesn't cause new ones. If you have questions about Git or any of the topics mentioned earlier, please leave a comment below.

In a source control rut? Feel free to contact us.

{
  "name": "core/freeform",
  "attributes": [],
  "innerBlocks": []
}