Naming each change of code is wasted effort and the more frequently you commit changes the worse it gets. This becomes apparent when you are changing a couple of lines at a time and pushing multiple times a minute.
If you are pair programming the review is already done and the PR isn't necessary at all. Also, true pairing on one pc doesn't make it easy to have both people logged in for creating/approving PRs.
As the size of changes increases so does risk which is why long lived branches are not a good solution for risk management.
I sure hope you provide a commit message which names your changes, no matter how frequently you commit. I also hope those changes are complete (compile, expected to pass testing) especially when being pushed.
I'm going to combine your claim of 'multiple times a minute' with other statements of 300 devs. If 300 devs are pushing changes multiple times a minute, the amount of time rebaseing to get the latest so you can push seems like a waste and is exactly what "racing other developers to merge code" is.
Here is the thing about git, you can't do any work without making a branch. A repo clone finishes by landing you in a branch off the remote repository.
The issues you discrbe with branches I find happen without. Rather then committing code, people will sit on a working directory. The real hard part is getting people to define a completed change and committing it.
Is this just an "other" people issue? No, as I work on one thing I'll usually come across a tweak, or be unsure if I should do x or y.
Then you bring up feature toggle, so rather than mitigating risk by not changing the code in the first place you hide it in an if condition and pretend that you have "integrated" with other people's work.
I'm quality assurance by trade and while I support this approach in reasonable conditions, I'm well aware you can't isolate all changes in this manner. I believe that keeping a codebase dependacy updated and removing cruft is crucial to a quality release. Feature flags get you only so far.
Yes, every commit has a relevant message. Only so far as can be done locally with unit testing, even then this isn't that important.
No reasonable team contains 300 devs and if all of your devs are working on one repository then that is an organisational issue. There is 0 extra work rebasing as it is just done the same time as pushing.
Nobody sits on working directories, they commit many times a day every day and we don't define completed changes.
That isn't pretending, that is actually integrating since it is in a shared state with the latest version all in one place.
It is not integrated until all the features are turned on, with feature flags you always need to keep in mind you have an additional layer of logic which control the functionality of your application.
If the development team is already committing and pushing often that is a great accomplishment. Though I'm concerned that you aren't completing changes before pushing.
Your push does not perform a rebase, git will reject if you are not up to date. If you can't get up-to-date because other devs are pushing their single line change git will continue rejecting your push.
It is great that everyone gets involved in your team to fix things even if they didn't cause it. I'm sure most try to address issues they cause rather than leaving it for another. I just personally know I don't trust myself to put others members through my mistakes.
To say that creating and merging a branch is "work" completely misses where time is spent.
Naming the branch - what are you working on?
Code review - review takes no time if you already pair programmed. A Pull Request/Merg commit provides a collection of related work.
Long lived branches create additional maintenance, and sometimes that is reasonable for risk management.
Git Branch Strategy
Jesse Phillips ・ Jan 13 '20 ・ 2 min read
Naming each change of code is wasted effort and the more frequently you commit changes the worse it gets. This becomes apparent when you are changing a couple of lines at a time and pushing multiple times a minute.
If you are pair programming the review is already done and the PR isn't necessary at all. Also, true pairing on one pc doesn't make it easy to have both people logged in for creating/approving PRs.
As the size of changes increases so does risk which is why long lived branches are not a good solution for risk management.
I sure hope you provide a commit message which names your changes, no matter how frequently you commit. I also hope those changes are complete (compile, expected to pass testing) especially when being pushed.
I'm going to combine your claim of 'multiple times a minute' with other statements of 300 devs. If 300 devs are pushing changes multiple times a minute, the amount of time rebaseing to get the latest so you can push seems like a waste and is exactly what "racing other developers to merge code" is.
Here is the thing about git, you can't do any work without making a branch. A repo clone finishes by landing you in a branch off the remote repository.
The issues you discrbe with branches I find happen without. Rather then committing code, people will sit on a working directory. The real hard part is getting people to define a completed change and committing it.
Is this just an "other" people issue? No, as I work on one thing I'll usually come across a tweak, or be unsure if I should do x or y.
Then you bring up feature toggle, so rather than mitigating risk by not changing the code in the first place you hide it in an if condition and pretend that you have "integrated" with other people's work.
I'm quality assurance by trade and while I support this approach in reasonable conditions, I'm well aware you can't isolate all changes in this manner. I believe that keeping a codebase dependacy updated and removing cruft is crucial to a quality release. Feature flags get you only so far.
Yes, every commit has a relevant message. Only so far as can be done locally with unit testing, even then this isn't that important.
No reasonable team contains 300 devs and if all of your devs are working on one repository then that is an organisational issue. There is 0 extra work rebasing as it is just done the same time as pushing.
Nobody sits on working directories, they commit many times a day every day and we don't define completed changes.
That isn't pretending, that is actually integrating since it is in a shared state with the latest version all in one place.
It is not integrated until all the features are turned on, with feature flags you always need to keep in mind you have an additional layer of logic which control the functionality of your application.
If the development team is already committing and pushing often that is a great accomplishment. Though I'm concerned that you aren't completing changes before pushing.
Your push does not perform a rebase, git will reject if you are not up to date. If you can't get up-to-date because other devs are pushing their single line change git will continue rejecting your push.
It is great that everyone gets involved in your team to fix things even if they didn't cause it. I'm sure most try to address issues they cause rather than leaving it for another. I just personally know I don't trust myself to put others members through my mistakes.
Integration of code isn't related to configuration and every piece of software has features turned on and off.
That's why you pull changes in as part of pushing changes. Rebasing never makes sense unless you want to rewrite history.
You wouldn't have to. But if you were a junior and a senior wanted to help to speed things up it makes sense.