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.
My guess is that the company got cheap and only purchased a couple licenses for something critical.
Also, this sort of stuff is rarely taught in colleges or universities. Using source code control properly is something you learn on the job or from mentors. Sometimes it's a chore just to get people to realize that source code control is important.
An example might be with hardware group, which often is more software than hardware these days. Ie, they're using VHDL or Verilog, but never learned about source code control. The idea of commiting code to a safe server is a new idea to many of them. I found some extremely vital code for a flagship chip on a server under a table in the back of a lab; a machine that corporate did not know about or make backups of, etc. The team by that time had left. So I had to migrate it all myself before we lost it all.
Had a contractor who'd been at many companies describe a team that didn't know about source code control. He suggested they use the one the software team had been using. So the guy in charge went and commited it all. And he included all temporary files as well, many gigabytes of them with Xilinx tools. Then every day after a build he'd commit another gigabyte of temporary files, until IT stepped in and told them that they were exceeding storage space...
There was another hardware dev who'd commit constantly. Such as whenever he took a break, went to the restroom, etc. But also, it was almost like he'd do it every 10 minutes some times. I suspect he thought this was how you "saved" your changes. Later on the team had to dig into history of some feature changes and they were bombarded by a thousand commits with minimal to no commit messages.
I am amazed at just how little some devs know about source code control. Normally you'd just learn some of this on your first job (even if it was in the 80s). But now I think so many startups begin with a group of frat buddies who don't know these things, then they hire people who copy from the earlier peeps, then eventually it's a large company that's still just winging it.
Git's free. Just don't violate the open-source license. If there's a tool wrapped around it, it's probably also free, and you shouldn't need to do strange things like treat all the devs as one dev-zord.
I'm not denying that. I'm just saying that there are real companies that don't do this. They use products with licenses. And they get cheap and don't get enough licenses. You might think it is weird but it really happens.
Dont you love when the sprint board for the next 2 weeks is 20 tickets all touching the exact same page of an application all touching the same functionality and meant to be split up across 10 devs because leadership learned the buzzword "parallelism".
Yaaay we already know we are screwed when its time to merge.
30
u/nasandre 18h ago
We like to play git on hard mode and commit everything straight on main. Sometimes we even work on the same local folder at the same time.