git on CodeGoalie

One-liner to copy a Github PR link from the terminal

Wed, 04 Jan 2023 14:35:12 -0500

Here’s a super quick one-liner to copy the current branch’s PR URL to your clipboard (for posting into Slack, tickets, etc.)

$ gh pr view --json url --jq .url | <pbcopy | xclip -sel c>

Remember to replace the copy command with your platform’s specific command.

This would also make a good shell alias.

Also, also, I might try setting up Clipboard for multi-platform goodness.

Happy PR-ing!

– Chris

Commit Before Code

Fri, 26 Jun 2020 06:43:29 -0400

I propose a case for writing all of your commit messages for a feature, bug, pull request before writing a single line of code and afterward not adding any additional commits to your branch. Plan and execute. Give clarity and focus to your reviewers. Here’s how.

This is an idea that’s been floating around in my head for a while now: pre-planning commits in your branches. In fact, I checked my older posts because I thought there might be a pretty good chance I had written this post already. There wasn’t. So, here it is.

What am I talking about?

Making all your commits to complete your task before you begin coding. Literally using --allow-empty to outline all the tasks your branch needs to do before you write one line of code. Every commit after that of code changes are all fixup commits to one of the original commits. No new commits allowed.

Why would anyone do that?

I find the exercise of planning my attack in the form of concrete commits beneficial for clarity and focus.

First, I can think abstractly about the work to be done. I don’t know which lines of code will change or even what they will change into, but rather, I can focus solely on what those changes need to achieve.

I can think at a much higher level and coordinate the expected changes together without getting bogged down by the intricacies or specific implementation details. I don’t need to think about error handling, variable naming, design patterns, code smells, testability, etc. (unless any of those are core to the rationale of the branch). It’s almost a pure-er way of processing the task at hand. I focus only on what are the smallest set of steps to reach the goal.

Secondly, and often more importantly, I force myself to remain focused on the task at hand. If I make a change that doesn’t fit into any of the predetermined commits, there’s a very good chance that the change doesn’t belong in this branch and should be made elsewhere.

Most often these are housekeeping tasks; small improvements to the code that I happen to notice while doing something unrelated. Sometimes these are areas that don’t adhere to newly adopted best practices. Or, improvements in readability. These aren’t things that are critical, but help keep code quality up over time. I’ll get into what to do with these kinds of changes later.

Ok, but how can I do this?

Let’s take an example and build out our branch of empty commits. Imagine we’re working on an app to track vacations. We have an entity that holds our check-in and check-out dates. What we want now is to display the number of days and nights of the stay. For example, a stay from July 14th to 20th is 7 days/6 nights.

One thing to notice about this new feature is that the numbers are always one off from each other. We can calculate one and then derive the other.

I like to write my tests first (in one commit) and then get them to pass in another. I’ll also prefix my test-only commits with “Ensure”. Using this pattern, I’d want to write test for and then implement the number of days calculation. Then test and implement displaying to users. Here’s the commands to acheive this:

$ git commit --allow-empty -m "Ensure amount of days can be calculated from trips"
$ git commit --allow-empty -m "Calculate amount of days from trips"
$ git commit --allow-empty -m "Ensure users can see days/nights for a trip"
$ git commit --allow-empty -m "Display days/nights for trips"

Then after writing the tests for the calculation, I would create a fixup commit to autosquash into the first commit from above:

$ git commit --fixup HEAD~~~ # using a relative commit reference
# or with the sha1 (prefix)
$ git commit --fixup 06aa143

Learn more about git references.

When all is said and done (or even before that), you can have git clean things up for you with:

$ git rebase master --autosquash

What about those small, unrelated changes?

These are changes I, personally, love to make. I believe this is where the rubber meets the road in software as a craft. The holy trail of the huge rewrite is often so tempting, but if you can’t put new learnings or best practices into existing code then how can you think that you’ll be able to do it in a brand new system. If you can prove that you are a good enough developer to make the existing system its best, then you know you are ready to tackle a rewrite. However, you also won’t need to. ;)

So, what could be the harm of slipping in some minor improvements with your other work? I’m already in here. Let’s just fix it really quick. Well, this will get you into trouble in at least 2 ways.

First, if the rest of your branch becomes obsolete or a better solution arrives before you merge, the codebase doesn’t get to benefit from your unmerged, unrelated change. Or worse still, if your merged branch needs to be reverted, you will also be reverting your unrelated change.

