pull-request-lifecycle.md

Pull Request Lifecycle

Create a new branch

If you're not on the master/main branch and you have already made changes, stage and stash them first.

ga .
git stash

Point workspace to master branch.

gco master

Sync up with remote.

gfa
ggl

Create a new branch and point workspace to it.

note: optional, prefix your branches so it's easier to find in a list.

gco -b <name>-branch-name

Unstash your previous changes.

git stash apply

Reset stage and get back to it.

git reset HEAD

Making a commit

Make sure your code adheres to the style guide.

npm run lint

If there are any issues, and the required fixes are minimal, you can usually follow up with:

npm run lint:fix

After lint is satisfied, it's time to finally commit 🎉

ga .
gst
gc -m 'helpful commit message'

NOTE: If you're going to use wildcards when staging a commit, also be in the habit of double checking that everything on stage belongs before committing. You won't regret it.

Push changes to remote.

ggp

Keeping your branch in sync

As pull requests are merged to master, all of the commits are squashed into one. This makes for a tidy timeline of changes. This also makes rebasing significantly easier.

You'll need to sync your branch when:

• Github prohibits you from merging because of a conflict.
• PR is merged to master that includes changes you need.
• Before deploying to staging for stakeholder review.

If you're in the middle of something, stash your changes:

ga .
git stash

With a clean workspace, move to the master branch.

gco master

Then fetch and pull changes.

gfa
ggl

Move back to your working branch.

gco <name>-branch

Finally you can rebase.

grbi --autosquash --autostash origin/master

If you needed to stash, get back to it.

git stash apply

Stage your changes

It's important to keep the staging branch as close to master as possible. Bonus points if that's not a chore.

What's in the staging branch (and hence deployed on the stage server) is most likely a bunch of commits from a past PR that has since been squash+merged to master. That means that master has a slightly different timeline.

Not to worry however, because your current working branch is synced with master. Which is exactly where you want the future of staging to be: ahead of the master timeline!

So let's just replace that old timeline with our branch that also happens to include all of our changes, shall we?

NOTE: If your branch isn't synced with the master branch, please do that before continuing.

Delete local staging branch.

gb -D staging

Then create a new branch from your current working branch.

gco -b staging

Finally, force push to Github.

ggp -f

That's all there is to it!

At this point, the staging branch is now a replica of your working branch (master + your commits). Just be sure to remember which branch you are currently on. If any further changes need to be made, you will need to move back to your working branch. In those instances, you may choose to repeat these steps or you can use merge:

gco <name>-branch
... make your changes
ga .
gc -m 'meaningful commit'
ggp
gco staging
git merge <name>-name
ggp

COMING SOON

STAGE YOUR CHANGES NEXT TO OTHER WORKING BRANCHES

PULL REQUESTS