Git workflow for related changesets

Question

I am working on two very closely related changesets, where the first change introduces a certain functionality - let's call it a library changeset - and a second one uses it - we'll call it feature changeset.

Due to the development workflow, it is preferable for those two changesets to be shown in origin/master git branch as two independent and complete commits - library commit and feature commit. I can do whatever I want in the private branches or local master. Also, obviously origin/master branch does not allow rewriting history.

The way code works, library changeset and feature changeset never touch the same files, but they live in the same repo, so although there is no possibility of conflict between the two, they share the same history and commit sequence.

I also do not have to push my changes to origin until I am fully comfortable with both of them.

In the ideal world, I would first complete and commit the libary change, push it to origin/master, and than work on the *feature, test and push. However, it is possible that during feature development certain problems with library implementations would require revisiting the library changeset. And, see above - it would be preferred NOT to make another commit for library, but instead, modify original commit. git commit --amend would be possible only if I didn't commit feature changes, and also would be awkward in presence of feature changes, unrelated to library.

Here is the workflow I am using now, but is it the best workflow possible? Seems there should be a cleaner way...

1. Fork library branch from master, work on it until satisfied, committing as often as needed
2. Once satisfied with library, squash all commits into single changeset commit
3. Fork feature branch from library, work on library, commit as neccessary
4. If change in library code required:
   • On the feature branch, git reset to the library changeset commit
   • git stash
   • git checkout library branch
   • make changes, git commit --amend on the library branch
   • Delete original feature branch
   • Fork new feature branch from library
   • git stash pop in the new branch
   • repeat step 4 as needed

The sequence above seems to work, but I feel it is error prone and somewhat clumsy.

Is there a better way of achieving my goal?

Answer 1

This is one of those cases where the best development workflow isn't a good match for the best presentation sequence: you're working on interrelated changes, the interrelations should be disentangled and organized for presentation, but that doesn't bear much relation to how their development works. This

I also do not have to push my changes to origin until I am fully comfortable with both of them.

is the payload quote. Pushing is publishing, you're constructing a work for publication. Your first-draft notes are messy and partial and out of sequence, that's normal. Do your first-draft work in whatever sequence and structure makes sense to you, then use interactive rebase and cherry-pick to construct your for-publication commit series.

For the outright exploratory work, just do it all on a single branch, reorganize the hunks for your own benefit as needed with the rebase-and-pick method into private I-think-this-is-{library,feature}-code branches. See here for a longer discussion on how to use rebase and cherrypick for this, it's pretty straightforward.