Git Choosy
2020-02-07
I have been playing around with creating a new Git codebase strategy which I call Git Choosy. It is designed to have the following features:
- Simple: As in it is less complicated than the Git Flow strategy.
- Flexible: Can be used by any Git-managed codebase project.
- Adaptable: Can be used to manage multiple forked codebases that have different agendas.
- Allows for time travel and parallel histories: It's like an unwanted commit never happened! Or... maybe later you decide that commit was fine but another one was the source of the headache. No problem! Let's get choosy and pick what we want!
- Aligns with standard Agile/Scrum and DevOps practices.
I plan to explain the details more thoroughly, but so far in my experiments the strategy works quite well. The basic premise is as such:
- Essentially, at the start of the sprint, the codebase is started from a set commit that serves as a baseline (B) for the rest of the sprint.
- Next, you branch from the baseline to create a sprint branch (S) which will grow/die as needed.
- Afterwards, each feature/bugfix/hotfix are simplified to what I refer to as ticket branches (T) to avoid worrying about the semantics of the differences between a user story vs. bugfix vs. hotfix and such, while still allowing you to categorize them how you want in something like Jira or Taiga. When a ticket branch (T) is ready to be committed, it merges into the current sprint branch (S).
- If all goes well at the end of the sprint, you can just simply merge the sprint branch (S) into the baseline (B), which then this will become the new baseline for the next sprint. Yet, if you decide that a particular ticket branch (T) is unwanted, such as T-123, then you can recreate a new sprint branch (S-2) from the original baseline (B) and rebuild S-2 with everything except T-123. Simple, right? Finally, when the latest, greatest sprint branch is ready, just merge that into the baseline.