Secondly, it has a very real chance to hold up your PR during review. There’s no better way to almost guarantee a flame war than think you can squeeze in a small, quick change. “Why is this fix here?” “If you’re fixing this, why didn’t you fix that?” “You should fix it in this way instead.”, etc. Your 2 second “improvement” will undoubedly attract comments and suggestions like moths to a flame. The actual point of the PR will be fine, but you’ll get stuck going around and around on your small addiiton.

If you can’t make these changes in your current branch, where do they go?

TL;DR Move them into another branch and open a separate PR.

There are 2 ways to do this. One uses the stash and one uses commits and cherry picking. I’ll start with stash.

Use the git-stash to move changes across branches. The stash is a temporary holding place for uncommitted changes. You can stash these changes on one branch and apply them to another. I’ll assume you’ve committed all changes with fixups and want to move all uncommitted changes to another branch.

$ git stash save
$ git checkout master
$ git checkout -b a-good-name-for-changes
$ git stash pop
$ git add .
$ git commit
$ git push

I always prefer git stash pop to git stash apply because the former removes the stash entry when applying it and keeps your stash clean. Once it’s applied and committed, you no longer need that stash and there’s no sense in keeping it around.

Now, for the second way. This way is a little less dangerous since you always have your changes committed, but maybe only by a hair. Here you’ll commit to your working branch. Then create a new branch and cherry pick that commit into the new branch. This technique also works will if your “small” fix has multiple commits.

$ git commit
[commit-before-code e4fe22f] Prefer single quoted strings
1 file changed, 3 insertions(+), 3 deletions(-)
$ git checkout master
$ git checkout -b string-style-fixes
$ git cherry-pick e4fe22f
$ git push

ProTip: cherry-pick takes any git commit reference. Utilize the branch name to cherry pick the tip of that branch into your current branch.

The really cool thing about this method is that if your fix branch gets merged before your feature branch, you can simply rebase on master (which you should be doing anyway) and git will detect the duplicate changes and automatically remove the cherry picked commit.

Next time you are starting to work on a new branch, give this method a try and see if it helps keep you clear on your objective and focused on nailing it.

Let me know how it works out for you.

Happy committing!

— Chris

Git References

Wed, 06 Apr 2016 23:04:17 -0400

Everyone knows how to checkout a branch, git checkout master, or how to look at a specific commit, git show a1c8b6d. But few know that branches, tags, and commit SHAs are typically interchangeable in these and many other git commands. Plus there is a whole set of modifiers to reference commits near to specific commits. In this post, we’ll explore all these techniques to become expert git referencers.

References

Below we will explore the different ways we can express a commit in git. While each technique has its own strengths and weaknesses, being able to wield a lot of git’s power and saving a lot of time comes from using these references interchangeably.

SHA1s

This first and most recognizable way to reference a commit is by its SHA1. This is the full or part of the long random looking string of letters and numbers. These are generated based on the contents of the commit, including current state of the repo’s files, commit message, author and committer, and timestamp. If any of those items change, a new SHA1 will be generated. Here are some examples of git commands using the SHA1.

git show abc123
git cherry-pick 321bca
git reset bbbaa4

Branch Names

Branch names are also something that are a big part of a git workflow. Under the hood, branch names are just aliases for commit SHA1s. Literally, you can see the branch names in the .git/refs/heads directory of your repo. Each file there contains one line which has the SHA1 of the commit it references. Here are some common usages of branch names:

git checkout master
git rebase stable
git merge features/new-hottness
git cherry-pick bugs/broken-email-form

An important aspect of branch names is the commit they reference can change. For example, when you create a new commit the branch which you are currently on automatically gets updated to the new SHA1.

HEAD

The HEAD commit is the current tip of the branch you are on. Similar to the pwd program, HEAD tells you where you are. On its own, the useful command is show which will show you the details of the last commit you made.

Modifiers

git also allows you to specify commits by their relation to other commits. In the git data structure the only explicit relationship between commits is child-parent. That is, the child commit knows its parent, but the parent does not know its child/children. Many of the commands which show or span multiple commits, such as log or diff, actually traverse the git tree to aggregate their output.

First Parent

