1

We had a debate on our team about how clean the Master branch should be.

The application is written and maintained by two people, me (a developer) and a GUI/UX designer. The GUI/UX designer does a lot of prototyping (or "sandbox"-type experimentation) to test or fix various layout issues in JS & CSS. This preliminary or tentative work introduces some "dirty" code such as inline CSS, scattered JS, poor formatting, etc. She would like to directly check that into Master as soon as functionally her goals her achieved, and I stop her.

My own checkins into Master are very clean and I always do a Diff to make sure they're final, formatted, and modularized. I clean up the preliminary or tentative changes I had to make to ensure that Master is "official." Should Master be allowed to get dirty?

gene b.
  • 315

2 Answers2

5

This is ultimately a decision a team needs to make based on it's coding standards and release cycle.

If you release fairly infrequently (every couple of sprints) the argument could be made that checking into master to be improved at a later date is reasonable. However assuming a few things I'll draw up a soap box:

If:

  • You work in an environment where Master should always be production ready (and can be released at any time)
  • You have the ability to check in without committing to master (perhaps a local git copy of the master repository) using a pull request mechanism

Then I would suggest that any code which is in the master branch should be production ready. This includes:

  • Clear and readable,
  • Properly unit tested,
  • Meets all other coding standards,
  • and it builds!

Otherwise the need may come to deploy (at the end of a release, sprint, or as an urgent fix) and poor quality code is in your master branch. This will ultimately lead to code which isn't improved and technical debt in the future.

Liath
  • 3,436
0

I think we can all agree that checking in non functional code is a bad thing(tm)

However, your definition of 'dirty' is pretty subjective.

I would suggest you switch to gitflow, allow any commits to feature branches. but have a PR/Code review process before the feature branch can be merged into development.

Additionally, Have a think and make sure you are not applying stricter rules to others than you apply to yourself.

Its all too easy to give yourself an out "Oh I need to meet the deadline/That hack is acceptable/It has to be done that way because I googled for ages but couldn't find an answer" When you are reviewing your own code and then pick up others on Pascal vs camel case

Ewan
  • 83,178