Feedback

Tag cloud

what's your question? be descriptive.

By: Asked

How should you structure you code commits?

What is the suggested structure for commmitting code? 1) How big should the commit be? 2) What should the comments (if any) convey about the commit?

Add comment viewed 60 times Latest activity over 1 year ago

NN comments
or Cancel

3 answers

  • 2

john merriwether [ Editor ]

1) Commits should be small and concise as possible, especially if you do code reviews (which is a practice I recommend) but also still have meaning. Whenever a "piece" of the functionality is implemented, I'd say commit it. It also depends on your source control system. If you use Git I recommend committing to your local repository frequently since it doesn't effect the rest of the team. Finally push your commits to the master when there is a good time for that. If it's a SCM that has a "main" repository like Subversion then I'd recommend being more judicious about commits as they are always going to effect the team.

2) Commits should always have a meaningful message behind them. Always try to answer the question "why" if you are making a change, and include a bug tracking number in the commit if possible. This helps with code review and understanding "why" those changes were made.

NN comments
or Cancel
  • 1

kevin rutherford

Commit (and push, if you're using a distributed SCM) every time your tests are green. That is, share your code with the rest of the team, and trigger a build, every time your code is good.

In theory, this means that your TDD cycle will be something like:

RED, GREEN (commit), REFACTOR (commit)

Anything uncommitted could be lost. Anything uncommitted creates a dirty workspace, so no-one else can safely use it. Anything uncommitted is WIP, and the longer you leave it, the more likely you'll have a merge / integration problem later.

NN comments
or Cancel
  • 1

jimmy bosse

I agree with both Kevin and Jonathan. What's important to note it that different source control systems allow for different work flows. Kevin's Red, Green, Refactor, Commit is an excellent life cycle. And I agree with his comment that you should commit when tests are green. However in a central repository system with tens of thousands of tests and millions of lines of code it is impossible to expect your team to commit code that won't fail tests on opposite sides of the system.

I believe John must be working with a system like Git which allows you to perform local commits where you can safely commit after passing the tests you are actually working on, but don't have to worry that the system hasn't been broken somewhere else until you are ready to push all of those local commits to a central repository.

NN comments
or Cancel

Question's Contributors