The ~ modifier follows a references first parent. For example, HEAD~ references the first parent of the current commit. The first parent modifier can be repeated: HEAD~~ references the first parent of the first parent of the current commit. Also, a number can be specified for many generations: HEAD~5 follows ancestors back 5 generations. Here are some other uses of the first parent modifier:

// Move the second to last commit into the current branch
git cherry-pick bugs/broken-email-form~
// Modify some of the last 5 commits on your branch
git rebase HEAD~6
// Mark your current changes to fixup into two commits ago
git commit -a --fixup HEAD~

Other Parents

Through merges, a commit can have multiple parents. The last modifier of the day specifies any parent of a commit. The caret, ^, modifies the reference to follow its first parent; the same as ‘~’. However, specifying a number along with the caret follows subsequent parent commits. For example, reference the last commit of a branch before it was merged into the current branch with HEAD^2.

Bringing it all together

Any of the above references can be combined with any number of modifiers to express the exact commit succinctly. Here are some examples:

// See the 3rd to last commit from the last branch merged to the stable branch
git show stable^2~~~
// Pull second to last commit from version 2 into your current branch
git cherry-pick v2.0.0~
// Create a new branch 2 commits back from a known SHA1
git checkout -b branch-from-history abcd122~~

The above examples might seem extremely specific, but knowing and using these techniques can turn wasted time digging through git logs or copy and pasting SHA1s into a quick one-liner. Impress your friends and co-workers, save your own time, and begin thinking of your git history relatively.

Happy referencing!!

– Chris

Delete multiple branches with git

Wed, 25 Jun 2014 00:00:00 +0000

When working on projects with multiple developers following a feature branching workflow, you can end up with a lot of branch laying around. I’ve been trying to optimize my branch cleanup workflow for a while now and had a big breakthrough recently.

UPDATE: I now use a shell script which has the meat of the git-sweep functionality. Thanks to @pengwynn for letting me steal that.

Before we get to that, I must mention git-sweep. It has been revolutionary to keeping branches (both locally and remote) clean. If you care at all about the output of git branch, install that now.

However, there’s another simpler trick I just recently discovered. Deleting multiple local branches with one command.

$ git branch -D old-branch-1 old-branch-2

That’s it! Simply pass as many branches into branch -D as you want and git will gladly delete them all.

But why do you need this?

I just said that git-sweep cleans up local and remote branches after they are merged into master. So, why would we ever need to delete local branches? For one, you might not merge branches into master, but still want to delete them. But more likely, you’ll need to do this after pulling down a colleague’s branch to review. Once you give them the green light, it’s best practice for them to rebase onto master (interactively to prevent accidentally merging !fixup commits). However, you will have one state of the branch locally, but they’ve merged a different, rebased state. This is just enough of a change to fool git-sweep, and git herself, into missing the fact that these branches are the same. Luckily, there is a quick way to identify and remove those branches too.

Handily, git-branch has a super verbose mode which can be shown with the “double v” flag (-vv). This displays the branch name, HEAD commit, remote tracking branch, and HEAD commit message.

$ git branch -vv
* gh-pages 123456 [origin/gh-pages] Show new features on the project website
master 654321 [origin/master] Merge features/super-new-feature into master

Additionally, super verbose mode will also show us when a remote tracking branch disappears (is deleted). Immediately following the tracking branch name, we’ll notice a “gone”.

$ git branch -vv
* master 654321 [origin/master] Merge features/super-new-feature into master
old-feature 523621 [origin/old-feature: gone] Users can see the brand new feature

I like to grep for that and filter out the branches which I don’t want to delete. Basically, my whole cleanup procedure goes like this:

$ git branch -vv | grep gone]
old-feature-1 523621 [origin/old-feature-1: gone] Link to the new account page
old-feature-2 856956 [origin/old-feature-2: gone] Toggle turtle visibility with feature flag
$ git branch -D old-feature-1 old-feature-2
Deleted branch old-feature-1 (was 523621).
Deleted branch old-feature-2 (was 856956).

And there you have it, removing multiple branches in git with a bonus of finding branches who’ve lost their remote tracks.

Happy branching!!

– Chris

Commit Message Starters

Tue, 14 May 2013 00:00:00 +0000

