2

Given that I am the least experienced in this place I thought in the beginning it's normal what a coworker is doing, committing and pushing nonsense changes directly to master including broken parts. I used to do the same in very extreme situations when fixing something broken or under time constraints (small sync to showcase), this doesn't seem to be the case.

For example today I am being notified of merge conflict because of: adding 4 new lines, commenting out 2 logging messages!

Maybe the reason is to be on top on developers list with the most commits to get raises (just like the nonsense competition on contribution graph on GitHub), but I am getting distracted now very often with these nonsense pushes to master.

How can I approach this issue as the least experienced person here?

|improve this question

closed as off-topic by gnat, Twyxz, IDrinkandIKnowThings, mcknz, Rory Alsop Apr 4 at 10:06

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    How do you know this was not an urgent request from management, just as your changes to master? What makes you say they are "nonsense"? – nvoigt Apr 2 at 5:32
  • 3
    Seems, the commit policy needs a revision. No commit to master should be direct (without a review), and the PR should accompany the integration and unit test reports. Looks like in your case, these basic things are not taken care of. – Sourav Ghosh Apr 2 at 5:46
  • @nvoigt I have provided the example of pushing to master: Four new lines and commenting out a few logging lines, I am not exaggerating, that's exactly the reason why I decided to get some advises here. – josi513 Apr 2 at 6:54
  • @SouravGhosh "the commit policy needs a revision", this is a very solid advise. I am not actually aware of any commit policy, however it seems like something to propose on the next meeting. – josi513 Apr 2 at 7:00
  • @josi513 That wasn't my question. My question is, how do you know there was no urgent request to make this change? You consider it nonsense, I would consider it nonsense, but I have been ordered to do apparent nonsense by managers so many times in my career that I just want to make sure you are sure that this is actually your colleagues own judgement call. Did you ask him? – nvoigt Apr 2 at 7:51
9

Well, there are some options here.

  1. Deal with it. Unless you're in a flat structure where there aren't leads, etc. the lead developer on the team is the person with the ability to enforce best practices. This doesn't mean you should start doing it yourself. Follow best practices unless told to do otherwise. If it's impacting your PRs, make sure your cover your ass. Conflicts are going go happen anyways, so rebase from master if you're concerned.
  2. Talk to them and be curious as to why they're pushing directly to master, etc. Keep asking questions. You can make note that you're getting a lot of conflicts (but you'll get these anyways if their changes are merged first).
  3. Talk to your senior developer about this. Issue here is that the chances are that they know, and don't care enough to do anything about it.
|improve this answer
  • 2
    I think 2 is the best approach, they may be doing it out of habit without realizing – Roberto Torres Apr 2 at 17:23
  • 2
    #2 is a good approach. In situations like this, it's always best to let curiosity (rather than frustration) drive your actions. That's easy to say and harder to do, of course. – O. Jones Apr 3 at 11:30
  • 1
    @O.Jones Oh man, I 100% agree. It takes strength of character to remain curious during the process as well. I often (and have personally struggled with) keeping it up past the first few questions before finding myself in a frustrating position. That being said, I have observed my betters cut through issues with it like a hot knife in butter. It's a skill to be mastered. – Malisbad Apr 4 at 0:05
2

Here’s what my place does: After a new release is given to customers from a development branch that has been tested and closed for changes, we then merge the whole development branch into master. This is expected to have zero conflicts. So if someone “checks nonsense changes into master”, I’d expect heads to roll.

|improve this answer

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