14

While trying to sort out bugs with apps on Heroku, I usually end up with a bunch of Git commits related to the bug fixing process, as I need to commit the updates in order to push to Heroku. Are there any clever ways of cleaning up those commits prior to pushing to the main shared repo for the project?

Matt Fordham
  • 3,147
  • 10
  • 34
  • 51

3 Answers3

18

Create a new branch when you start debugging (git checkout -b debugging or similar), and then make all your commits on there, pushing them to Heroku instead of your master via git push heroku debugging:master.

Then when you've fixed the problem, you can squash your debugging changes into a single commit and merge them back into master:

git checkout master
git merge debugging --squash
git branch -D debugging

There are lots of other ways to go about doing this, it all comes down to which you find the most logical.

Andrew Marshall
  • 95,083
  • 20
  • 220
  • 214
  • 1
    Bad idea. Squashing is bad, because it prevents Git from reasoning about the connection between the pre-squash and post-squash commits. See http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html . – Marnen Laibow-Koser Dec 12 '11 at 22:22
  • 4
    @MarnenLaibow-Koser I think in most cases that would be correct, but here the only reason so many commits are being made is because they *must* be made in order to even test if they are correct—you wouldn't normally commit when you have no idea if you've yet solved the problem. If committing to even test wasn't required there probably would be just one commit to solve the issue. – Andrew Marshall Dec 12 '11 at 23:06
  • 1
    I don't really think that changes the argument against squashing. If the commits were made, they generally should be kept (especially if they were pushed to a remote repo); otherwise, Git can't keep track of ancestry properly. What I *do* think, however, is that the OP should figure out a way of testing locally so that he doesn't have to push to Heroku just to test. – Marnen Laibow-Koser Dec 12 '11 at 23:25
  • 1
    @MarnenLaibow-Koser In the little I've ever used Heroku, there have been times where everything is working locally but not remotely. If the remote repo being pushed to was one pulled to by other devs, then yes that should never be overwritten, but the Heroku remote is (typically) never pulled from. I don't agree that commits (especially many of them) that never really had much meaning in the first place should be kept when they can be squashed into one, still small and contained, commit with much greater meaning. A commit saying "this might solve the problem" isn't very useful or meaningful. – Andrew Marshall Dec 12 '11 at 23:30
  • 1
    "The Heroku remote is never pulled from" -- ??? I often use it as the main repo on multiperson projects (cheaper than a private GitHub account...). And the OP *was* talking about "the main shared repo"; it's not clear whether that's Heroku or not. As for commits saying "this might solve the problem", those commits shouldn't have been made in the first place. Every commit should be fully tested -- Git's partial commits and `stash -k` make this easy. Anyway, squashing breaks Git's analysis tools; keeping intermediate commits is a small price to pay for making Git smarter. – Marnen Laibow-Koser Dec 13 '11 at 00:05
  • 1
    Anyway, I usually find that intermediate commits each have a lot of meaning. A big squash commit, OTOH, doesn't. It has a lot of *content*, but not a lot of *meaning*, because it essentially just says "here's a big dump of code". Small commits with meaningful messages, OTOH, can tell you a lot. – Marnen Laibow-Koser Dec 13 '11 at 00:07
  • 3
    @MarnenLaibow-Koser How can you test something before committing when the problem is solely with the remote server—and thus not testable locally—and the only way to get changes to the server is by pushing commits?? That doesn't make any sense, and no amount of stashing or partial commits will change that. And that's my very point: this is a special case, and should be treated as such. – Andrew Marshall Dec 13 '11 at 00:11
  • 1
    Well, yes, this is a special case. But I don't think that excuses squashing, particularly since in this case the commits to be removed have *already* been pushed to a public repo (Heroku). You never, never, *never*, should get rid of a commit that someone could already have pulled. Also, Heroku now offers interactive console access, which should (when possible) probably be used for testing before committing things that might not work (not that I always do that myself :) ). – Marnen Laibow-Koser Dec 13 '11 at 14:25
4

You can do a git rebase -i <commit_before_fixing_commits> and edit / squash / drop the commits and then push to Heroku.

manojlds
  • 290,304
  • 63
  • 469
  • 417
0

You don't really want to clean up these commits. What you want to do instead is encapsulate them in a merge commit:

  • Check out master -- git checkout master
  • Create a branch for your topic -- git checkout -b my-cool-bugfix
  • Do the work on your branch
  • When ready, git checkout master again, then do a non-fast-forward merge. This is essential: forcing non-fast-forward with the --no-ff option means that a merge commit will always be created. In this case, the command would be git merge --no-ff my-cool-bugfix.
  • You now have one merge commit on master that encapsulates all your branch commits, but retains the commit history so that Git's history analysis tools don't break.
  • When you've tested the fix, git push heroku.
Marnen Laibow-Koser
  • 5,959
  • 1
  • 28
  • 33