As I’ve been working in git and crafting my commits with rebase working toward creating pull requests which are easy to read, review, and comment, I’ve been noticing myself fall into habits of naming commit messages similarly which contain code to acheive similar ends. Further, when I struggle to find the correct words for a commit message, it’s often easier to being with a familiar word to get things flowing.

{% img right /images/readthesource.jpg 460 276 Read the source %} Over the past few months, I’ve also had the pleasure of working with some great developers. As such, I’ve been afforded the opportunity to review a lot of their code. If there is one thing I recommend to all developers, from novice to expert, it’s read code. Your own, your friend’s, strangers, projects you admire, anything you can get your hands on. Not only will it enlighten you to how others write code, new coding patterns and syntax, but it will empower you to be able to figure out how the code you use works and how to fix it.

As a quick aside, I was able recently to dig into the Ruby source code, even into the C, to discover exaclty what was happening with Range bracket operator access on an empty Array. It felt great to be able to see how Ruby herself was implemented and know exactly why my code worked; to go beyond “well, it worked in irb so it must be correct.”

The great thing about reviewing pull requests is that I am able to open discussions with the authors and inquire as to why they made certain decisions and what their motiviations were for writing certain code. Also, it gave me a chance to see code which was not polished and final. Thereby, recognizing anti-patterns and less than best practices.

Coming back to the topic of this post. These anti-patterns and less than best- practices extend to commit messages as well. Below I’ve listed some of the dos and don’ts which I have started to use in my everyday committing.

What I like

These words I often use to start commit messages which make some common changes in the codebase.

Ensure

Ensure phone numbers strip extraneous characters
Ensure deactivation resets users' api tokens

I use “Ensure” to start a commit which contains tests for my code. These commits are often the first commits in a pull request, especially if I am using TDD. A whole commit just for test? Surely, that’s overkill? There are two reasons I like to encapsulate tests into their own commits.

{% img left /images/ensure.jpg Ensure %} First, this standardization allows others to know which commits will define and test the behavior I aim to implement. We all know that tests can be a great documentation tool and prefixing commit messages which contain “Ensure” allow people to find them easier.

Second, if the tests are in their own commit(s) before the implementation commits, it’s very easy for a reviewer to simulate the red-green test cycle. Either through a checkout or selecting a commit to be ‘editied’ in an interactive rebase, the state of the repo after the tests are written, but before the task is implemented can be recreated. Tests are run at that point and a reviewer can cofirm that the new tests do indeed fail. The rebase is continued and the tests can be run again. This time they succeed. A review has very simply been able to confirm that the tests are working correctly.

Boyscout

Boyscout the user model specs
Boyscout line lengths in the sessions controller

Boyscouting refers to updating the format and/or style of code without changing the behavior. I picked it up from a presentation about code styles which I now cannot find to reference here. However, I did find this written reference online. The term refers to a famous quote by the founder of the Boyscouts, Robert Stephenson Smyth Baden-Powell, “Try and leave this world a little better than you found it”.

Continuing to think of the reviewer when committing, just by looking at the message, expectations are set that this commit does not change functionality, only formatting. Review of a change like that is much easier when you know that nothing is supposed to happen.

Migrate

Migrate a unique index for user email addresses
Migrate timestamp columns onto the comments table

As you might have guessed, I use “Migrate” to start commit messages which contain migrations. As a best practice, we like to isolate migrations to their own commits containing only the migration class definition and the changes to the schema file. It also can be useful, but not 100% reliable, to quickly see if a particular set of commits has migrations; say before a deploy or after pulling down the latest changes. Again, along the theme of setting expectations for others.

What I avoid

These words often start a commit message off on the wrong foot. Being very generic on their own, they often lead to very generic commit messages.

Fixed

Fixed broken specs
Fixed editing a user

{% img right /images/fixedit.jpg FIXED!!! %} First off, past tense should be avoided in commit messages. The rule of thumb is to write a commit message as if you were commanding the code to take an action. Secondly, commit messages should describe the reason for a change, not the change itself. If someone would like a know what the changes were, they need to do no more that a git show or click in github. However, to reason why the change was made or what it is attempting to do is much harder to determine from the code itself. Great commit messages can be the difference between Fixed broken specs and Activate users after registration in user specs.

Added

Added new Order model
Added full_name method to User model

