14

I'm wondering, how could I avoid a commit in really small changes of code. For instance, sometimes I miss a space between parameters or that kind of tiny code formatting. The reason I ask this is because later I have to push my commits to a remote repository and I don't want to include those small changes.

Any ideas? Thanks

user229044
  • 232,980
  • 40
  • 330
  • 338
Robert
  • 143
  • 1
  • 4
  • 2
    See also http://stackoverflow.com/questions/2302736/trimming-git-checkins-squashing-git-history/2302947#2302947 for squashing commits – VonC Jul 13 '10 at 05:51
  • 1
    You might also want to consider adding a pre-commit hook to help review your coding style. With that, you can have git complain if you try to commit code that violates some standards that you've set. You can help prevent bad commits in the first place! The example pre-commit hook (`.git/hooks/pre-commit.sample`) looks for things like trailing spaces after lines. You could wrap GNU indent in a script, for example, to enforce a specific coding style, and put that in your pre-commit hook. – David Brigada Dec 15 '11 at 14:26

4 Answers4

26

Update: As others pointed out, do not do any rebasing, or history re-writing of any sorts if you've pushed to a remote origin and shared this code with other developers. Short answer: It's dangerous and risky!

I'd recommend checking out the rebase command for this. It does exactly what you are asking for

What this does is take smaller commits and combine them into larger ones

To use it:

git rebase -i HEAD~5

Your editor will pop up with the last 5 commits from the head of the current branch, with some documentation. In your case you will want to use squash. The site I linked explains it really well, they have this example:

pick 01d1124 Adding license
squash 6340aaa Moving license into its own file
squash ebfd367 Jekyll has become self-aware.
squash 30e0ccb Changed the tagline in the binary, too.

This will package the previous 3 commits and put them all under the one you've marked as pick. You can then modify the commit message and so forth.

Have fun

Community
  • 1
  • 1
Bartek
  • 15,269
  • 2
  • 58
  • 65
  • +1. Squashing is the way to go. More information here: http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html – Jeet Jul 13 '10 at 02:24
  • 2
    Just whatever you do, *don't* do this if you've already pushed your changes :S – andrewdotnich Dec 14 '11 at 06:00
  • even if the repository is just for me and not for any other developers? – Homero Esmeraldo Aug 09 '18 at 10:58
  • I just did it and it ends up conflicting with the remote. And I had to do a merge and solve the conflict. So what was supposed to make the history log better, made it worse. I don't know if there is any clean way to rebase the remote. – Homero Esmeraldo Aug 09 '18 at 11:29
18

The only way to make a change is with a commit. However, you could amend a previous commit to include the new change if you like. This may be the best solution when you haven't pushed the previous commit to a remote repository yet.

There's good information about amending git commits in the Git user's manual and in a blog post.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
David Underhill
  • 15,896
  • 7
  • 53
  • 61
  • Thanks for the links. However, I don't like [clickhere] linking style. Here is an useful bookmarklet for generating descriptive links: [Copy the markdown link or edit it](http://pastebin.com/qEafAErg) (pastebin link) – takeshin Jul 13 '10 at 07:12
  • `commit --amend` works great if you did not `push` previous changes to remote `origin`. If you've already pushed, then, after `amend`, you'll have to `push --force`, which is very risky. – Danijel Oct 19 '20 at 13:19
3

One of the best ways to address this is to use git difftool to run a visual tool like xdiff or winmerge on every modified file before committing. This makes it easy to undo minor changes and will catch significant changes you forgot you made and aren't ready. I catch a fair number of bugs this way. For example, a missing or extra html tag can be hard to spot when you are looking at code, but is easy to spot when you do a diff.

mikerobi
  • 20,527
  • 5
  • 46
  • 42
  • 1
    Is there some reason you wouldn't just use `git diff`? That's one of its primary purposes... – Cascabel Jul 13 '10 at 02:04
  • @Jefromi, git diff doesn't let me edit code and revert portions of files. Also, I find it much more help full to have a side by side diff of the full file contents helps me catch mistakes I might miss with a line by line diff (I wouldn't be surprised if there is an option for this, but it wouldn't make up for the lack of editing) – mikerobi Jul 13 '10 at 14:01
  • Ah. I thought this was mostly in a verification context, where you wouldn't be likely to edit, just add/reset changes from the index. Cool. – Cascabel Jul 13 '10 at 23:51
0

One option is to work on a separate branch, and then squash all the commits of the branch into a single commit when you feel like you've done enough, see this question.

vfinn
  • 140
  • 1
  • 8