I found this workflow about how we can use an integration branch as a base for stacked branches.

Stacked branches with vanilla Git

Instead start the work by creating a feature-integration branch, which will contain all the changes you are working on together. Later, when you better understand the specific changes you are making, you can re-order the commits with git rebase -i to group commits together that you want to slice off as their own reviewable and mergeable branches.

We don’t know the hierarchy first of our work, so we can create an integration branch to mess around with ideas. The good thing is that this doesn’t need to be pushed. I can start working on the branch without too much structure and then organize my work later.

Naming these would be something like this: TICKET-ID/integration

This would be the source branch for the stacked branches so that Tower will show it as the first item in the branch tree in the sidebar.

Just like in typical programming, the commits are in no particular order. As so frequently happens, you only wrap your head around the overall change you want to make after you’ve touched a bunch of different pieces.

What does he mean by “commits are in no particular order”? Maybe I should ask ChatGPT… Here’s what it generated about this:

In a typical programming session, you might start working on one thing, then realize another part of the system needs to be changed, and by the time you’re done, the commits reflect this non-linear process. Only afterward do you gain a clearer understanding of the full scope of the changes you’ve made.

This mirrors the messy, real-world workflow where things evolve organically as you work, rather than being neatly planned out in advance.

This essentially means that we organize our commits after we create a mess. It could be avoided, though, with frequent committing and then squashing related ones later. This would force a commit review workflow on me, which can be helpful in Finding a session wrap-up process so I can wrap up my work more efficiently.

Then we have to somehow create the branches to point at the associated commits. Remember the rule though: never switch off your integration branch. So how are we going to create these branches?

We branch off from commits. Then, these branches are pushed and sent for code review. It is still important that a PR has the proper base, so we have to maintain some form of connection between them.

Or, it can be solved by pushing the integration branch too, and setting that as a base, but then we lose the nice local, private sandbox.

• So the question is, what should we use a base for a PR here?

The beauty of this method is that you are still on the feature-integrationbranch, ready to keep adding new work, while feature-a can go up for review.

In theory, this sounds good, but what about keeping stuff current?

• Can I re-order branches in Tower so one commit gets into a branch automatically?
  • Or do I have to cherry-pick?
• What about editing an existing commit where I do the coding?
  • I don’t see that as a convenient way to integrate commits
• Will the Tower re-stacking workflow work in this case?

I have to review these use cases first in Tower. I don’t care about the command line git for now.