1–10 of 14 posts
1. Do a rebase to get their branch in-sync with main, 2. Squash their branch's commits, 3. Make a push/force push to their branch, and 4. Create a pull request.
Which is lovely, but the process has a gnarly learning curve for our junior devs.
Is anyone familiar with documentation or tooling that does a good job of streamlining this sort of workflow?
https://gitimmersion.com/lab_31.html is likely where you would want to explore. hths!
I really appreciate the efforts for gitimmersion.com. https://gitimmersion.com/lab_31.html is likely where you would want to explore. hths!
I've had success using https://git-rebase.io/ to help people understand the workflow.
function stash_and_rebase() {
local current_branch="$(git_current_branch)"
if (( ${#current_branch} == 0 )); then
echo "There is no current branch. This script must be executed in git repo."
return 1
fi
if (( $# == 0 )); then
local target_branch="$(git_main_branch)"
else
local target_branch="$1"
fi
git stash push
git fetch --all
git rebase origin/${target_branch}
echo "Don't forget to execute 'git stash pop' after rebase!"
}
N.B. This doesn't do squash!
I can't recommend highly enough Learn Git Branching[1], an interactive demo for understanding rebases and cherry-picks.
Then try it a couple of tricky times, and you're settled.
I feel dirty anytime I put '--force' and I encourage workflows that don't mess with history. In every code base I've been in, it is just more straightforward to squash merge smaller, self-contained, commits into your main branch. Tests should act as a gate for committing to the main branch.
That being said, the workflow for this project is unlikely to change. And, to be fair, the workflow has its benefits. The project history is very clean, PR code reviews are straightforward, etc.