2

I'm currently re-factoring a part of our application at work. I'm normalising a data structure from a flat list of fields to a parent/child relationship. This has an impact on all layers in the application:

  • The database
  • Models
  • Business logic; and
  • The UI

Instead of creating a few massive commits - where each commit compiles - I've decided to break it down into a large number of small commits (accepting that the build will break). Why? So I can rollback/discard my edits quickly.

My plan was to keep the commits local until the whole thing compiled and then sync with the server. However, it's now been two days and I'm not half way yet. So I'm thinking that I should sync my commits in case I lose my work.

Which leads me to the question. Would it have been better to sync the commits on day one? If so, what's the best way to handle the CI server? Just accept that there's a lot of broken builds coming my way?

  • 6
    Isn't that one thing that branches are for? – immibis Jul 25 '16 at 2:40
  • 1
    I forgot to mention. We're using GitHub flow and the CI server is configured to run tests on any branch that has been pushed. Perhaps this is the real cause of my problem? – Mitkins Jul 25 '16 at 3:56
  • 1
    Sounds like it. Figure a way to exclude some branches from the tests. These tools are supposed to help you. Not get in the way. Don't give in to bad practices because some tool told you to. – candied_orange Jul 25 '16 at 5:25
  • 2
    Maybe think about the real matter, why is everything breaking? Isn't it possible that, although you already do small commits, you still take on too big changes as a single task? Or is the code too tightly connected so it breaks all the time? Those issues would be my first things to look. In general it seems possible to deliver a work-in-progress which is not complete but stable every few hours at least. It might make the codebase better also for future changes. – Luc Franken Jul 25 '16 at 8:28
  • 1
    @Camel if you're going to do that, might just want to give your team a head's up before they get any notifications about it. – RubberDuck Jul 25 '16 at 23:06
3

If you're using git, you should be doing your work in a branch. Create as many commits as you like on this branch, but don't check them into your CI server. The CI build should be kept clean. You don't want other developers accidentally getting your broken code. Once you are finished your work (or at least have a compilable chunk of code), you can consider squashing this into a single commit, which you can then merge back to trunk and push to the server.

I would recommend making small commits, even of uncompilable code. I would not recommend pushing them to the server though. Keep your history clean and your intentions clear. If you are worried about the amount of code you need to push all at once, try to create smaller chunks of compilable code.

Your CI server is there for a reason. The tests run on it for a reason. Don't be the guy who breaks trunk intentionally. It's not fair on anyone else in your team and is unnecessary for the work you're doing.

  • Cool, thanks. The commits are in their own branch. I was originally intending on keeping my work from origin (so the CI server would not compile broken builds). But then by not doing that, my work exists only on my machine. Is this a matter of build configuration with the CI server - or is there something else I can do to make sure that my work is backed up? – Mitkins Jul 25 '16 at 4:21
  • You could back your machine up or upload your work to a cloud source. Basically the CI server is for builds, not backups. – Stephen Jul 25 '16 at 5:14
  • At the moment, we're using GitHub as the cloud service/backup. The CI server monitors GitHub to kick off builds. Is there a better way to do this? – Mitkins Jul 25 '16 at 5:17
  • With regards to not pushing to the server, I assume you mean within a short time frame (i.e. not days)? – Mitkins Jul 25 '16 at 23:34
2

Don't ever leave code on just one box. Hard drives fail. People get sick. Accounts get locked out. Buildings catch on fire. And sometimes other people just need to see what you've been up to.

Use a separate branch. Commit often. Keep it in sync.

Don't commit broken code without SAYING that it's broken and HOW it's broken. It's so much easier to back track if where you want to go is clearly labeled.

  • Any tips on documenting what and how - especially for a large number of commits (30+)? – Mitkins Jul 25 '16 at 5:36
  • 1
    I use a lot of tags, like 'broken'. If it's tagged as something in particular, I know it's on purpose – Gil Sand Jul 25 '16 at 8:11
  • 3
    I like to prefix my commits with REDBUILD or REDTEST to indicate that they fail to compile or pass the tests, and then if necessary add more info at the bottom of the commit message. – Sebastian Redl Jul 25 '16 at 8:11
  • This article on using emojis presents some interesting ideas - tjvantoll.com/2016/06/10/emoji-and-coding – Mitkins Jul 25 '16 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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