2

My current usage of git could be described as "commit early and often". I certainly attempt to make each commit a single logical unit (as discussed in good commit criteria). However, I'm often iterating a design and wish to save each stage. If I come up with something ugly but functional, I want to commit that checkpoint before cleaning things up.

What is your experience in this matter - has it caused issues for your team? Going beyond ugly code - is it acceptable to locally commit broken code as long as you don't push until the bugs are fixed?

Community
  • 1
  • 1
i_grok
  • 638
  • 7
  • 9

3 Answers3

7

The most common convention for this is to use a feature branch (or set of branches) that live in your repository - and perhaps somewhere online like GitHub or Gitorious.

You can rebase and rewrite that feature branch with reasonable impunity until you finally have it ready to submit upstream in whatever project-specific way you want. That allows you to build, and share, work-in-progress code without too much headache.

Along the way, building a series of commits, then using an interactive rebase (or other rewriting tools) to turn those into another set of clean, logical commits is a great way to move from checkpoints in time to checkpoints in functionality - and works best if you commit extremely often, and in extremely small parts.

Daniel Pittman
  • 16,733
  • 4
  • 41
  • 34
0

has it caused issues for your team?

Not for me/my team. As long as you don't push broken code, it's not going to affect your teammates - at least, not until you go looking for past commits.

Is it acceptable to locally commit broken code as long as you don't push until the bugs are fixed?

I think so, but I also think you'll find the answer to this question is very subjective.

If you're really concerned about pushing commits which may contain intermediate broken commits, Squash my last X commits together using Git

You can find more recommendations/opinions at git commit frequency, some of them more rigid than my own, but not without merit:

  • The guideline for the Git project itself is one commit per "logically separate changeset."
    (Scott Chacon)
  • Also you would want for each comitted version to work correctly (this help with bisecting for finding errors) (Jakub Narębski)
  • if you own the project, commit whenever you feel like it. If you're editing someone else's project, commit when the patch is finished (Tyler Gillies)

The list goes on...

Community
  • 1
  • 1
Matt Ball
  • 354,903
  • 100
  • 647
  • 710
0

Another option to checkout is:

git stash

This link has a good summary: http://csurs.csr.uky.edu/cgi-bin/man/man2html?1+git-stash

Xaca Xulu
  • 659
  • 6
  • 13