“Added” is not strictly a not so best practice, but I see it go awry more often than I see it used for good. Again, “added” has a great tendnecy to lean toward what happened instead of why did it happen. I, myself, sometimes write a commit starting with “added”. For example, Added jquery javascript library at first glance seems perfectly reasonable. I didn’t fix anything. I didn’t write a great new feature. I just added jQuery. However, when I find myself with a commit message like this, I go through the practice of adding “in order to” and then trying to finish the commit message. Added jquery javascript library in order to provide DOM manipulation methods. Put it together for Provide DOM manipulation methods with jQuery. Now, I’ve given some context to why I added jQuery instead of simply restating the code changes in the commit message.

That’s all I have for now. Please comment below with your commit message best practices and tendencies. I bet you guys have some great tips too!

See ya soon and keep committing!

–Chris

Better pull requests with git --autosquash

Thu, 04 Apr 2013 00:00:00 +0000

UPDATE (Jun 7, 2013): I created an ascii.io video demo of autosquash for your viewing pleasure.

Pull requests are an extremly crucial part of our workflow at Mobile Defense. We pride ourselves on producing quality code and we do not subscribe to the git-blame “I didn’t write it” culture. We all take responsibility for all the code we produce, as a team. As such, being able to review our code efficiently and thoroughly before it gets into master is a goal we are constantly looking to improve upon.

A somewhat paradox in reviewing code arises when the need for reviewers to see the updates based on their feedback quickly and efficiently and for the developer to be able to ‘fixup’ their branch before merging to ensure the code enters master as cleanly as possible. That’s where git-rebase comes in.

Rebase is an extremely powerful tool in the git toolbelt. Combine commits, edit commits in-place, rewrite history, etc. It’s especially great for cleaning up your topic branches before submitting for code review. However, remembering which commits need to be squashed into which can be tricky especially when being the reviewee and the reviewer on multiple pull requests daily. Well, it turns out git already has a really clever, built-in way to organize and automate the branch cleanup process. It is perfectly suited for making changes based on pull request feedback. It’s called autosquash.

Here was a typical pull request workflow:

Code up a feature; commit early and often.
Push to github and open a pull request.
Do a quick self-review of my code.
Ask others to review my code.
Add temporary commits in response to comments.
When the branch is approved for merge, rebase and fixup the temporary commits into the original commits.
Merge the branch.

As you might have experienced or noted in the workflow above, how do you keep organized and remember which temporary commits should be squashed into which original commits? The problem I ran into time and time again was that as soon as I started an interactive rebase I would be unable to remember exactly which commits needed to be changed, squashed, or fixedup. So, I had been developing some commit message conventions for temporary commits.

For example, a commit which I knew was incomplete work or needed to be looked at again would have it’s message prefixed with an excalmation mark.

! Possible logic error in the complex_redirect logic

Further, commits which I knew I wanted to squash into previous commits would be prefixed with four hyphens and have a message which I would be able to make sense of when editing the rebase todo file.

---- into the first set of unit tests

This worked fairly well as long as I left myself good notes. But, surely there must be a better way!

Enter autosquash

The --autosquash flag on git-rebase is exactly what I was looking for. During an interactive rebase, it processes messages to stage squashes and fixups. These messages are setup with flags on git-commit at commit time, which is when you are most likely to know what you ultimately intend to do with commits. Further, it works via the commit message so it’s easy for humans to understand as well!

Say you have a feature branch with three commits: (viewing git logs with the incredibly awesome lg alias)

* cdaa049 (HEAD, features/new_hotness) Add new hotness to UI (66 seconds ago) <Chris Marshall>
* e14aa92 Implement new hotness backend (2 minutes ago) <Chris Marshall>
* 293070e Ensure new hotness works (2 minutes ago) <Chris Marshall>
* de72adc (origin/master, origin/HEAD, master) Add git internals meetup talk slides (6 months ago) <Chris Marshall>

Now let’s say you get a review comment on the commit for the tests (‘Ensure …') which asks to add a test for a missed edge case.

So we will code up our edge case fix and as we commit, we’ll add the flag to specify what we ultimately will do with the commit.

Git-commit has two such flags: --fixup and --squash with each of these we will specify the commit into which we want to fixup or squash. In our example, we want to fixup into the first commit after master: 293070e.

We can do that with:

$ git commit --fixup=293070e

Which will produce a commmit with a message of:

fixup! Ensure new hotness works

A commit message formatted this way tells git-rebase (with --autosquash) to fix the patch in this commit up into the commit with the message “Ensure new hotness works”. The power of using the commit message instead of SHA1 to identify commits is that this will work even after a rebase without --autosquash (e.g. pulling in lastest master changes).

Here’s how it would look in github:

Obviously, don’t have conversations with yourself on github. This is purely educational ;)

