A "feature branch" means something much different to my teams. A feature branch for us is a short-life topic branch, and typically for one use case, kanban card, etc.
We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc.
We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of multiple reasons:
1. A topic branch gives good code isolation for distributed development: I can share a topic branch with you, directly, without needing to merge to master.
2. A topic branch makes it really easy to do many kinds of popular git workflows; this includes many popular CI servers, git automation scripts, git aliases, etc.
3. A topic branch is great for integrating early and often into code reviews, and also with master. For example, we use a feature branch that uses feature toggles, and we can do CI/CD to propose changes to master as often as we want, and we can rebase the topic branch as often as we want. We can choose whether a repo will prefer merge, or rebase, or rebase with preserve, and between elided linear history or real graph history.
4. We favor automatic integration, meaning when we push a topic branch, and the reviews are all good, and the tests are all green, then the CI/CD does an automatic integration process, including an automatic deploy. When the topic is integrated, then the topic branch is deletable.
5. Finally, I've tried the "TBD just merge to master" approach with multiple teams, and inevitably it turns out to be significantly harder and more complex to coordinate, especially at speed, scale, and with more stakeholders.
If you're interested in git, you can see some of the git alias topic branch commands that we use:
All teams I've worked for in the last few years basically did this.
Although we never distinguished between features/topics explicitly, the proces would be the same.
Having one branch per story is just very simple from a management perspective; it aligns user requirements, graphics design, development, code review and deployment into one trackable unit.
Stories are never too large so in practice code branches don't exist for too long, a couple of days usually. If two or more developers work on the same story they'll use the same branch. If two stories are code-wise interdependent they'll reuse each other's branches as they see fit.
How do you name your topic branches? We previously used a bug tracking system in parallel with this same process, so we used ticket numbers as the prefix for branch names. On our current project, we are using Trello as the driving tool which obviously doesn't have the simple numbers so we end up with odd inscrutable branch names and I haven't yet found a good way to normalize them.
Each team is free to choose their own way. Personally I like topic branch names that are read like a present tense imperative commit messages e.g. add_feature_for_user_to_like_a_post, fix_relation_between_a user_and_a_post, optimize_search_speed_for_a_user_to_see_posts. The names are long and meaningful. Autocompletion makes these work well.
Do you "force" push sometimes to this kind of feature branch you describe?
I often `push -f` to my own feature branches, I think it's manageable also in a shared branch, but less easily
We use short-life topic branches for each feature, each bug fix, each infrastructure-as-code change, each documentation update, etc.
We prefer short-life topic branches vs. committing to the `master` branch (or equivalent `develop` branch) because of multiple reasons:
1. A topic branch gives good code isolation for distributed development: I can share a topic branch with you, directly, without needing to merge to master.
2. A topic branch makes it really easy to do many kinds of popular git workflows; this includes many popular CI servers, git automation scripts, git aliases, etc.
3. A topic branch is great for integrating early and often into code reviews, and also with master. For example, we use a feature branch that uses feature toggles, and we can do CI/CD to propose changes to master as often as we want, and we can rebase the topic branch as often as we want. We can choose whether a repo will prefer merge, or rebase, or rebase with preserve, and between elided linear history or real graph history.
4. We favor automatic integration, meaning when we push a topic branch, and the reviews are all good, and the tests are all green, then the CI/CD does an automatic integration process, including an automatic deploy. When the topic is integrated, then the topic branch is deletable.
5. Finally, I've tried the "TBD just merge to master" approach with multiple teams, and inevitably it turns out to be significantly harder and more complex to coordinate, especially at speed, scale, and with more stakeholders.
If you're interested in git, you can see some of the git alias topic branch commands that we use:
https://github.com/GitAlias/gitalias/blob/master/gitalias.tx...