-
-
Save joshcom/4349831 to your computer and use it in GitHub Desktop.
#!/bin/sh | |
JIRA_ISSUE=$1 | |
BRANCH=$2 | |
if [ "$BRANCH" = "" ]; then | |
BRANCH="master" | |
fi | |
echo "Commits in branch $BRANCH for issue #$JIRA_ISSUE" | |
echo "------------------------------------------------" | |
echo "" | |
git log --grep="^$JIRA_ISSUE " --reverse $BRANCH | |
echo "------------------------------------------------" | |
echo "Would you like to cherry-pick the above commits " | |
echo "into your current branch? (yes/no) " | |
read YESNO | |
if [ "$YESNO" = "yes" ]; then | |
echo "" | |
echo "" | |
echo "" | |
COMMIT_LIST=`git rev-list --grep="^$JIRA_ISSUE " --reverse $BRANCH` | |
### | |
# Replay commits one by one, rather than piping full list to git-cherry-pick, | |
# making merge conflicts slightly less confusing. | |
### | |
for commit in $COMMIT_LIST; do | |
echo "$commit" | |
done | |
else | |
echo "Aborting..." | |
fi |
This sounds pretty solid, as you described.
One rant I'll drop in here: we pick too many cherries. We've developed a cherry-pick always, merge never mentality when transferring changes from master to production. As pointed in numerous references, cherry-picking breaks tracking commits by duplicating the history of that change, which makes it harder and harder to merge branches back together. The problem, as it was in surround, commiting a patch across branches (which is all a cherry-pick is) is always far easier than merging.
I don't know what the best fix is yet. I proposed to the API team of going to a pull request model of tracking and integrating features. I'd love to hear proposals.
Regardless, this is a fine tool for making the cherry picks we do need to make much easier.
+1 Cal, +1 Wade.
I agree with the pull request/merge idea. I've mentioned that a couple times to the web dev team as well. It would also help out for getting another set of eyes on things as well.
If webdev followed this, it would go something like:
- Constrain each feature to it's own branch
- Merge into master for dev/alpha testing
- Merge into production branch for websrc testing
- Install live from the same branch that websrc was tested on (in webdev's case production). That way when testing we at least know that websrc and live use identical codebases.
Using one branch for websrc/prod would still require something like the deploy dog though (granted that's another discussion entirely). This would at least avoid the cherry-picks on bigger change sets, but you could still use the cherry-pick method for smaller changes like bugs.
Honestly, I think our team at least needs to get better about using feature branches more often regardless.
Revisiting this... as I'm going through another massive cherry pick from master to prod. What do you guys think of this general algorithm I wrote up:
Algorithm for perfect JIRA issue cherry picker
Retrive the commit list with a variety of grep regex to help
pattern match lazy typers: /\s*CUR-1234/i /^1234/ == CUR project
Attempt to detect missing JIRA text in a diff. If a commit in
the middle of the jira commits does not contain any issue tag,
print out the commit description and ask the user:
"Is this yours? Did you forget to write in the JIRA issue?"
Check the file list in the jira diffs
Check through each file in prod, looking to see if the earliest
commit in this jira issue is later than the latest commit in
each file. (IE: are we attempting to skip a commit in prod
that will result in an auto-resolve conflict
show the skipped commits, and then ask the user if they want
to cherry pick those first
show the commits and short description in chrono order for
the jira issue
ask the user if they want to cherry pick this list
cherry pick each individual commit, printing out each one
freaking out over whitespace inconsistencies
if one fails, ask if: