1

For squashing commits in git, the usual advice I see given is to use the rebase command. Also to use it interactively (-i) for more detailed options.

But, the pattern I've fallen into (just by playing around) is to use the reset command for squashing.

Usually I do:

git reset origin/<branch I'm working on>

Or, if I want to squash to any commit:

git reset <sha>

Then, after an add and commit, my local commits are squashed into one and I'm ready to push.

Am I following an anti-pattern? What kind of negative side-effects could I run into?

Jonathan.Brink
  • 23,757
  • 20
  • 73
  • 115
  • Well, it's a working solution and probably it has no "hidden" downsides. Certainly you should be careful, otherwise you may lose your changes, but it's "here and now" caution w/o any further effects – user3159253 Apr 22 '14 at 00:42
  • FYI, doing `git reset ` followed by `git commit` in your case will get you the same result as doing an interactive rebase. As a matter of fact, sometimes I do the same thing, because as you've observed, sometimes it's just more convenient to do it this way. Git is flexible enough that you can do it either way. As for whether or not it's an ***anti-pattern***, I think that's a matter of opinion. Personally, I see nothing wrong with it, as long as you know what you're doing. –  Apr 22 '14 at 03:10
  • You can use `git stash` to save your local changes instead of resetting to HEAD or before resetting to another commit. – Pavel Šimerda Apr 22 '14 at 06:51
  • Thanks for the comments. It seems that "reset" is almost like the forgotten power tool of git... – Jonathan.Brink Apr 22 '14 at 12:49

2 Answers2

3

The main thing that you lose with this approach is fine control.

With an interactive rebase you don't have to squash down into just 1 commit, you can group them into logical change sets and even discard commits if you need to.

Also you get the opportunity to simply select the commit message from one of the commits instead of re-typing a new one, this is important if your memory is as bad as mine ;-)

But, all in all interactive rebase is just a tool for you to manipulate your local commit history, if you can do what you need another way that's easy for you then I say, why not.

Tim Jarvis
  • 18,465
  • 9
  • 55
  • 92
1

If you haven't already, you should check out these articles on git reset:

Can you explain what "git reset" does in plain english?

http://git-scm.com/blog

They each discuss the use cases and potential pitfalls far better than I can. Note that using reset without designating --hard or --soft automatically defaults to 

git reset --mixed

To answer your question, I think you will be fine as long as you don't suddenly switch to using git reset --hard as that can actually destroy your working directory before you push.

Community
  • 1
  • 1
Andrew L
  • 1,164
  • 12
  • 20
  • I think the most important part to this answer is the last paragraph. Everything else is just unnecessary clutter that isn't really relevant to the question. The original poster is specifically using `git reset`, which of course defaults to mixed mode, so he's not losing any work as long as he commits right after, which he said he is. –  Apr 22 '14 at 03:12
  • 1
    Fair enough. Will leave it up in case someone else finds it helpful. – Andrew L Apr 22 '14 at 03:26