It is not quite as easy or quite as reliable as it with merges, but generally "branches" come in as recognizable chunks of commits, and you can either revert them with a range, or interactively rebase them out of existence, depending on your goals. It's generally not very difficult, but in some cases it may be.
I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing.
I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones.
That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.
- Checkout master.
- Start an interactive rebase of master onto the last
commit before the series of commits you wish to remove.
- Mark all the commits you don't care about as "skip".
- Let the rebase run and resolve conflicts on the way,
the same as you'd do with your current work flow.
This rewrites history, right? What I meant was a feature branch which got merged into master turned out to introduce unwanted behavior, so while a fix is rolled out to the feature branch I'd like to remove that code from master. What I currently do is revert (git revert, which generates a new commit) the merge commit(s) used to bring that feature branch into master, then when the fix on the feature branch is complete I revert the revert I just made and merge the feature branch again.
Exactly. I love this process, and endeavour to drop all dev/develop branches from the repos I'm working in. Sensational headline aside, I've seen a lot less untangling when feature-branching off of master and a judicious use of tags.
While it's dated at this point, I've always felt that the Github flow [1] works best (for the projects I'm involved with anyway).
I'd also suggest that you want to make sure you consider the full totality of costs, because it's very humanly easy to see this one feature that you recall using a lot, when in fact you can easily recall it precisely because it is a rare event (and thus worthy of memory), whereas the costs of a complicated branching structure are continuous and ongoing.
I'm not saying that linear is therefore guaranteed to win for you, just pointing out the cognitive danger of seeing the big, rare expensive costs and missing the continual drip of small ones.
That said, I'm not necessarily 100% linear myself, but I do sometimes feel like git made branches easy and some people overreacted. If you've got a branch that lived for at least, say, a week, and had significant independent work within it, then by all means merge it and keep a merge commit. But this workflow creates branches upon branches upon branches, and then keeps them around forever in the history. I'm not convinced that last bit is necessarily a good thing... I create a ton of branches, sure, but I only keep big ones that actually mean something, not every little bug branch with one commit of one line. There is a happy medium available here, too.