Why are some features in Pipelines not available in Gitflow?
Some Pipeline features are not yet available in Gitflow. We are actively working towards parity. Current gaps include:
Continuous delivery rules
Long-term projects
Linking ServiceNow change records to production releases
Automatic creation of sync PRs
In-app DevOps performance (DORA) metrics
Can I use "Squash" or "Rebase" merge methods with Gitflow pipelines?
Short answer is no, you can't.
Depending on your Version Control System (VCS), you may have the option to utilise different methods to merge your changes into target branches (source branches of your CI jobs).
Usually these are "merge commit", "squash" and "rebase" as explained in the following GitHub article about pull request merges.
Using "squash" or "rebase" merges can cause issues over time particularly between long-lived branches like develop, release, and main.
In Gitflow, changes flow through a sequence of merges (e.g. develop → release → main, and sometimes back from main → develop). These merges rely on commit history to determine what has already been integrated.
Using "squash" will combine (squash) your pull request's commits into a single new commit hash before layering that onto your target branch. This breaks Git’s ability to track shared history between branches. As a result, future merges (e.g. merging main back into develop after a hotfix) may select an incorrect common ancestor, leading to unexpected merge conflicts, even when the underlying changes are identical.
And "rebase" will actually create new commits to layer onto the target and you wouldn't be able to tell a feature merged in at a particular point in time. This article from Atlassian goes into more detail on rebasing: Merging vs. rebasing.
Can I transition from an expanded branching pipeline to a Gitflow one?
Yes. However, the 2 pipeline styles are fundamentally different, and there is no transition wizard or capability in Gearset to do this for the customers. However, depending on the existing and target setup, there could be some shortcuts.
Considerations
If possible, this should really be treated as a sizeable way-of-working shift, that would be cleaner to take place during a code freeze when there’s not tons of WIP to account for, so promoting all work through to main/production and completely synchronizing everywhere else would be the smoothest.
If this isn’t possible, there are a few considerations though:
Any existing branches across your current pipeline (that will be used in the new gitflow pipeline) will still showcase on existing branches, e.g the ‘develop’ and ‘main’ CI jobs if you’re reusing them, but the propagation/synchronization/feature branch deletion needs to be considered
Any branches and CI jobs that align to specific environments (UAT, Staging etc) will not be needed, and can be archived accordingly
Any
gs-pipeline/branches will no longer be required, so should be cleaned up in your existing repository, and merged for production.
Steps
Configure the new Gitflow pipeline as per here, making sure to consider if you’re going to be creating a new main/integration branch, or leveraging existing ones
If there’s an existing single CI job that acts as your ‘integration’ (develop) stage, as outlined here, that CI job could be reused and added into your new Gitflow pipeline, in accordance with the rules stated around the integration branch name.
If there’s an existing single CI job that acts as your ‘production’ (main) final stage, as outlined here, that CI job could be reused and added into your new Gitflow pipeline