Now the fun part! When the pull request is approved, you can rebase with autosquash (and interactive) and watch as git does the work for you:

$ git rebase master -i --autosquash

Produces the rebase todo file:

pick 293070e Ensure new hotness works
fixup 3877fdf fixup! Ensure new hotness works
pick e14aa92 Implement new hotness backend
pick cdaa049 Add new hotness to UI

Simply save it and git rebases the branch as if you had changed the file yourself. You can then merge and have a beer for all your efforts!

Automating autosquash

Adding the long --autosquash flag all the time can get tiresome. Luckily, you can add the rebase.autosquash config value to run autosquash automatically for every interactive rebase.

$ git config --global rebase.autosquash true

If no commits with the fixup! or squash! syntax are found, the rebase continues normally. To override the autosquash default value, simply pass the --no-autosquash flag to rebase.

Happy squashing!!

–Chris

Oh my! What large hot fixes you have

Tue, 26 Feb 2013 00:00:00 +0000

We’ve all been there: just finished a nice new feature, deployed it out to production only to find that you’ve completely overlooked an edge case or use case which is now totally breaking your app. Sometimes you have to push a big hot fix. It has to get in immediately. It can’t wait for writing correct tests or other better abstractions and implementations. What to do? What to do?

Well, there’s the common way of hacking as fast as you can until you’re pretty sure the bug is fixed, commit everything in a big “Avert crisis!!” commit. However, I think we can do better.

First step checkout a new branch at your current ‘production,’ or similar. Call it production_pre_fix. Don’t check it out or work on it, just leave it there as a placeholder.

$ git checkout production
$ git branch production_pre_fix

Now for the fun part: hack away! But, follow your usual development practices of committing early and often. Refactor a method. Commit. Add some if checks for edge cases. Commit. Get the shit fixed and deployed. Go on. I’ll wait.

Ok, alarms are quiet now and you’re done breaking shit? Good. Now let’s get to work on the real fix. I’m glad your hacked together bunch of duct tape fix is holding, but let’s not leave things like that. I know you and I bet you’ve got some good work there. You probably don’t want to just throw it all away. That’s cool. Why don’t we use the duct tape as a basis for the permanent fix? Here’s how:

First, get a clean branch off master

$ git checkout master
$ git checkout -b bugs/prod_fix

Then, write tests to account for your new found bugs.

Next, cherry pick your current fix onto this branch.

$ git cherry-pick production_pre_fix..production

You may have noticed I passed two branch names with two periods in between to cherry-pick. What the fuck, right? Well, as we all know, two commit SHA1s separated by two periods is a range of commits. For exmple, 2e45f..34b79. You are saying that you’d like to use all the commits starting at 34b79 and following parent links back until you reach 2e45f.

But I’ve used brach names here, which are just human friendly shortcuts for SHA1s. Remember branch names are basically pointers to a particular commit. They can be used in any git command which would otherwise take a commit SHA1. Add that to the fact that cherry-pick can take a range and suddenly your doing some pretty powerful stuff with a pretty simple command. Go you!

Now a little housekeeping,

Make sure your fix actually passes your tests.
Refactor and make your fix nice. Rebase, as necessary.
Start pull request and get the feature merged back into master.

Then we need to reset your temp fix in production. Like this:

$ git checkout production
$ git reset --hard production_pre_fix
$ git branch -d production_pre_fix
$ git push -f

Woah woah woah! No, I didn’t. I just force pushed a non-topic branch. Isn’t that a big no-no? Usually, yes and I would expect to be taken out back and beaten until I learned my lesson. However, until I’m told of a good reason otherwise: production or other released branches are not shared among developers. They are an exact representation of what is to be deployed next to the environment they represent.

Why aren’t release branches an accurate representation of what is currently deployed to the environment they represent? Because if you want to know that, look at the environment. There’s no need for duplicate information. A branch like production should be curated and hold what will be deployed next to production. You might not do that curating and updating until moments before the deploy. But for all that time until you deploy, if you had to emergency deploy, whatever is in the branch will be deployed.

