Tool support for your strategy

Consider the GitOps strategy from the previous issue. Imagine that you wanted to implement tool support for you team mates by developing a small CLI (Command Line Interface) that could give you access to sub-commands such as

work-on <issue>

  Create a development branch off of main, named like the title of the issue, 
  prefixed with the issue number.

  issue: Integer, the issue number you want to work on

wrap-up 

  Commit anything dirty (git add -A) to the current development branch 
  and constructs a commit message that consists of the title of the 
  issue and a reference to the issue number.

deliver

  Rebase from main, add (or update) the commit message to include the 
  keyword "close" and a mention of the issue number, adda tag "READY" 
  to the commit and pushe buth the branch and the tag to origin.

Three relative small extensions , but imaging if I had theses set up, then I could simply instruct any new-comer to the party to contibute like this:

Example:

Say you have an issue no. 3 with title "Setup Python environment on startup"

You run git work-on 3 and you will get a branch named 3-setup-python-environment-on-startup. you start fixing you problem there and commit as main time as you want. When you belive you are don you rin git wrapup and the branch is now ready for delivery. Så you run git deliver and in a few seconds the GitHub action will care of the rest. If you work is validated you commit will end up on main where it will automatically be deployed to stage.

Would something like this be useful?

Add a few notes to the issue on wether or not you would find three small helper commands like these useful.

How to go about it

I can imagine three rater obvious technologies or approaches you could use to implement something like this:

How would you argue using one or the other, or maybe a completely different approach?

Give it a shot

You don't have to implement all three but choose at least one of them and use the approach you argued for. And then create that as an example - commit the code here - or in another repo, but if you put it somewhere else, make sure it's Public, så vi can see it.

I believe it might be an advantage to use git extensions + aliases as the gh extension is installed locally and scoped to the user which might make it difficult to retain the information about who committed what. By using a script we can call the already installed gh CLI to retrieve information about the issue. Below is an example of how we could write a script for the work-on sub-command:

#!/usr/bin/env bash

# Check if an issue number is provided
if [ -z "$1" ]; then
  echo "Usage: gh work-on <issue>"
  exit 1
fi

ISSUE_NUMBER=$1

# Fetch issue details from GitHub
ISSUE=$(gh issue view $ISSUE_NUMBER --json title -q .title)

if [ -z "$ISSUE" ]; then
  echo "Issue #$ISSUE_NUMBER not found."
  exit 1
fi

# Create a branch name based on the issue number and title
BRANCH_NAME="${ISSUE_NUMBER}-$(echo $ISSUE | tr ' ' '-' | tr '[:upper:]' '[:lower:]' | tr -cd '[:alnum:]-')"

# Checkout to the main branch and pull the latest changes
git checkout main
git pull origin main

# Create and checkout the new branch
git checkout -b $BRANCH_NAME

echo "Switched to a new branch '$BRANCH_NAME'"

ttc-cases / pydevx-lindjacob