One, Git workflow
1. Development process
In the master branch or functional development branch, cut out the recommended naming rule for the personal development branch: [Developer name Jianpin]/[Type]-[naming], the
name of the developer may conflict with the suffix.
Types include: fix/fixbug、feat/featureetc.,
naming Can be customized, it is recommended
to use jira jira-[JIRA_ID]
with confluence, use confluence-[confluence_pageId]
other logic with the same
function, submit and push personal branch to remote after development,
switch locally to dev branch and update git checkout dev && git pull, merge personal remote development branch. Note: As for whether to use git pull or git featch, please refer to this picture
After the conflict is resolved, push to the remote dev branch git push origin dev
If the gitlab-CI configuration is correct, submit the dev branch/any branch to create a specific tag (test-xxxxx) will automatically trigger the CI, CD process
test environment after passing, develop it locally Branch merge master branch After
resolving the conflict, push the code to your remote development branch
Submit a merge request in gitlab, the target branch is master, @related personnel review the code, after confirming that it is correct, the person
in charge merges MR and creates a tag in the master branch in Gitlab ( release-xxxx), trigger CI to build a formal environment package
Submit a deployment application at http://web.xxxx.com/, and it will be automatically deployed to the production environment after the application is approved
In the entire R&D process, the
deployment of the test environment can be completed with one click, that is, push to the remote specific test branch or any branch to create a specific tag and push to the remote.
Deploy the production environment to add review code steps and deployment review steps
to enable CI/CD in the project Later, while effectively using the functions of Gitlab, the robustness of the project was ensured and the tedious execution process was reduced.
2. Matters needing attention
The merge conflict can only be executed on the local machine, and only the remote branch can be merged into its own development branch.
All code that has been merged into the "master" branch must be correct! Their codes must be checked and confirmed. This also means that development work should not be done directly on the "master" branch, which is also the most basic rule.
The life cycle of the functional development branch is only maintained until the end of the development topic (for example, when the error is fixed, the new function is completed...), the changes of this branch will be merged into the master of the project, and this branch will also be Delete it.
Rebase will rewrite the history, so you should only use rebase to process your local branch, and never do this on commits that have already been released.
Use the "git commit" command and attach the "–amend" parameter to easily modify your last submission, including modifying the submission information and adding new submissions. Note: This method requires that the commit has not been pushed to the remote warehouse
3. Go online urgently
master branch detecting code git checkout master && git checkout -b hotfix/XXXXX
to fix the problem dev incorporated into the test
the test is completed in Gitlab the MR submitted, review and then merged into the master line
4. Git submission information format specification
The submission message consists of a header, body and footer. The
header includes:
Type (type), scope (optional), subject (subject)
[()]:
[BLANK LINE]
[body]
[BLANK LINE]
[breaking changes]
[BLANK LINE]
[footer]
The header is the only mandatory submission. The
first line (type + subject) is limited to 50 characters (mandatory) and the
other parts should be limited to 72 characters (including line
breaks ). This makes it easier to submit information in Gitlab and various git tools In reading.
Optional values for type:
feat: new features (feature)
fix: fix bugs
docs: documentation
style: file format changes (for example, changes after lint execution, etc., which do not affect code operation changes)
refactor: refactoring ( That is not a new feature, nor a code change to modify a bug)
test: add test
chore: change in the build process or auxiliary tools
ci: change in the CI release process
scope: submit the scope of influence
subject: the description
of the submission body: the details of the submission The description
footer has two functions:
1. Incompatible changes: If the current code is not compatible with the previous version, the footer part starts with BREAKING CHANGE, followed by a description of the change, the reason for the change, and the migration method.
2. Close Issue: If the current commit is for a certain issue, you can close the issue in the Footer section. See the description of Issue related to Gitlab below for how to close
Example:
1. feat(classroom): a new function
2. ci: add test
3. style: remove extra spaces
Two, the principle of using Gitlab
1. Upstream priority
The biggest principle of Gitlab flow is called "upsteam first", that is, there is only one main branch master, which is the "upstream" of all other branches. Only code changes adopted by the master branch can be applied to other branches.
2. Continuous release
For "continuous release" projects (multi-environment branch workflow), Gutlab recommends establishing different environment branches in addition to the master branch. For example:
the branch of "development environment" is dev
"pre-release environment" branch is pre
"production environment" branch is master
"production environment" branch is "upstream" of
pre-release branch , pre-release branch is development branch "Upstream".
Code changes must be developed from "upstream" to "downstream". For example, if there is a bug in the production environment, create a new ISSUE in Gitlab (assuming the ID is 312), describe the problem, and then create a fix branch fix/312 from the master. After the problem is solved, submit the commit message as fix([scope]) : Fix #312, then merge it to dev, confirm that there is no problem, then cherry-pick to pre, there is no problem at this step, then merge it into master, the process is: dev -> pre -> master.
Only in emergencies is it allowed to skip upstream and merge directly into the downstream branch.
Three, Gitlab related terms
1、Issue
Issue is used for bug tracking and requirement management. It is recommended to create a new Issue first, and then create the corresponding function branch. The feature branch is always to solve one or more issues.
The name of the feature branch can be consistent with the name of the issue, for example: 15-require-a-password-to-change-it After the
development is completed, in the submission description, you can write "fixes #14" or "closes #67 ". Gitlab stipulates that as long as the following verbs + numbers or in the commit message, the corresponding issue will be closed.
Close, Closes, Closed, Closing, close, closes, closed, closing
Fix, Fixes, Fixed, Fixing, fix, fixes, fixed, fixing
Resolve, Resolves, Resolved, Resolving, resolve, resolves, resolved, resolving
can have two ways :
1. All in the same warehouse:
Closes #333, #444, #555 and #666
2. In different libraries:
Closes #333, #444, and https://gitlab.com///issues/
2、Protected branch
The master branch should be protected. Not everyone can modify this branch and has the authority to approve Merge Requests.
3、Merge Request
The feature branch must be merged into the master/feature branch through Merge Request. Merge Request is essentially a dialogue mechanism. When submitting, you can @related personnel or team in the comments to attract their attention.
4. Merge node
There are two types of merging in Git: one is "fast forward", which does not generate a separate merge node; the other is "none fast-forword", which generates a single node.
The former is not conducive to keeping the commit information clear, and it is not conducive to future rollbacks. It is recommended to always use the latter (that is, use the -no-ff parameter). Whenever a merger occurs, there must be a single merge node.
5. Merge (Squash) multiple commits
In order to make it easier for others to read your submission, and to facilitate cherry-pick or undo code changes, you should merge multiple commits into one before initiating a Merge Request. (The premise is that the branch is developed by you alone and has not been merged with the master.)
You can also use the squash operation attached to the rebase command