re: why branching on git is wrong VIEW POST

re: After your stuff works again, you do the rebase again and repeat this until there is nothing to fix, and then you make the pull request and let oth...

Do you realise, that you have much bigger problems with your development process and colleagues, than how you use your source control system? Seems like a big mess and here is why:

  1. You need features from other incomplete branches, i.e. you are not planning ahead correctly and your branch lifespan is too high

  2. Your colleagues can't properly use git and branches just like you (why am I not surprised?)

  3. You need better tools to merge code maybe (can I suggest Araxis Merge?)

  4. Everyone works on their own and nobody knows what the other is doing, then you are "surprised" of the outcome and you have to stitch it all together.

Don't be offended by my words - I intentionally wrote it this way, so you can pause and think a bit.

Exactly my thinking. They have serious issues in how they work, I also bet it's not a team that one enjoys working with, and they just blame it on "the system".
I'm pretty sure their task breakdown is also wrong and they start working on huge epics in one branch without properly splitting the work. Probably their tech isn't allowing it.

Chalking things up to poor communication is like saying that the key to standardizing deployments is better documentation. Its true that a wiki can work, but why leave it up to human error when there is a better solution which is automation? Automation is essentially working documentation so you were right if you said the answer is documentation, however, I would give a better grade to the person that answered 'working documentation' over 'documentation'.

The problem we are talking about here is having people and teams come out of sync that can result in integration issues later down the road. Better communication is the right answer. To me, trunk based development essentially means 'working communication'.

code of conduct - report abuse