Where to put technical updates in git branching flow?

Question

From time to time you need to do technical updates, like:

• Update versions of your dependencies
• Update the version of your parent POM, you build tool etc.

Leave out those updates that have a firm deadline or directly induced by business needs. I mean the updates that are not urgent, but should be done every couple of months.

How do you handle them in git?

• Do you write an issue/ticket for yourself and handle them like any other feature branch?
• Do you "hide" them in other feature branches, so that maybe the first step of a feature is to update dependencies?
• Do you have special branches/commits for them, e.g. after a release is done, an update branch is created to update the versions of dependencies?

Answer 1

Feature branches are a general term that means "not the main branch" (or master). Don't get too complicated with this. Create a branch just to upgrade that dependency. This should capture any additional code or documentation changes necessary during the upgrade. Breaking changes should be noted in the commit message. The commit message should include:

• Name of the dependency or library being updated
• Version of the dependency or library
• Notes about other code changes, especially breaking changes
• References to external work items if appropriate

For example, updating Selenium, which is used for automated testing, might have a commit message like this:

Upgrade Selenium NuGet package to v4.1.0

- Added DotNetSeleniumExtras package to support ExpectedConditions class
- Refactored page models to eliminate dependency on PageFactory
- Breaking changes to how screenshots are captured during failed tests

Task: #12345

Whether you create a work item, story or task for this is up to you and your team. The key here is to communicate this change. Updates to dependencies can have large impacts when breaking changes are necessary, so coordinate with your team.

The smaller the change, the better. This makes updates easier to incorporate into existing work. Failing tests or bugs can be more easily tracked down to the upgrade if it can be encapsulated in a single branch, and a single commit.

Moving or renaming files as a result of the upgrade should be done in the same branch, but done as separate commits in order to preserve file history.

Work with your team on when to make this change, and to identify which branch the change gets merged into. Unless you have a compelling reason, I recommend merging it into your main branch, and making sure automated and manual tests are passing before merging it into other branches.

Answer 2

Ticket, like everything else. Also serves to account for time spent doing this and provides visibility to the team.