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
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.
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.
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.
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.
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.
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?
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.
Christopher R Marshall