Include this information in your README or use it as the basis for a new feature that would automate the process described in this RFC
RFC: Improving Git Workflow Using Versioning Patterns
Document Status
This RFC (Request for Comments) describes a proposal to enhance the Git workflow by incorporating more robust and clear versioning practices. This document is in an early stage of discussion and is subject to revisions and changes.
Introduction
Git Flow is a popular methodology for managing software development with Git. However, this proposal aims to present an enhanced approach to Git Flow, aiming to improve the clarity and effectiveness of the versioning process.
Keywords
The keywords "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "NOT RECOMMENDED," "REQUIRED," and "OPTIONAL" in this document should be interpreted as described in RFC 2119.
Improvement Proposal
Git Flow already supports release, feature, and bugfix branching types. However, it has been observed that the standard naming for feature and bugfix branches can cause confusion and lack of clarity.
It is proposed that when creating a feature or bugfix branch, developers SHOULD NOT include a specific name for the branch. Instead, they SHOULD adopt a versioning-based approach, using the format major.minor.fix.
For example, when starting a new feature, instead of creating a branch with a specific name, the developer SHOULD use the format git flow feature start major.minor.fix.
Upon completion of the feature or bugfix and merging it into the develop branch, developers SHOULD create a new version based on the adopted versioning pattern.
If it is necessary to increase the major version number, developers SHOULD NOT do so directly. Instead, they SHOULD first execute git release finish , which will automatically merge the finishing release into main/master. Then, they SHOULD push to the remote repository, bearing in mind that versioning has been reset starting from 1.0.0, while maintaining the adopted pattern.
Afterward, they SHOULD create a new release with the sum of the major, minor, and fix numbers from the previous release, along with the last feature merged into develop. For example, if the last release was 2.3.4 and the last feature was 1.2.3, resulting in a new release/3.5.7.
Conclusion
This proposal aims to improve the clarity and consistency of the Git workflow, ensuring a more structured and standardized organization of versioning in both the local and remote repositories. By adopting a versioning-based approach, it is expected to reduce the ambiguity and common conflicts found in traditional branching methodologies.
Final Considerations
This RFC is open to comments and suggestions from the development community. It is expected that the adoption of these practices will result in significant benefits for the organization and efficiency of software development using Git.
Include this information in your README or use it as the basis for a new feature that would automate the process described in this RFC
RFC: Improving Git Workflow Using Versioning Patterns
Document Status
This RFC (Request for Comments) describes a proposal to enhance the Git workflow by incorporating more robust and clear versioning practices. This document is in an early stage of discussion and is subject to revisions and changes.
Git Flow already supports release, feature, and bugfix branching types. However, it has been observed that the standard naming for feature and bugfix branches can cause confusion and lack of clarity.
It is proposed that when creating a feature or bugfix branch, developers SHOULD NOT include a specific name for the branch. Instead, they SHOULD adopt a versioning-based approach, using the format major.minor.fix.
For example, when starting a new feature, instead of creating a branch with a specific name, the developer SHOULD use the format git flow feature start major.minor.fix.
Upon completion of the feature or bugfix and merging it into the develop branch, developers SHOULD create a new version based on the adopted versioning pattern.
If it is necessary to increase the major version number, developers SHOULD NOT do so directly. Instead, they SHOULD first execute git release finish, which will automatically merge the finishing release into main/master. Then, they SHOULD push to the remote repository, bearing in mind that versioning has been reset starting from 1.0.0, while maintaining the adopted pattern.
Afterward, they SHOULD create a new release with the sum of the major, minor, and fix numbers from the previous release, along with the last feature merged into develop. For example, if the last release was 2.3.4 and the last feature was 1.2.3, resulting in a new release/3.5.7.