You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to better manage the source code, facilitate history tracing and changelog generation, we need to discuss whether to introduce some standardized git operations.
I'll list a few things to discuss:
Specification of git commit message format (important)
Good commit message helps code review and recall historical information. I have listed the git commit message specifications popular in the community for your reference, and if you have better suggestions, please initiate your own discussion.
I recommend following the commit format in the Angular Commit Message Format, which I've seen used or referenced by many communities. And Conventional Commits have been specially produced. Note, however, that the commit type for chore: has been removed from the latest commit specification.
From the perspective of the master repository, the development process of a feature does not need to be concerned, only the end result. So the commit in the PR process does not need to be reflected in the master repository. Turning on squash can automatically compress the commit of the PR process into a commit when the PR is merged into the master branch, and there are a large number of Merge pull Requests on the master repository commit baseline.
This practice has been used in many open source projects.
It should be noted that enabling this practice needs to be used in conjunction with a development model that develops functionality in separate branches. Instead of constantly committing and constantly launching PR on a branch. For example, I need to complete the function of refactoring the user module, which can be completed in the refactor/user branch, and after the PR merge, I can delete this branch.
disable push main/master branch
Allowing the main branch push is a very dangerous operation, it can cause the main branch source code to error or crash because of something, and then repeatedly fix the main branch code.
In strict accordance with the function, the revert is merged into the main branch in the form of PR. If there is a problem, the revert PR can be used to repair the problem. When the main branch is merged in PR mode, the function of minimum review number can be enabled to ensure the quality and security of the merged main branch code.
enable sign commit
We all pay great attention to security when using projects in the open source community, and enabling signed commit can verify the identity of developers by submitting signatures to avoid the risk of code tampering.
While this is not necessary, in conjunction with the PR development pattern, the commit that is merged into the main branch by PR is automatically signed by github, and the code of the PR process is automatically compressed into this commit by squash.
From my observation, individual commit signatures are not very common, for example, many projects in apache do not, and many projects in the kubernetes sig do not.
The text was updated successfully, but these errors were encountered:
In order to better manage the source code, facilitate history tracing and changelog generation, we need to discuss whether to introduce some standardized git operations.
I'll list a few things to discuss:
Description
git commit message
Good commit message helps code review and recall historical information. I have listed the git commit message specifications popular in the community for your reference, and if you have better suggestions, please initiate your own discussion.
I recommend following the commit format in the Angular Commit Message Format, which I've seen used or referenced by many communities. And Conventional Commits have been specially produced. Note, however, that the commit type for
chore:
has been removed from the latest commit specification.For details on how to write a commit description, see How to Write a Git Commit Message
enable squash commit
From the perspective of the master repository, the development process of a feature does not need to be concerned, only the end result. So the commit in the PR process does not need to be reflected in the master repository. Turning on squash can automatically compress the commit of the PR process into a commit when the PR is merged into the master branch, and there are a large number of Merge pull Requests on the master repository commit baseline.
This practice has been used in many open source projects.
It should be noted that enabling this practice needs to be used in conjunction with a development model that develops functionality in separate branches. Instead of constantly committing and constantly launching PR on a branch. For example, I need to complete the function of refactoring the user module, which can be completed in the refactor/user branch, and after the PR merge, I can delete this branch.
disable push main/master branch
Allowing the main branch push is a very dangerous operation, it can cause the main branch source code to error or crash because of something, and then repeatedly fix the main branch code.
In strict accordance with the function, the revert is merged into the main branch in the form of PR. If there is a problem, the revert PR can be used to repair the problem. When the main branch is merged in PR mode, the function of minimum review number can be enabled to ensure the quality and security of the merged main branch code.
enable sign commit
We all pay great attention to security when using projects in the open source community, and enabling signed commit can verify the identity of developers by submitting signatures to avoid the risk of code tampering.
While this is not necessary, in conjunction with the PR development pattern, the commit that is merged into the main branch by PR is automatically signed by github, and the code of the PR process is automatically compressed into this commit by squash.
From my observation, individual commit signatures are not very common, for example, many projects in apache do not, and many projects in the kubernetes sig do not.
The text was updated successfully, but these errors were encountered: