Feature branches are part of the shared repository
Hold on, the definition we are working from says
"developers to integrate code into a shared repository"
Just having a branch in a shared repository does not mean it is 'integrated'. If you have three people push their work branch into a shared repo, the work was not integrated. That is the point of this discussion on Trunk based flow.
There are issues with branches, and feature flags, and rebaseing, and any other collaborative strategy. What we don't want to do is claim our side is doing something it is not.
If you have three people push their work branch into a shared repo, the work was not integrated. That is the point of this discussion on Trunk based flow.
That entirely depends on where and when you run your integration tests. If you run integration tests for each pull request, the work will be integrated with whatever is the current status of the branch they're integrating into.
What we don't want to do is claim our side is doing something it is not.
I definitely don't want to claim my side is doing something it is not. Ofcourse it sucks when your pull requests integration tests fail because another feature was merged into the source branch first and the changes somehow affect your work (usually an indicator someone went out of scope). As far as I understand trunk based development has this same issue. My issue with trunk based development is that when this happens you cannot release or continue development on other features.
work will be integrated with whatever is the current status of the branch they're integrating into
But it is not integrated with other people's work continuously. That is the point. I don't agree that we need to go to that extreme, but if you have long lived feature branches you aren't doing continuous integration (only with one long lived feature branch at a time)
Trunk based dev reduces conflicts because you're more likely working in the latest modified code. With branches people can go days without pulling in mainline. The issue is less with the branching model and more to do with the people.
Even git flow does not endorse long lived branches, but that still happens.
But why do you want to integrate with other peoples work if their work isnt even ready to be integrated into the source branch yet? That doesnt make sense to me.
Trunk based development wants to integrate with each and every commit... won't that discourage people from making regular commits? They'll feel forced to only commit when they're completely finished with a task and are already pretty sure that their code wont break the pipeline.
I'd prefer if people made commits to the feature branch as often as possible even with "unfinished" code and pull in the source branch into the feature branch as often as possible in order to avoid conflicts, rather than postponing their commit because they're scared it won't integrate with the trunk yet.
Because adding new functionality to the code base that isn't used in production isn't that hard and it reduces the time to integrate which reduces complexity and wasted work.
No, it is just a different style of development, accepting that there is no such thing as a complete start to end finished task in one commit. There is also nothing wrong with tests failing in the pipeline. It is more important to improve quickly than guarantee green tests (which can't be done anyway).
That doesn't help integrate their branch into the mainline which is what continuous delivery is. That fear and worry goes away if you try it and have a reasonable work environment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hold on, the definition we are working from says
"developers to integrate code into a shared repository"
Just having a branch in a shared repository does not mean it is 'integrated'. If you have three people push their work branch into a shared repo, the work was not integrated. That is the point of this discussion on Trunk based flow.
There are issues with branches, and feature flags, and rebaseing, and any other collaborative strategy. What we don't want to do is claim our side is doing something it is not.
That entirely depends on where and when you run your integration tests. If you run integration tests for each pull request, the work will be integrated with whatever is the current status of the branch they're integrating into.
I definitely don't want to claim my side is doing something it is not. Ofcourse it sucks when your pull requests integration tests fail because another feature was merged into the source branch first and the changes somehow affect your work (usually an indicator someone went out of scope). As far as I understand trunk based development has this same issue. My issue with trunk based development is that when this happens you cannot release or continue development on other features.
But it is not integrated with other people's work continuously. That is the point. I don't agree that we need to go to that extreme, but if you have long lived feature branches you aren't doing continuous integration (only with one long lived feature branch at a time)
Trunk based dev reduces conflicts because you're more likely working in the latest modified code. With branches people can go days without pulling in mainline. The issue is less with the branching model and more to do with the people.
Even git flow does not endorse long lived branches, but that still happens.
But why do you want to integrate with other peoples work if their work isnt even ready to be integrated into the source branch yet? That doesnt make sense to me.
Trunk based development wants to integrate with each and every commit... won't that discourage people from making regular commits? They'll feel forced to only commit when they're completely finished with a task and are already pretty sure that their code wont break the pipeline.
I'd prefer if people made commits to the feature branch as often as possible even with "unfinished" code and pull in the source branch into the feature branch as often as possible in order to avoid conflicts, rather than postponing their commit because they're scared it won't integrate with the trunk yet.
Because adding new functionality to the code base that isn't used in production isn't that hard and it reduces the time to integrate which reduces complexity and wasted work.
No, it is just a different style of development, accepting that there is no such thing as a complete start to end finished task in one commit. There is also nothing wrong with tests failing in the pipeline. It is more important to improve quickly than guarantee green tests (which can't be done anyway).
That doesn't help integrate their branch into the mainline which is what continuous delivery is. That fear and worry goes away if you try it and have a reasonable work environment.