For specification development, keep code commit records and git branch structure clear, convenient for subsequent maintenance, now regulate git related operations.
Branch Naming
- Master is the master branch, which is also used to deploy production environment, ensuring the stability of master branch
- Master branches are generally incorporated by development and hotfix branches, you cannot modify the code at any time.
develop branch
- develop is a development branch, always keeping the latest finished and bug-fixed code
- In general, feature branches are created under the development branch
feature branch
- Create feature branches based on development when developing new features
- Branch naming: feature/beginning with feature branches, naming rules: feature/user_module, feature/ cart_module
release branch
- release is the pre-line branch, release the prediction phase, will release the branch code for the baseline prediction
When a set of features is developed, it will first merge into the development branch, and when it enters the prediction, it will Create areleasebranch.
If there are bugs that need to be fixed during the testing process, the developer will use the The branch is fixed and committed.
When the test is complete, merge thereleasebranch into the masterand develop branches, at this point Masteris the latest code for online use. hotfix branch
- Branch naming: hotfix/beginning with fix branch, its naming rules are the same as feature
- branch is similar to If there is an emergency problem online, you need to fix it in time, using master branch as baseline, create a hotfix branch, after the fix is complete, you need to merge into master branch and develop branch
Common Tasks
Add new features
( dev) $: git checkout -b feature/xxx # Create feature branch from dev
(feature/xxx) $: blabla # development
(feature/xxx) $: git add xxx
(feature/xxx) $: git commit -m 'commit comment'
(dev) $: git merge feature/xxx —no-ff # incorporate feature branches into devFix emergency bugs
( master) $: git checkout -b hotfix/xxx # Create a hotfix branch from master
(hotfix/xxx) $: blabla # development
(hotfix/xxx) $: git add xxx
(hotfix/xxx) $: git commit -m 'commit comment'
(master) $: git merge hotfix/xxx —no-ff # Combine the hotfix branch into master and go online to production
(dev) $: git merge hotfix/xxx —no-ff # merge the hotfix branch into dev, synchronize the codeTest Environment Code
( release) $: git merge dev —no-ff # merge dev branch into release, then pull and test in the test environment
Production environment online
( master) $: git merge release —no-ff # Combining release test code into master, operation and maintenance personnel
(master) $: git tag -a v0 .1 -m 'deployment Package version name ' #给版本命名，打Tag 
In a teamwork project, the developer often needs to submit code to fix bugs or implement new features. The files in the project, what features are implemented and what problems are solved, will be lost and time spent reading the code. But good log specification commit messages writing helps us, and it also reflects whether a developer is a good collaborator.
Writing good Commit messages can achieve 3 important purposes:
- Accelerate the review process
- Help us write good release log
- To let the later defenders understand the specific changes in the code and why features are added
Currently, the community has a variety of writing standards for Commit message. The Angular specification is currently the most widely used writing, more rational and systematic. As shown in the following figure:
Basic syntax for Commit messages
Angular Git Commit Guidelines is widely used in the industry.
The format is:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>- type: The type of commit, such as bugfix docs style, etc.
- scope: Scope of this commit
- subject: The main thrust of this commit is briefly explained. In the original text, several points were specifically emphasized 1. Using a praying sentence, is not very familiar and unfamiliar word, to send the door in this praying sentence 2. Do not uppercase the first letter 3. No need to add a mocking at the end
- body: We need to describe this commit in detail, such as the motive of this change, if you need to enter a line, use |
- footer: Describe the issue or break change associated with it, see the case
- feat: adding new features
- fix: fixing bugs
- docs: only modified documentation
- style: Just modify spaces, formatting indents, all good, etc., do not change the code logic
- refactor: code refactoring, no new features or bug fixes
- perf: Increase code for performance testing
- test: Add test cases
- chore: Change build flow, or add dependency libraries, tools, etc.
# Title line: 50 characters , describing the main changes
#
# Body: More detailed description text, recommended 72 characters or less. Information to be described includes:
#
# Why is this change required? It may be used to fix a bug, add a feature, improve performance, reliability, stability, etc.
# How does he solve this problem? Describe the steps to resolve the problem
#* Are there side effects, risks?
#
# If desired, you can add a link to the issue address or other documents 
No comments:
Post a Comment