what does feature branch contain

Question

I tried to google the answers and got articles all about branching models and how to create feature branches, which are not the answers I am looking for. I know I might not use the proper key words to search the answers, the guide about the key words for the relevant answers would also helpful.

My question has two parts:

1. When we are developing features for a project and these features could be used for other projects in the future, we want to source control each feature so that other projects can just take whatever features needed for the specific feature(s) in the specific project. Is this what feature branch model can help achieve?

2. As a feature is just part of a complete program, which can be run and tested, should a feature branch contain the whole program, or just the source files for that specific feature?

Thanks! Crane

Answer 1

I'm going to put this here, but the question will likely be closed as opinionated. There's a whole Software Development Life Cycle that needs to be understood here.

The concept of a feature branch is part of the gitflow workflow.

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Let's say you have a bunch of projects, each project has a ticket in Jira or a similar program. Each ticket outlines a feature for your project. The feature can be a small change or a big change. A big ticket (an Epic) might be broken down into a collection of smaller tickets.

So for each ticket, you create a feature branch. If the ticket is PRJ-1234, then create a new branch off of the develop or main branch (depending on your process). Name that branch feature/PRJ-1234.

You create a pull request from that feature branch. Have it reviewed, then it gets merged to your develop branch. You can keep using that feature branch to address bugs during the development time period. Once that code has been merged and it's made ready to deploy to production, you can delete that feature branch since the code is now part of the main code base.

So if you have 8 tickets, then the dev team should have had 8 feature branches. Those branches should generally only exist for the life of that sprint (release). You don't reuse feature branches for other tickets.

Answer 2

You need to play with VCS first, some of the questions will be resolved by themselves. E.g. branches contain the source code of the whole project with some additional changes. They can't contain just the changes.

There are several ways feature branches are used. It's easier to say what feature branches are NOT:

• They are not release or hotfix branches where people could keep changes for a particular release
• They are not a development branch. This kind of branches are sometimes kept when people want to separate out 2 main branches - one containing latest stable version, and one that contains current development (not necessarily stable).
• They are not trunk (aka master, main). This branch can either be used same way as development or it could be the "latest stable" branch.

Unless I forgot something, the rest would be feature branches. 2 primary ways they are used:

1. To introduce a new feature. In this case such branch can contain quite a lot of changes.
2. To implement a part of the feature or any kind of change (could be a tiny change). While it may look silly that we call them feature branches, that's the name we're stuck with. Such branches are created to temporarily stash changes and/or for technical reasons - to be able to create a code review (using pull/merge requests)

These days since Continuous Integration is trending, we're supposed to use approach #2. We don't like keeping long-running branches. Look up "trunk-based development" for more details.

PS: you will often come across GitFlow as it used to be a popular approach. It's not an outdated and overly complicated strategy and shouldn't be used anymore (actually it was always against the principles of Continuous Integration, but people didn't know about it :)). Even its author doesn't recommend it anymore. PPS: In case of trunk-based development, we can do away with the feature branches completely if we use micro code reviews with Gerrit. Instead of creating pull/merge requests with GitHub, GitLab and others.