3

I've heard conflicting philosophies on this issue - or specifically, two conflicting philosophies.

One is to check in the code as soon as the change is complete, so that your co-workers can see the change and to minimize any merging that has to be done when putting a build together.

The other is to not check in any code until you are certain that you are ready for a build, so that if a problem is found, you can address the issue as quickly as possible.

Whether or not one of these is correct, what is a good guideline for knowing when you should check in source controlled code?

This question suggests using branches to resolve this issue, but our version control (ClearCase) doesn't offer branching - so what option do we have for version control policy?

Improve this question
11
  • 9
    If you are using ClearCase, then your absolute, no.1, top priority should be to stop using it as soon as possible, switch to a modern tool and start using branches. Strategies for checking in should be a far lower priority than getting rid of ClearCase.
    – David Arno
    Commented Nov 30, 2016 at 15:40
  • 4
    I don't know anything about ClearCase, but googling for "ibm clearcase branching strategy" resulted in a lot of hits including An Introduction to ClearCase Branching Strategies which suggest it's possible to use branches in ClearCase.
    – Dan Pichelman
    Commented Nov 30, 2016 at 15:41
  • 3
    Seriously? What version control system doesn't have branches? (Well, okay, Subversion doesn't, but it has something much better: cheap copies, which let you model branches, tags, and even some stuff the Subversion developers never imagined, on top of it.) 0.5 seconds of Googling reveal multiple tutorials on branching in ClearCase, including recommended workflows and strategies.
    – Jörg W Mittag
    Commented Nov 30, 2016 at 15:41
  • 10
    The current philosophy is to stop using whatever version control system you are using now and switch to Git.
    – Pieter B
    Commented Nov 30, 2016 at 15:54
  • 1
    @8bittree Of course local commits. The problem the OP deals with is that he's stuck to yesterdays VC mechanisms. Never ever I'd go back to those beasts. Pushing to production is only done, once you got a block of work ready for testing.
    – user188153
    Commented Nov 30, 2016 at 17:42

4 Answers 4

Reset to default
6

I come from the side that believe commits should be frequent. Exactly how frequent will depend on your personal development style. Some in the TDD world will commit every few minutes (each completed cycle), others perhaps a few times a day at what they feel to be a good point. Some benefits of frequent commits are:

  • Work is backed up, useful not just in case of disk failure or some other system problem, but human issues such as leaving your laptop at home (meaning you can jump on a spare dev system if one is available) and pick up where you left off, or illness (someone else can pick up your work)
  • Related to that, the ability to roll back if you realise you have gone down the wrong path at some point, without necessarily having to throw everything you have done away
  • Meaningful comments with the commit will provide a development story, helping you and other team members understand the change
  • Reduced likelihood of merge conflicts, as a result of using small incremental commits. Where conflicts occur, they are easier to resolve
  • In a CI environment, you will be notified early of any build failures or if you have broken any tests, and can fix them while the work is still fresh and before they cause issues for other team members

Instead of branching you can use feature toggles. These can be used to keep your feature hidden on separate code paths until it is ready to be revealed. However this does introduce some complexity and extra overhead, so it's generally not worth doing this for small tasks.

I'm unclear what you mean by "if a problem is found, you can address the issue as quickly as possible". Commits are quick and cheap, you fix the bug and make another one (commit, not bug). If on the other hand you mean "oh no I've found a major problem with my feature and want to pull the whole thing from the build", feature toggling can also help in this regard, as you just switch it off.

Improve this answer
6

One is to check in the code as soon as the change is complete, so that your co-workers can see the change and to minimize any merging that has to be done when putting a build together.

The other is to not check in any code until you are certain that you are ready for a build, so that if a problem is found, you can address the issue as quickly as possible.

These are really both correct. You should check-in as soon as you have code done. Your check-in should always build.

That is the entire point of Continuous Integration and stuff like gated check-ins. You have a build step to make sure that you didn't break the build. You have a suite of unit tests to make sure the code didn't break stuff. You might have a set of smoke tests to make sure the code works on a real environment. All of that provides abundant confidence in #2, so you can abide by #1.

Improve this answer
-2

The "possible duplicate" question focuses on the chance of losing work in case of calamities. I would argue version control should not be used as a backup tool. It should reflect the development stages of a system, one should avoid noise that are really just Ctrl+S moments and do not mean anything in the progression of development. At least in your trunk or in any branches. That shelving thing may be good for intermediate saves though.

The folks in the other thread seem to love branching. I don't. You should avoid branching if you can. Sometimes there is no way around it but it is a potential pain waiting to happen, once you have to merge you may find it is not so easy any more so it is always a potential risk.

The main source for guidelines in this matter would be your business and the point in your development cycle. If you know you will not be delivering anything for a month you will behave differently from when you have to deliver tomorrow. Does whatever you check in have to be stable or can it be an in-house test version? It depends on circumstance, both may be valid at different times.

Improve this answer
4
  • 5
    version control should not be used as a backup tool: well, I often backup to the last git-commit when things start going astray. And each time I forgot "commit often" I start biting my own back.
    – user188153
    Commented Nov 30, 2016 at 15:57
  • 5
    If you don't commit often, then when you finally commit you run the exact same risk of conflicts as if you did the same work over 10 commits in a private branch.
    – RemcoGerlich
    Commented Nov 30, 2016 at 16:00
  • 5
    And I also don't agree that the business and its development cycle matter here -- the use of private branches and your commits in them is entirely confined to your own computer and your own habits, the rest of the company will never be affected. Unless of course you accidentally delete a day's work and don't have a recent commit to go back to.
    – RemcoGerlich
    Commented Nov 30, 2016 at 16:03
  • git branches are fine for Ctrl-S saves, as long as you squash them together in a single commit when merging your work.
    – Thorbjørn Ravn Andersen
    Commented Oct 8, 2023 at 18:23
-2

There is no perfect solution to this problem

To fully test a feature will require that you deploy it to a test environment.

But to deploy code, even to test environment will normally require that the code is checked in and versioned!

Obviously if you check in and version broken code you have a version of your software which you never want to release and will have to do another checkin to fix! so it is 'a bad thing'(tm)

However, surely everyone accepts that even the most careful checking wont catch all the bugs? So you have to accept that any version of your software is potentially faulty and allow for bug fixes in your versioning and deployment stragetgies

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.