What should be committed to a repo?

Question

I am wondering, what kind of code is/should normally be committed to a project repo (branches, not master)?

Complete features only? Is it considered wrong/frowned upon to commit half completed code?

Answer 1

Commit everything that's needed to build the project to its current state (and no more).

At least I'm committing half completed features all the time, but even if half-complete it of course must be working code that doesn't break/crash the rest of the project.

Answer 2

Anything you write / create should be under revision control.

Stuff you generate (.class files, generated code) should not be under revision control: make sure though, that all team members have the same compilers/generators available.

In general, I'd commit as often as possible, making sure the committed code does work properly (compiles ok, all tests pass)

Answer 3

If you are working with a team, a good general rule is that only working code is committed to the repo. If you have tests, it should have tests, and all tests should pass (be GREEN).

How you deal with partially completed features is really dependent on your team and how the code is used. On my projects I try to keep code ready to push to production, so if a partial feature is in, it is somehow "hidden" from the user interface. There are other teams that allow the repo to drift a little between releases. Really depends on teammates and release cycles.

Seems perfectly fine to check partially completed code into your own branch. Branches are relatively cheap to create and maintain, and the provide a good back-up mechanism.

Answer 4

In a given repository you should commit the source (or input) for generating the required output for the given project. Usually this is source code, and the output is some sort of executable entity.

You should not commit output or intermediate output that is generated as part of any build step into the same repository as the source. You might choose to archive intermediate or final output in a separate controlled repository. Having intermediate files in the same repository as source files gives rise to the possibility of inconsistency and blurs the strict boundary of keeping source and only true source in your source control tool.

You should commit as often as you need a checkpoint but you should only integrate (push/merge) with any integration branch that other developers are working off when your change will not harm them, either by breaking the build or major functionality of the project.

Answer 5

The only thing most people agree on is: commit often. If you do something stupid or have a hardware failure, everything already committed is save, everything else might be lost.

As for where to commit to -- this is something you and your fellow-workers need to agree on. There are many different ways to do this and you need to find one that suits your workflow.

For example, you could chose to only commit compilable/tested/whatever code to the trunk, so that it would (almost) always be usable; everything else would go into feature branches which are only merged into the trunk when they are compilable/tested/whatever. Or you could agree for everybody to happily commit away on the trunk (which would thus always be instable) and branch off stable branches. And I'm sure there are a lot of other conventions that I can't think of right now.

Answer 6

If you are asking what are requirements before comitting in 'trunk', the answer is it depends on workflow used.

Note also that the notion of 'trunk' isn't something that is required to exist in Git repositories; you can for example have 'master' (stable branch; well, you could cal it trunk), 'maint' (maintenance branch, only bugfixes apply there) and 'next' (development branch).

But let's assume that 'master' (what you call trunk) is the only published branch. In topic branch workflow you create new separate branch for each (well, almost each: single commit changes and fixes can be applied directly in 'master'), and merge it into 'master' when it is ready.

To summarize this (and other) answers:

• put only finished work in 'master'
• do not break the build
• commits in master should pass the testsuite
• do not put generated files under version control

Answer 7

It all depends on how you want to work, but here's some food for thought:

A way of working I favour is to have a trunk and a release branch. Changes are made to trunk and merged into the release branch as and when it's appropriate.

If you commit logical units of work to trunk, you've got a good basis to cherry pick specific revisions (and therefore features) into a release branch, and you've also got a good story of your project's development in your trunk's history. If you commit everything because it's friday afternoon - it might be hard to pick out a coherent set of features to your release branch (if you have one), and very hard to write good commit comments.

But you need to balance that with committing often to secure your work and take the value out of your working copy. Unstable development branches are ideal for this. The branches can be short lived and merged into trunk at logical/functional points. These would have no penalty if you commit simply because it's 20mins since you last committed, and the story of the branch would likely be sufficiently simple that you don't care too much about individual details.

However, this is only relevant if you have a sufficiently complex development environment - if you're not likely to be holding specific changes back from release or managing multiple versions of a project at the same time, it may not be worth it.

Answer 8

If the branches are local, then commit whenever you can because you should be able to undo or change them before you push it to a remote repository.

For remote branches shared between other people, only if unit tests don't break publish it.

Answer 9

Lots of folks answering this one but I'll throw my hat into the ring anyway.

Short answer is: commit as often as you want for the files that that you edit and are not automatically generated.

Long answer is rephrased as a slightly different question. More appropriate for teams is the question what should I "push". Local commits are for you and should be used as such.

The question of what should I push is a little different from what should I commit. First of all you should only push working code as your team defines working code. Ideally code that passes the tests and compiles/runs without breaking. (Whether its defined as only full features is up to you.) However since Git is so free about being able to rewrite history you have a couple options about how to push those out to your central repository.

• If you want the central repository to have a clean less noisy commit log you can squash the commits for a feature into one commit before pushing to the remote repo. (note: this will only work if no one else has been pulling from you).
• If you don't care about how noisy the commit log for your central repo is then just push all the small commits you've had and don't worry about it.