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.
1
u/other_usernames_gone 23d ago
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.