20

I have the following git workflow:

  1. Create new feature branch
  2. Work on feature branch
  3. Commit often
  4. Once feature is complete, merge into master branch
  5. Rinse and repeat

However, sometimes, I have the need to revert a whole feature from master. This could involve a whole lot of reverting. (The reason for needing to revert a feature is I have a website that works off of one repo. From there, we use a script that deploys the site to either our Production site or Staging site. Both are done from our master branch. Don't ask, that's just what I've been given to work with. Sometimes, I'm working on something that I stage, but then an immediate change needs to be made, so I needed some way to pull my changes in order to clean the repo.)

I'm thinking that the easiest way to do so is if each feature branch has only one commit. Then I could revert that commit. So naturally, I am thinking of squashing all commits of a feature branch into one, prior to merging it into master.

So now my workflow would look like:

  1. Create new feature branch
  2. Work on feature branch
  3. Commit often
  4. Once feature is complete git rebase -i HEAD~number_of_commits (or if remote branch is available, origin/feature_branch)

Is there any issues with this logic? Does it go against any best practices? I did some testing myself and the whole workflow seems to run smoothly and solves my problem, but I wanted to run the idea by other (smarter) Git-ers to see if there is anything wrong with it.

Thanks!

Fillip Peyton
  • 3,637
  • 2
  • 32
  • 60
  • 1
    Have you looked into `git merge --squash` ? Any particular reason why you chose `rebase` instead of using the `squash merge` ? You would not have a linear history when you do a `merge`, but the commits in the feature branch would still have linear history, and you would just have one merge. – Tuxdude May 08 '13 at 20:03
  • I just looked into that for my scenario. Very nice. I don't know which I would use more (maybe `rebase` since I throw away these branches somewhat often), but having the history on my feature branch is a nice thing to have. Thanks for your help! – Fillip Peyton May 08 '13 at 21:21
  • 1
    @Tuxdude: Consider making that an answer. It probably *is* the answer. – sleske May 08 '13 at 21:24
  • Agreed. @Tuxdude, If you made this an answer, I would definitely upvote it, if not accept it. – Fillip Peyton May 08 '13 at 21:42
  • Added an answer. By the way, a small misleading typo in my previous comment. There is a commit with a merge message, but no actual merge (i.e. a commit with 2 parents) in either of the cases. I have explained the result for both the cases in my answer which should hopefully give more clarity. – Tuxdude May 08 '13 at 22:01

2 Answers2

22

You should look at leveraging the squash merge capability of git i.e. git merge --squash, so that you do not rewrite history unnecessarily.

Both git merge --squash and git rebase --interactive can be used to produce a squashed commit with the same resultant work-tree, but they are intended to serve 2 totally different purposes. Your tree eventually ends up looking different in both the cases.

Initial tree:

a -- b -- c -- d    master
      \
       \-- e -- f   feature1

After git checkout master; git merge --squash feature1; git commit:

a -- b -- c -- d -- F    master
      \
       \-- e -- f   feature1

After git checkout master; git rebase -i feature1 and choosing to pick c and squash d:

a -- b            /-- F  master
      \          /
       \-- e -- f   feature1

As you can see from the difference, you do not rewrite the history of any branch when using git merge --squash but you end up rewriting the history of master when using git rebase -i.

Also note that the actual commits (for the ones which got squashed) would be present in your git history in both the cases, only as long as you have some branch or tag reference through which those commits are reachable.

In other words, in the above example, if you delete feature1 after doing merge --squash, you would not be able to actually view the commits e or f in the future (especially after the 90 days reflog period). The same applies to the commits c and d in the rebase example.

Tuxdude
  • 47,485
  • 15
  • 109
  • 110
3

One specific downside to your approach is that it severely reduces the utility of git bisect in tracking down bugs in your code.

That said, if you find yourself reverting an entire feature often enough to where you're looking for ways to optimize that process, you may want to ask yourself whether you're merging into master too quickly. You may want to consider using multiple long-running branches to set up a workflow that suits your project better.

Wally Altman
  • 3,535
  • 3
  • 25
  • 33
  • We'll the reason for this is I have a website that works off of one repo. From there, we use a script that deploys the site to either our Production site or Staging site. Both are done from our `master` branch. (Don't ask, that's just what I've been given to work with.) Sometimes, I'm working on something that I stage, but then an immediate change needs to be made, so I needed some way to pull my changes in order to clean the repo. – Fillip Peyton May 08 '13 at 20:53
  • If possible, I would try to modify the script to deploy a different branch to Staging (or ideally, allow the deployment of arbitrary branches to either site). But if you can't, then your proposed approach seems reasonable. – Wally Altman May 08 '13 at 21:09
  • Yeah, I am working on that with our team, but for the moment, I was going to see if there's a good way to do this. Thanks for your help! – Fillip Peyton May 08 '13 at 21:22