Jira cherry-picker galore?

gistfile1.txt

#!/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

+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.