With dvcs/git, is a single commit preferred over multiple, small, thematic commits?

This may not be a git specific question, but it comes up in the context of git. The idea may apply more broadly to other vcs’s.

I am working on a small project in which I am currently the only developer. I’m getting used to using git, so I am wondering about best practices. As I implement new features/functions, I find that I work on multiple files, their examples, and documentation at once, such that my git status may report 15 files that have changed. But those files might relate to 3 different parts of the project.

  • Is there a way to remove the history for a single file in Mercurial?
  • Delete all local changesets and revert to tree
  • Check in single file with Mercurial?
  • What is the Difference Between Mercurial and Git?
  • What is the value-add of Repo (+git)?
  • How to setup GIT bare HTTP-available repository on IIS-machine
  • Is it better to commit them in 3 separate parts, keeping the related files together, so that I could later go back and more easily find those commits. Or it is just as easy to commit them all at once with an appropriate message?

  • Create archive of modified files in GIT via batch file
  • How to install hooks in gitolite
  • Git: Can I commit my working directory to a new branch without committing it to a current branch?
  • How to list the change history of the directory tree in git
  • Change first commit of project with Git?
  • How to integrate UML diagrams into GitLab or GitHub
  • 3 Solutions collect form web for “With dvcs/git, is a single commit preferred over multiple, small, thematic commits?”

    One criteria that can help you make the right “amount” of commit is git bisect or git blame: would a large commit be a nuisance when trying to git bisect in order to detect a bug?

    That is what describes the “Understanding the Git Workflow” blog post, when it describes “checkpoint commits” (too little commits capturing the code in a unstable state), or “no-ff commits” (which represents too many modification bundled together in one large commit).

    Its preferable to make commits atomic. That is, a commit represents one logical change to the project in question, and can stand alone.

    This allows

    1. Easy code inspection
    2. git bisect to work correctly

    It can be difficult, and there are many differing views about “the one best workflow”. Where possible it is better to

    1. separate concerns – use a number of short lived separate branches, one per concern. You can always squash your commit sequence before the final merge and publishing to a more senior branch.
    2. commit often – smaller steps make it easier to find where mistakes happened and why, and to align merges. Again you can squash after it works.
    3. use the staging area and git stash to partition which work you place in each commit.
    4. Don’t worry too much about minor slip ups. Foresight only happens if you walk backwards..
    Git Baby is a git and github fan, let's start git clone.