A branch names a line of work so a change can be developed while keeping the starting state identifiable. Use a small documentation edit to create, switch and merge branches. Inspect the graph to distinguish a fast-forward update from a merge commit.
gitops-demo in Part 5 assumes that main exists and the work tree is clean. If there are any unfinished changes, commit them first or store them separately. Switching branches also changes files, so it doesn’t override ongoing edits.
Git · GitOps All Series · 08 / 24
On this page
1. Check the criteria and create a working branch
git switch main
git status --short --branch
git switch -c feature/readme-usage
printf '\nUsage: run greeting.py with Python 3.\n' >> README.md
git diff -- README.md
git add README.md
git commit -m "Document how to run the greeting example"
git log --oneline --graph --decorate --all -8switch -c creates a branch and moves there. You can use names like feature/, fix/, docs/, etc., which are easier for your team to identify, but Git does not assign any special deployment meaning to those prefixes. If an automation uses a name as a condition, it becomes a team rule.
2. Accept changes in main
git switch main
git merge --ff-only feature/readme-usage
git status --short --branch
git log --oneline --graph --decorate --all -8If there have been no other commits in main in the meantime, fast-forward is possible. This method moves the pointer of main to the location of the feature branch and does not create a new merge commit. --ff-only means stop if this move is not possible.
Failure doesn’t mean the change is ruined. This could be a sign that the two branches have diverged. Confirm and merge the merge or rebase strategy decided by the team. Conflict resolution will be practiced separately in the next section.
When to leave a merge record
To preserve the confluence of functional units in history, you can create a merge commit with --no-ff. Running the same command again on a branch that was already merged earlier will not result in a new example, so a separate, smaller branch is used below.
git switch -c docs/contributing
printf '\nContributions use short-lived branches.\n' >> README.md
git add README.md
git commit -m "Add contribution note"
git switch main
git merge --no-ff docs/contributing -m "Merge contribution documentation"
git log --oneline --graph --decorate -8Here we have a commit with two parents. The graph shows confluence points, but there is also the cost of increasing the number of commits. In contrast, a squash merge bundles multiple changes from a working branch into one new commit and writes them to the base branch. This is distinguished from the method of leaving the ancestor relationships of the original commits intact.
| way | remaining form | Reason for choosing |
|---|---|---|
| fast-forward | straight history | Simply join when there is no baseline change after branching |
| merge commit | Confluence and Parental Relationships | Preserve merge paths by feature |
| squash | One change grouped together | Organize review units into a single commit |
| rebase | New commit above new parent | Organize unshared work history according to criteria |
If you need to change branches urgently while working
If you are not ready to commit yet but need to handle other changes first, you can use stash to store your changes for a while. -u includes untracked files, but does not include files excluded by .gitignore. It is not used as a backup for long-term storage or sharing with other PCs.
git stash push -u -m "Pause README work"
git stash list
# After returning to the original branch:
git stash apply 'stash@{0}'
git statusapply applies leaving archived items behind. After checking the contents and leaving the necessary commits, you can delete the entry with git stash drop 'stash@{0}'. I don’t think that just because you archive it, it automatically merges with other edits, as they may conflict during application. For operation, refer to git stash.
When to delete merged branches
git branch --merged main
git branch -d feature/readme-usage
git branch -d docs/contributing-d checks for merge and deletes. Deleting the branch name does not remove the commits referenced by main. Deleting a remote branch on a server is a separate command and requires checking to see if it is being used by others before proceeding.
Branches merged by squash or rebase may be rejected by -d because the original commit is not an ancestor of main. At this time, rather than simply repeating -D, check the review, merge results, and commits to leave. For real team work, it’s better to use a combination of protected branches and review rules on the server.
For the internal structure of the branch, refer to Git Branches in a Nutshell, and for merge options, refer to git merge.
Previous · [Git and GitOps 07] Choose restore, reset or revert Before Undoing Changes · Next · [Git and GitOps 09] Resolve Conflicts with the Common Ancestor and a Three-Way Merge · Series list and example files
.jpg){kind=link}