0

My first experience with Git and servers was when we had a server where the only way to get code onto it was to push to Github which then had the server do a pull through a webhook. We ended up with a lot of tiny commits with messages such as "Fix previous commit - commit #3" and "Fix attempted fix for commit #3" because we had no way of knowing whether or not our commits would run properly on the server until after they were committed and pushed.

Recently I deployed my first Rails app to Heroku and although I see a lot of positives there it seems to me to be very similar to the situation I described above. Unless we want to set up our own server to mirror the Heroku servers very closely so that we can upload and test code without committing to Git, there's no way of knowing whether or not our code works until it's already committed, and therefore it might require many small, useless (as far as the repo's history is concerned) "tweak" commits to patch up failed commits.

I know that there are plenty of questions already that explain how to set up and use a staging server in addition to a production server, but that still doesn't solve the problem of polluting the repo history. I know that it's possible to ammend commits, squash, rebase, etc. so that these "useless" commits could be dealt with (as mentioned in the answers to this question), but with multiple people potentially doing this all at once I can see it getting ugly and creating all sorts of conflicts in Git.

TL;DR
How can we maintain a "clean" Git history for our projects when using Heroku so that we don't have a whole slew of commits or branches creating confusion and noise just for the sake of fixing something that should have worked in the first place but didn't simply because we couldn't test it in the server environment until after committing and pushing?

Community
  • 1
  • 1
mayhewluke
  • 133
  • 1
  • 6
  • 1
    You said you could not test locally. Why? – TheMorph Mar 16 '14 at 01:31
  • It's not that I *can't* test locally but rather that the local environment is not likely to mirror the production environment exactly and so it's possible to push a commit that works locally and doesn't work on the production server. – mayhewluke Mar 16 '14 at 16:10

3 Answers3

1

You could look into adding Heroku Local to your workflow for testing your application locally.

heroku local

seantomburke
  • 10,514
  • 3
  • 18
  • 23
0

You can try this How to avoid tons of commits when debugging Heroku app

The more important question may be: Why does your software break so often that you consider the amount of fixes polluting your repository? Maybe you can streamline your development process.

Community
  • 1
  • 1
TheMorph
  • 572
  • 2
  • 10
  • As I mentioned in my question, I've seen that post and it would indeed be the solution to my question except for one issue: multiple team members each rewriting Git history and pushing to the same server strikes me as a recipe for disaster. It's not that our software breaks frequently but that there's no way of telling whether or not a commit - whether it's introducing a new feature or fixing a bug - will work as intended on the server until after committing and pushing. – mayhewluke Mar 16 '14 at 16:34
  • According to [this Heroku page](https://devcenter.heroku.com/categories/billing) each ***app*** gets 750 dyno-hours/month. Perhaps a potential solution would be for each developer to have their own [fork](https://blog.heroku.com/archives/2013/6/27/heroku-fork) of the app for development so that they can push, rebase, squash, etc. without conflicting with other developers, and then when their commits are certain to work they can push to the main repo? – mayhewluke Mar 16 '14 at 16:44
0

You could have a separate Heroku App just for testing purposes and when your commit works, squash all the commits into 1 and push this to the production.

git remote add origin https://git.heroku.com/production-repo.git
git remote add test https://git.heroku.com/test-repo.git

While you work you commit and git push test master, then when you are ready to push to the production, start the interactive rebase:

git rebase <commit-id-of-the-first-commit-before-production> -i

then change:

pick 8e4804f test this
pick 6c29fdd fix that
pick 4ddbb35 break this
pick ececbfb try that
pick 4f563eb add this
pick be065ae delete that

to 

pick 8e4804f test this
s 6c29fdd fix that
s 4ddbb35 break this
s ececbfb try that
s 4f563eb add this
s be065ae delete that

And change the commit message to whatever you want. Now you can just

git push origin master

and you'll only have the desired commits on the production repo

seantomburke
  • 10,514
  • 3
  • 18
  • 23