Home/ Questions/Q 567185
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T13:03:23+00:00

I am starting to get a reputation at work as the guy who breaks

  • 0

I am starting to get a reputation at work as the “guy who breaks the builds“.

The problem is not that I am writing dodgy code, but when it comes to checking my fixes back into source control, it all goes wrong.

I am regularly doing stupid things like :

  • forgetting to add new files
  • accidentally checking in code for a half fixed bug along with another bug fix
  • forgetting to save the files in VS before checking them in

I need to develop some habits / tools to stop this.

What do you regularly do to ensure the code you check in is correct and is what needs to go in?

Edit

I forgot to mention that things can get pretty chaotic in this place. I quite often have two or three things that Im working on in the same code base at any one time. When I check in I will only really want to check in one of those things.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A few suggestions:

    • try work on one issue at a time. It’s easy to make unrelated changes to the codebase that then end up being committed as one big chunk with a poor log message. Git is excels here since you can so easily move switch branches, and stash and cherry pick changes.
    • run the status command before a commit to see which files you’ve touched and if you’ve created new files that need to be added to version control.
    • run the diff command to see what you’ve actually changed. Often times you find that you’ve left in some debug logging that should be taken out or made some unnecessary change that is just cluttering up the diff. Try to make your diffs as small and clean as possible.
    • make sure your working copy builds with your changes in it
    • update before checking in and make sure that your working copy builds with other peoples changes in it
    • run what ever smoke test suite you might have to make sure that your changes work correctly
    • make small and frequent commits. It’s a lot easier to figure out what has broken the build when the breaking commit is small.

    Other things that the team can do is setup a continuous integration server like David M suggested so that the broken build is discovered as soon as possibly and automatically.

    • 0