2

At my work, we use Git as our version control system. We have a master branch, which I have direct commit access to. Sometimes I have to make a trivial fix, such as fixing a typo in documentation, and the unwritten standard in our office is that getting reviewers for that is a waste of time (please don't argue this point, changing company culture is not a battle I want to fight today). So I have two options for how to go about making my trivial change:

Create a Pull Request

  1. Create a branch off of master
  2. Make my trivial change
  3. Push the change to the branch remotely
  4. Go the Web UI, which is the only way to make pull requests on our system
  5. Create a pull request with zero reviewers*
  6. Merge it

Direct Commit

  1. Make my trivial change
  2. Commit directly to master

The end result for the two is the same; my change makes it into master. But the first method takes much more time than the second does. Assuming my team is not interested in reviewing the change, is there any reason, technical or organizational, that I would want to do the pull request rigmarole?

Community
  • 1
Thunderforge
  • 2,798

1 Answers1

4

I once spent a full week finding a bug that was caused by a checkin like this. Not even a trivial fix, but a trivial change where a developer thought that if (p != NULL) should be replaced with if (! p) because it looks nicer, and shouldn't be code reviewed because it was trivial. (The bug only became visible after a co-worker spent six months completely rewriting a subsystem, and it led to a crash if you put your computer to sleep for 40 to 50 seconds, and in no other case).

Make sure that code reviews can be done with minimal overhead. In my workflow I can do a trivial change plus code review in two minutes. That's not worth taking risks. If it takes you longer, change your process.

gnasher729
  • 49,096