Skip to main content

Long Lived Feature Branches

In some situations, it may not be possible to strictly follow the Trunk Based Development (TBD) principles outlined in our Branching Strategy, and a need may arise to create a longer-lived feature branch.

Examples of such a situation we have encountered in the past include:

  • Annual code/feature freeze during the Spring Carnival, where new work cannot be deployed to UAT for most of our core backend repositories unless it is specifically a hotfix for production
  • Products with not-yet-stable backend, microfrontend or GraphQL features which RN depends on, e.g. @technology/ui-graphql pointing to an alpha branch, which could not be safely merged to main yet, or changes to the GQL server e.g. resolvers that aren't yet deployed

In these cases, it can be ok to create a long-lived feature branch, after the particular case has been discussed with and approved by:

  • the Native Apps Platform team
  • your pod's Delivery Manager
  • a Staff Engineer in the React Native space
  • your pod's Engineering Manager

Using a Long-Lived Feature Branch​

Using a long-lived feature branch differs from our normal TBD process, but you'll still use TBD for your individual Merge Requests. For this example, lets assume we have created a feature branch called feature/some-product

The Feature Branch​

  • We create feature/some-product from the main branch
  • Unlike the normal TBD process, we DO NOT rebase feature/some-product with the latest changes on main
  • If we did rebase feature/some-product, all of the Working Branches (outlined below) will become irreparably out of sync with the target branch when it comes time to create a merge request
  • Instead of rebasing, you will simply merge main into the feature/some-product, e.g. git pull origin main
  • After merging main into feature/some-product, push the branch to the remote
  • After pushing the branch to the remote, please inform your fellow developers who are working from feature/some-product that they need to rebase their local working branches and any open MRs against feature/some-product (as outlined below)
  • You should merge main into feature/some-product at least once every few days, due to the volume of working going into that branch on a daily basis, so that your feature branch does not become quickly out of sync.

Working Branches​

  • Instead of creating your working branches from main, you'll create them from feature/some-product
  • Instead of targeting your merge requests to main, you'll target them to feature/some-product
  • You will still need to rebase your local branches regularly, but again, rather than rebasing from main you'll do it from feature/some-product, e.g. git pull origin feature/some-product --rebase

Pointing the feature branch at stackz or dev-cluster​

Follow the docs here to point your feature branch at the stackz or dev-cluster environment which is hosting your BE or GQL changes that cannot be deployed to UAT.

When ready to merge into main​

Get ready for a really fun time.

Depending on how long feature/some-product has been running, and how wide-ranging the changes are throughout the codebase when compared to main, it can be arduous to get the branch merged back into main due to the high potential for conflicts while other teams continue to merge code to main via the normal TBD process.

Basically, you will:

  • Advise your team members who have been working from the feature/some-product branch that no more MRs are to be created pointing to this branch - essentially a momentary "code freeze" for this feature
  • Create an MR just as you would for any normal branch going to main, get approvals, and merge it in
  • Reminder - if there are conflicts, DO NOT REBASE
  • Resolve any conflicts locally by running git pull origin main into feature/some-product and commit the conflict resolution as part of the merge commit
  • If new conflicts occur before you can get it merged, you need to repeat the above process
  • Once you get approvals and get the branch merged, please put a notification message in #chapter-native-apps in Slack, so that other teams can rebase from main to get up to date with all your new commits