Back to business, we’ve reset production back to not include the duct tape. Now it’s time to merge master and our fix up to it.

$ git checkout production
$ git merge master

Congratulations! You’ve not only saved your company from sure collapse by fixing a huge production bug. But you’ve also reconciled your technical debt and prevented other developers behind you from cursing your name at the duct tape-y hacks you introduced to the code base. That deserves a beer!

– Chris

Help! I lost a commit from days ago!!!

Fri, 08 Feb 2013 00:00:00 +0000

Oh no! I’m screwed! Better try to remember what work I did and recreate it… :( J/K! This is git! Of course there’s a slick way to recover what you lost. Here’s my situation: I was working on a feature branch happily coding away. Finished the feature, rebased it quickly to fix a typo and then merged it into master. All’s well in my world. However, that was days ago and today I just realized that I accidentally removed one of my commits from the feature branch while I was working on it. No worries. Here’s how I got the commit back with relative ease.

First, let me give you a lay of the land. I use the incredible git lg alias.

lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --

Seriously, steal that now. Use it a thousand times a day. I wish I could attribute it to the original author, but I have since forgotten where I originally saw it. At any rate, every few weeks I see it posted anew on a different site.

Anyway, here’s where I was at before the recovery:

Well…now what? Redo all that work in the lost commit. Nah. Reflog to the rescue! Git’s reflog is a (by default) 90 day record of everywhere your HEAD ref was pointing. Anytime you do a checkout, create branch, commit, rebase; anytime the ‘current’ commit of your working directory changes, the reflog gets a new entry. You can think of the reflog as a record of what you’ve been doing. If you’ve had it in your working directory in the past 30 days, it’s in the reflog.

Remember what the commit message was for my lost commit? Nice! We can easily grep for it:

chrismar035:super_sweet_rails_app(master) $ git reflog | grep "commit message"

What’s that? I didn’t tell you the commit message for the lost commit? Well, I don’t remember either! Now we are screwed.

Gotcha again! We can still find it. We can use the ancient art of looking for what we lost. It’s easy. Simply do a git reflog and you will see a list of everywhere you’ve been:

AHA! Not only did you find the LOST COMMIT!!!, but we can also look at what happened too. Apparently, on a mad dash to get the feature merged before going out and getting my drink on with some chaps, I accidentally rebased my commit right out of the project. Damnit.

Oh well, at least you found it for me. Thanks. Now, we’ve only got one real choice to fix this. We have to cherry-pick the commit out of the reflog back into master. Because I’ve already merged my feature branch into master and pushed it, I cannot go back and rebase or otherwise edit that pushed history of master. I’ve got to bite the bullet and add a commit straight onto master… Everyone screws up once in a while.

In the reflog, there are two ways to reference the commit: the SHA1 and the HEAD@{integer} reference. Either one will work. I like the SHA1 because I can double click in the terminal and it gets correctly highlighted for copying. Copy it and we’ll paste it back into the command line with:

chrismar035:super_sweet_rails_app(master) $ git cherry-pick 9a7de0e

lg that again and see how we look:

Nice! Now, notice that the SHA1 changed from what you copied out of the reflog. Remember, commit SHA1s are based on their content (files, dirs, commit messages and meta data) AND their parent(s). So, if you change the parent of the commit, you change the commit (Same reason all the SHA1s change when you rebase). In reality, the commit you cherry-picked is duplicated on to the branch you cherry-pick it into. However, in our case that’s exactly what we wanted, because I messed up and deleted the commit in the first place.

Nice work! Push and have a beer!! :)

– Chris

git on CodeGoalie

One-liner to copy a Github PR link from the terminal

Commit Before Code

What am I talking about?

Why would anyone do that?

Ok, but how can I do this?

What about those small, unrelated changes?

If you can’t make these changes in your current branch, where do they go?

Git References

References

SHA1s

Branch Names

Tags

HEAD

Modifiers

First Parent

Other Parents

Bringing it all together

Delete multiple branches with git

But why do you need this?

Commit Message Starters

What I like

Ensure

Boyscout

Migrate

What I avoid

Fixed

Added

Better pull requests with git --autosquash

Enter autosquash

Automating autosquash

Oh my! What large hot fixes you have

Help! I lost a commit from days ago!!!