@james I dig the talk, just can’t get behind treating the history as mutable. Once code is shared, mucking about with commit IDs causes havoc to understanding what’s going on with the code.
@travis once it’s in master, complete agreed (and I think he says so in the talk).
For collaborative branches, a little work is required sure, but it’s hard to avoid unless you want to save all your merge conflicts to the end and have a bunch of “fix build” commits in there.
@travis For me, the benefits of a super helpful git log and blame workflow vastly outweighs the challenges of coordinating rebasing feature branches.
And over time it encourages us to be more mindful of the commits we create in the first place, making them cleaning and more coherent from the outset.
@james thinking about merges and rebased again? 😊
@james @travis I'm kind of new to the use of rebase in the git flow process but I'm starting to like it now. For larger joint branches I've been saving the rebase for integration down into the main branch with the development happening on a feature or side branch using traditional merges that preserve history.
A Mastodon instance for Rubyists & friends