Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
Usually people comment because they disagree. In this case I'm posting because this is heterodoxy while also the way I feel about feature branches. The whole idea of a version control system is to allow the team to work together. This means being synchronized in terms of the code base. Having people run off on their own branches and mark stories as complete based on a branch creates a problem with knowing what is actually included in the main code base. I understand why Git and feature branches might make sense in highly distributed or open source teams where features are highly atomic and developers work more independently, but in co-located teams working closely with one another feature branches lead to endless discussions about which features are actually merged, and conflicts over merges. Evolution means small regular change. Branching is essentially a fork which will require healing.
I think the title is a bit misleading. With Trunk Based Development you still have branches but they are short-lived and intended to be integrated very quickly into the main line of development, as opposed to the traditional feature branches that usual span for weeks or months until a feature is "complete".
"I think the title is a bit misleading" Indeed. I've updated the title and added mentions of short lived branches where appropriate. Hopefully it's clearer now.
At least the original title brought in a lot of interesting discussion :)
Marking an issue/story/req complete in a branch is also a bad workflow. They should not be marked as complete until they are merged into the master branch, or whatever the developing branch is.
GitHub even has this feature automated. If you mark branches fixing issues, those issues will be closed once they are merged.
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.
Usually people comment because they disagree. In this case I'm posting because this is heterodoxy while also the way I feel about feature branches. The whole idea of a version control system is to allow the team to work together. This means being synchronized in terms of the code base. Having people run off on their own branches and mark stories as complete based on a branch creates a problem with knowing what is actually included in the main code base. I understand why Git and feature branches might make sense in highly distributed or open source teams where features are highly atomic and developers work more independently, but in co-located teams working closely with one another feature branches lead to endless discussions about which features are actually merged, and conflicts over merges. Evolution means small regular change. Branching is essentially a fork which will require healing.
I think the title is a bit misleading. With Trunk Based Development you still have branches but they are short-lived and intended to be integrated very quickly into the main line of development, as opposed to the traditional feature branches that usual span for weeks or months until a feature is "complete".
"I think the title is a bit misleading" Indeed. I've updated the title and added mentions of short lived branches where appropriate. Hopefully it's clearer now.
At least the original title brought in a lot of interesting discussion :)
Marking an issue/story/req complete in a branch is also a bad workflow. They should not be marked as complete until they are merged into the master branch, or whatever the developing branch is.
GitHub even has this feature automated. If you mark branches fixing issues, those issues will be closed once they are merged.