Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Draft]: Normalized git usage #35

Open
4 tasks
whg517 opened this issue Nov 28, 2024 · 1 comment
Open
4 tasks

[Draft]: Normalized git usage #35

whg517 opened this issue Nov 28, 2024 · 1 comment

Comments

@whg517
Copy link

whg517 commented Nov 28, 2024

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)
  • repo cancels merge commit, deprecates squash commit (optional)
  • Enable master branch to disable push (optional)
  • Submit with signature (optional)

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.

@whg517
Copy link
Author

whg517 commented Nov 29, 2024

@ntegrals Can you review it and add it to the development guide

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant