Define who reviews a change and when it may enter the shared branch. Short task branches, automated tests and a protected main branch provide a useful starting workflow for many small teams. Choose merge or rebase with the effect on other people’s history in mind.
This article assumes a remote repository and a service with Pull Request or Merge Request functionality. PR is a server function that requests changes to be reviewed and merged, and is different from Git’s own commit object. Even though the name and setting screen are different for each product, the content to be judged is similar.
Git · GitOps All Series · 11 / 24
On this page
Send small changes to short branches
git switch main
git pull --ff-only
git switch -c fix/empty-name
# Edit files and run tests.
git add greeting.py test_greeting.py
git diff --staged
git commit -m "Reject blank names in greeting"
git push -u origin fix/empty-nameOnly files that have actually been modified are added. If you don’t have a test file yet, prepare the example in Part 17 first or exclude it from being changed. Select the base branch main on your server and create a PR, listing the issue, reason for modification, and tests you ran.
The size of a good PR is in units that reviewers can understand. If you change the permission model with a small number of files, the review may be significant. Separating format changes from functional changes makes it easier to find the intended changes.
Criteria for choosing trunk-based and Gitflow
| flow | the right situation | costs to manage |
|---|---|---|
| short branch + main | Services that are frequently integrated and distributed | Small changes, quick tests, feature flags |
| Gitflow series | Parallel supported versions and explicit release preparation | Merge management between develop·release·hotfix |
| release branch | Only some versions are maintained | Backpropagation and backport management of modifications |
Trunk-based development is an approach that frequently integrates changes into a baseline. It is not a concept that conflicts with writing PR. Conversely, just because you created a release branch does not mean that you have applied the entire Gitflow. Look first at your deployment cycle, number of supported versions, and your team’s testing capabilities.
rebase stacks changes back onto the new parent
If main changes while your personal working branch is open, you can move commits you haven’t yet shared up the base. The below will run on your current working branch.
git status --porcelain
git fetch origin
git branch safety/before-rebase
git rebase origin/main
# If a conflict occurs: edit, git add, then git rebase --continue.
# To cancel an in-progress rebase: git rebase --abort.Rebase creates a new commit with a different parent. If someone else is already working on that branch, they will need to coordinate a change that will remove the existing hash. If your team doesn’t allow rebasing of shared branches, merge will incorporate the latest baseline.
If I need to rewrite a remote working branch I own by consensus, I can check with --force-with-lease that the server is where I expect it to be. Although it has more conditions than the general --force, it does not necessarily protect other people’s work. You should also consider environments where tracking references change due to background fetch.
# Only for your agreed, rewritable feature branch. Never use on shared main.
git push --force-with-lease origin HEAD:fix/empty-nameWhen taking a fix to the maintenance branch
You can cherry-pick if you only want to send specific bug fixes to an older version in operation. Applies changes from the base commit as a new commit to the current branch. Below is an example where there is an already existing maintenance branch and a single modification commit that has been reviewed.
git switch release/1.x
# Replace FIX_COMMIT with the reviewed fix commit ID.
git cherry-pick -x FIX_COMMIT-x leaves the original commit information in the message. Check the dependencies and tests of the new branch and handle any conflicts with --continue or --abort. If one commit depends on several previous changes, importing only that one may not work. Check the coverage of git cherry-pick.
Create rules to be followed on the server
Limit pushes directly to main, and leave required reviews and CI success as merge conditions. Even before CI was introduced, mandating a test name that does not exist can block all PRs, so check and specify the test name that actually succeeded. Administrator exceptions and emergency change paths are also logged.
Approved PRs also need to be rechecked against the base branch after the merge. Even if two PRs each succeed in the test, the combined combination may fail. As the scale grows, you can consider integrated checks such as merge queue.
For Git’s rewrite operation, refer to git rebase, and for server limitations, refer to Gitea protected branch guide. Rather than memorizing one branch strategy, your branch strategy should be able to describe how changes come into operations.
Previous · [Git and GitOps 10] Work with Remotes: clone, fetch, pull and push · Next · [Git and GitOps 12] Use Tags and Releases to Identify a Deployment · Series list and example files
.jpg){kind=link}