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
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
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
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
STAGE YOUR CHANGES NEXT TO OTHER WORKING BRANCHES
PULL REQUESTS