Third generation software development-Git submission specifications
Article directory
- Third generation software development-Git submission specifications
-
- Project Introduction
- Git commit specifications
-
- branch specification
- Commit Message Format
-
- Header
- Body
- Footer
- Revert
- in conclusion
Keywords:
Qt、
Qml、
git、
Commit、
release
Project introduction
Welcome to our QML & C++ project! This project combines the power of QML (Qt Meta-Object Language) and C++ to develop excellent user interfaces and high-performance backend logic.
In the project, we leveraged QML’s declarative syntax and visual design capabilities to create a modern user interface. Through intuitive coding and reusable components, we can quickly develop rich and diverse interface effects and animation effects. At the same time, we use QML’s powerful integration capabilities to easily integrate the underlying logic and data model of C++ into the front-end interface.
On the backend side, we use C++ to write high-performance algorithms, data processing, and computational logic. C++ is a powerful programming language that offers excellent performance and scalability. Our team is committed to optimizing code and reducing resource consumption to ensure that our projects run efficiently on a variety of platforms and devices.
Whether you’re interested in QML and C++ development or need us to build complex user interfaces and backend logic for you, we’re ready to support you. Please feel free to contact us and let’s build a modern, high-performance QML & C++ project together!
Important?
?The price of this column will increase after the third generation soft development update.
Git submission specifications
Surprisingly unexpected, in the third generation software development process, bloggers no longer work alone, but finally have their own friends. When I was alone before, Git was only used as a backup, and I never paid attention to the submission specifications. But with small partners, it needs to be standardized a little to facilitate later maintenance and bug location. Currently we are using an **Angular commit message specification** Here we can find two articles and work downwards
Copy homework link: https://blog.csdn.net/Joseph_ZG/article/details/112818937
Copy homework link: https://www.jianshu.com/p/6433679cd10f
Branch specification
| Branch type | Naming convention | Created from | Merge to | Description |
|---|---|---|---|---|
| master | master | – | – | Long-term branch, code deployed to the production environment |
| develop | develop | – | master | Long-term branch, branch for code integration |
| feature | feature/* | develop | develop | Short-term branch, new feature branch |
| release | release/* | develop | develop and master | Short-term branches, a new version release |
| hotfix | hotfix/* | master | develop and master | short-term branches, fixing urgent bugs found in the production environment, the only ones that can be forked directly from the master branch Branch |
Once the three short-lived branch types complete development, they are merged into develop or master and then deleted.
The name of the branch should follow certain naming conventions to make it easier for developers to identify it.
When a new feature needs to be developed, the basic process is as follows:
Create a new feature branch from the develop branch, such as feature/my-xxx.
Develop on the feature branch and submit the code.
After the code submission is completed, push the feature branch to the remote warehouse.
Create a merge request on gitlab
Commit Message Format
Git commit specifications are very important for team collaboration and version control. Here are some of the importance of git commit specifications:
Improve readability and maintainability: Using a standardized commit message format can increase the readability and maintainability of your code base. Each commit should clearly describe the changes so that other developers can understand and track the changes to the code.
Improved code review process: Canonical commit messages make the code review process more efficient and meaningful. Code reviewers can more easily see the context of code changes and provide more accurate feedback and suggestions.
Facilitate issue tracking and version control: Standardized commit messages can better correlate code changes with specific tasks or bugs in issue tracking systems or version control tools. This helps to effectively manage issues and releases in the project.
Promote teamwork: Consistent commit message formats help promote good collaboration between teams. Developers can more easily understand and explain each other’s code changes and work better together on development.
In short, the importance of git commit specifications is to improve the readability, maintainability and collaboration efficiency of the code base, so that the team can better manage and track code changes.
<header> <BLANK LINE> <body> <BLANK LINE> <footer>
Each commit message should contain header, body and footer. The footer can be omitted, but the header and body cannot be empty.
Header
Header is divided into three parts: type, scope, and summary. Type and summary are required. Scope can be omitted. The format is as follows:
<type>(<scope>): <summary>
Type:
Used to describe the category of git commit. Only the following identifiers are allowed.
- feat: new function (feature).
- fix: Fix bugs, which can be bugs discovered by QA or bugs discovered by R&D itself.
- docs: documentation.
- style: format (changes that do not affect code operation).
- refactor: Refactoring (that is, code changes that are not new features or bug fixes).
- perf: optimization related, such as improving performance and experience.
- test: add test.
- chore: Changes to the build process or auxiliary tools.
- revert: Roll back to the previous version.
Scope
Scope is used to describe the scope of influence of commit, such as Controller, DAO, View, etc., which varies depending on the project. For example in Angular it could be:
- animations
- bazel
- benchpress
- common
- compiler
- compiler-cli
- core
- elements
Wait, if it contains multiple scopes, you can use commas ‘*’ to separate them.
Summary
Summary is a brief description of the commit. Generally, the Git Commit Head does not exceed 50 characters in total, so the summary must be concise. For the English commit summary, first, use the first person, present tense, such as change, neither changed nor changes. Second, the first letter does not need to be capitalized. Third, there is no punctuation mark at the end of the sentence. Except for tense, everything else is the same in Chinese.
According to the above specifications, the git commit message header can be as follows:
fix(Controller): request url map typo
Body
Same as summary in Header. At the same time, you need to explain the motivation for submission, why the change is needed, and compare it with previous behavior to explain the impact of the change, etc.
Footer
Footer is suitable for when the submitted changes contain incompatible changes or deprecated changes. The Footer part starts with BREAKING CHANGE, followed by a description of the change, the reason for the change and the migration method. At the same time, you can include related Github issues, JIRA tickets or other Fill in the document link
BREAKING CHANGE: <breaking change summary> <BLANK LINE> <breaking change description + migration instructions> <BLANK LINE> <BLANK LINE> Fixes #<issue number>
DEPRECATED: <what is deprecated> <BLANK LINE> <deprecation description + recommended update path> <BLANK LINE> <BLANK LINE> Closes #<pr number>
Revert
There is also a special case. If the current commit is used to undo the previous commit, it must start with revert:, followed by the Header of the undoed commit.
revert: fix(Controller): request url map typo
This reverts commit {commit hash id}
Summary
It is really shameful to put all this in a paid article. Please mark shameful in the comment area. For the sake of the continuity of the entire project process, I will leave this here for the time being, but I will also put it here. I don’t know if it can be realized in other free transfer columns.
