Introduction to GitLab Flow | GitLab - 0 views
-
GitLab flow as a clearly defined set of best practices. It combines feature-driven development and feature branches with issue tracking.
-
In Git, you add files from the working copy to the staging area. After that, you commit them to your local repo. The third step is pushing to a shared remote repository.
-
branching model
- ...68 more annotations...
-
The biggest problem is that many long-running branches emerge that all contain part of the changes.
-
It is a convention to call your default branch master and to mostly branch from and merge to this.
-
Nowadays, most organizations practice continuous delivery, which means that your default branch can be deployed.
-
Continuous delivery removes the need for hotfix and release branches, including all the ceremony they introduce.
-
Merging everything into the master branch and frequently deploying means you minimize the amount of unreleased code, which is in line with lean and continuous delivery best practices.
-
GitHub flow assumes you can deploy to production every time you merge a feature branch.
-
You can deploy a new version by merging master into the production branch. If you need to know what code is in production, you can just checkout the production branch to see.
-
Production branch
-
Environment branches
-
have an environment that is automatically updated to the master branch.
-
deploy the master branch to staging.
-
To deploy to pre-production, create a merge request from the master branch to the pre-production branch.
-
Go live by merging the pre-production branch into the production branch.
-
Release branches
-
work with release branches if you need to release software to the outside world.
-
each branch contains a minor version
-
After announcing a release branch, only add serious bug fixes to the branch.
-
merge these bug fixes into master, and then cherry-pick them into the release branch.
-
Merging into master and then cherry-picking into release is called an “upstream first” policy
-
Tools such as GitHub and Bitbucket choose the name “pull request” since the first manual action is to pull the feature branch.
-
Tools such as GitLab and others choose the name “merge request” since the final action is to merge the feature branch.
-
If you work on a feature branch for more than a few hours, it is good to share the intermediate result with the rest of the team.
-
the merge request automatically updates when new commits are pushed to the branch.
-
If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.
-
In GitLab, it is common to protect the long-lived branches, e.g., the master branch, so that most developers can’t modify them.
-
if you want to merge into a protected branch, assign your merge request to someone with maintainer permissions.
-
After you merge a feature branch, you should remove it from the source control software.
-
Having a reason for every code change helps to inform the rest of the team and to keep the scope of a feature branch small.
-
If there is no issue yet, create the issue
-
The issue title should describe the desired state of the system.
-
For example, the issue title “As an administrator, I want to remove users without receiving an error” is better than “Admin can’t remove users.”
-
create a branch for the issue from the master branch
-
If you open the merge request but do not assign it to anyone, it is a “Work In Progress” merge request.
-
Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it’s ready.
-
When they press the merge button, GitLab merges the code and creates a merge commit that makes this event easily visible later on.
-
Merge requests always create a merge commit, even when the branch could be merged without one. This merge strategy is called “no fast-forward” in Git.
-
Suppose that a branch is merged but a problem occurs and the issue is reopened. In this case, it is no problem to reuse the same branch name since the first branch was deleted when it was merged.
-
At any time, there is at most one branch for every issue.
-
It is possible that one feature branch solves more than one issue.
-
GitLab closes these issues when the code is merged into the default branch.
-
If you have an issue that spans across multiple repositories, create an issue for each repository and link all issues to a parent issue.
-
use an interactive rebase (rebase -i) to squash multiple commits into one or reorder them.
-
you should never rebase commits you have pushed to a remote server.
-
Rebasing creates new commits for all your changes, which can cause confusion because the same change would have multiple identifiers.
-
if someone has already reviewed your code, rebasing makes it hard to tell what changed since the last review.
-
never rebase commits authored by other people.
-
it is a bad idea to rebase commits that you have already pushed.
-
If you revert a merge commit and then change your mind, revert the revert commit to redo the merge.
-
Often, people avoid merge commits by just using rebase to reorder their commits after the commits on the master branch.
-
Using rebase prevents a merge commit when merging master into your feature branch, and it creates a neat linear history.
-
every time you rebase, you have to resolve similar conflicts.
-
Sometimes you can reuse recorded resolutions (rerere), but merging is better since you only have to resolve conflicts once.
-
A good way to prevent creating many merge commits is to not frequently merge master into the feature branch.
-
keep your feature branches short-lived.
-
Most feature branches should take less than one day of work.
-
If your feature branches often take more than a day of work, try to split your features into smaller units of work.
-
You could also use feature toggles to hide incomplete features so you can still merge back into master every day.
-
you should try to prevent merge commits, but not eliminate them.
-
Your codebase should be clean, but your history should represent what actually happened.
-
If you rebase code, the history is incorrect, and there is no way for tools to remedy this because they can’t deal with changing commit identifiers
-
Commit often and push frequently
-
You should push your feature branch frequently, even when it is not yet ready for review.
-
A commit message should reflect your intention, not just the contents of the commit.
-
each merge request must be tested before it is accepted.
-
test the master branch after each change.
-
If new commits in master cause merge conflicts with the feature branch, merge master back into the branch to make the CI server re-run the tests.
-
When creating a feature branch, always branch from an up-to-date master.
-
Do not merge from upstream again if your code can work and merge cleanly without doing so.