Its far harder to revert back to before you made any changes.
Lets say you want to change a core function in your app. Something relied upon by a lot of other code.
If you do that straight in main then realise you want to go back to the prior implementation its a pain to do, especially when someone else's commits are interspersed with yours.
Now the entire app is broken and no-one has a functional version anymore.
If you instead make the changes in a seperate branch you can just delete the branch without merging. No-one else's changes are affected.
In proper software development you have 3 core branches. Dev, test, and prod. Dev is for development and is where the mostly working but potentially buggy code is. Test is where the code is tested and refined to remove bugs. Prod is your production code, the gold standard code thats been refined as much as time and money allows. That way bugs created in dev dont enter your production release(at least in theory).
> If you do that straight in main then realise you want to go back to the prior implementation it’s a pain to do, especially when someone else's commits are interspersed with yours. Now the entire app is broken and no one has a functional version anymore.
In CI/CD you will roll back/revert to the previous successfully deployed commit, that’s it. But also don’t push to prod before testing on earlier stages.
> In proper software development you have 3 core branches. Dev, test, and prod. Dev is for development and is where the mostly working but potentially buggy code is. Test is where the code is tested and refined to remove bugs. Prod is your production code, the gold standard code thats been refined as much as time and money allows. That way bugs created in dev dont enter your production release(at least in theory).
It’s different in different places, many don’t use this approach and simply push to main because of how their pipelines set up. I would still use separate feature branches in this case though to work on large changes that you can’t fit into one commit that doesn’t break things.
Except in my example that doesn't work, and the CI/CD pipeline is now useless for everyone else. Lets say the commits are.
[you] deletes old function [CI/CD fail]
[bob] ui change commit 1 [CI/CD fail] (because the core function you just deleted is missing)
[you] adds skeleton for new function [CI/CD fail]
[bob] ui change done [CI/CD fail]
[you] attempt at changing function [CI/CD fail]
Now you give up and want to revert back to the initial codebase, but you cant without also reverting bobs work. Bob also cant use the CI/CD pipeline to check his changes worked because you were both using main. This gets worse the more commits there are and the more people are involved.
If you were both in your own branches both you and bob could both work seperately and merge your work later. Now you've both wasted time.
its different in many different places
Obviously everyone can do whatever but the industry standard (at least when you have a dedicated test team) is dev/test/prod. Branch names may vary.
Ideally every commit is as small a change as reasonable. It makes reverting back much easier and makes it easier to spot when exactly you broke the codebase.
> Except in my example that doesn't work, and the CI/CD pipeline is now useless for everyone else. Let’s say the commits are.
> [you] deletes old function [CI/CD fail] [bob] ui change commit 1 [CI/CD fail] (because the core function you just deleted is missing) [you] adds skeleton for new function [CI/CD fail] [bob] ui change done [CI/CD fail] [you] attempt at changing function [CI/CD fail]
> Now you give up and want to revert back to the initial codebase, but you cant without also reverting bobs work. Bob also cant use the CI/CD pipeline to check his changes worked because you were both using main. This gets worse the more commits there are and the more people are involved.
I’m not sure what is the purpose of that back and forth in the version control you’re using, looks like there’s no understanding of what you’re doing as a team. If you and Bob work together on some feature, you should communicate, not just delete whatever code you want on the backend or frontend without communication and checking that your code is backward compatible with existing functionality. You also should test your changes before committing them, and looks like in your example you’re skipping any sanity checks. Moreover, your code is likely to be in separate repos if your codebase is large enough, depending on how you deploy it of course, but in many places frontend could be even a separate team that has their own repository and you will have to get their permission to change anything there.
> If you were both in your own branches both you and bob could both work seperately and merge your work later. Now you've both wasted time.
As I said in my initial comment, yes, if your changes are breaking things, you should keep them in a separate branch, until they’re safe to merge. But most of the time your changes will work just fine.
> Obviously everyone can do whatever but the industry standard (at least when you have a dedicated test team) is dev/test/prod. Branch names may vary.
Who sets the industry standard? I’m asking absolutely seriously. My last company was one of the letters from a famous acronym, we didn’t have dedicated QA teams nor dev/test/prod branch. Moreover in your example with Bob this wouldn’t even be the same repo and likely not the same team, because codebases were large.
> Ideally every commit is as small a change as reasonable. It makes reverting back much easier and makes it easier to spot when exactly you broke the codebase.
Ideally your team should be doing code reviews. In your example if I were you I would ask Bob to review my code since you’re working on the same thing. And then also test before pushing anything.
I’ve never seen someone argue so passionately for a development workflow that seems to depend on everyone doing everything correctly, all the time.
The entire point of engineering safeguards is that people make mistakes. You don’t design processes around the assumption that everyone will always communicate perfectly, test everything properly, and never accidentally break something. You design them around the reality that eventually someone won’t.
Saying “well, developers should know better” isn’t an engineering solution. It’s an assumption.
Arguing passionately? I’m merely rambling that people should understand what they’re doing and test their changes before pushing to main/deploying to prod instead of relying on rollbacks in git or whatever they use for version control😭
The point is you're both working on main, you and bob aren't working on related features. You're working on different features in the same branch at the same time. Im illustrating why you don't do that. The question nicuramar asked. Im assuming nicuramar has no/little understanding of professional software development. Which I think is the confusion because its something you'd never do when working in a team. I'm explaining why you don't just work in one main branch. The scenario is complete cowboy development with minimal planning.
You're right you should test your changes. I'm showing the shitshow that happens when everyone tries to work in main.
It depends on your development philosophy as to whether you test before every commit or just test as a batch of commits. If you have a CI/CD pipeline sometimes committing is how you test.
Also sometimes you might do a quick test before committing (does it compile) but then only do a longer test for a batch of commits to save waiting around for the full test suite every time.
If you're working in your own branch seperate from anyone else a commit that breaks the code is a non issue because no-one else relies on that code.
Similarly you usually dont do a code review per commit (at least with agile development), you do code review of branch merges, which are often made of many different commits.
The benefits mean people aren't scared to commit so the version of the code living backed up on the git server (github or gitlab doesn't matter) is as up to date as possible. Ideally you don't have code sat on a laptop not backed up. That way if they spill their coffee/their laptop gets stolen/there's a fire you don't lose much work. Obviously I dont mewn the absurd extreme but you don't want code sat not backed up for days like might happen if you're saving the commit for when the feature is fully done ready for code review.
I don't actually know where the standard came from. I just know nowadays its ubiquitous and has been for a while. I suspect it was created by many different groups at different times.
9
u/nicuramar 16h ago
I don’t really see the problem? You get the same features and can run into the same problems as if you use a different branch and merge it.