Skip to content

FAQ: Git‐Flow: Developers Branching Model

Jump to bottom
Ulrond edited this page Dec 16, 2024 · 7 revisions

1. Clone the Repository

To start, clone the repository to your local machine:

git clone https://github.com/rdkcentral/ut-core.git

2. Set Up Git Flow

We use the Git Flow branching model for managing branches. If you're new to Git Flow, please review this guide:

Example of initialising git flow:

git flow init -d

3. Create a Feature Branch

Create a new feature branch from the 'develop' branch for both new features and bug fixes, adhering to the naming convention:

feature/gh<issue-number>_<brief-description>

or

feature/<issue-number>_<brief-description>

The should briefly summarize the branch's purpose.

Example of creating a feature branch:

git flow feature start 123_add-logging-enhancements

GUI from github.com/rdkcentral: It's possible to create the branch from the GUI also.

Compliance Notice: All contributors must strictly follow our Git branching guidelines. Every branch must be accurately named using the corresponding issue ID from our issue tracker, ensuring traceability and upholding automated workflow integrity. Incorrectly named or untraceable branches will fall under a retention policy, allowing for correction within 30 days before removal. This policy is crucial for maintaining the clarity and reliability of our project management processes.

4. Implement Changes

Make changes according to the project’s coding guidelines.

5. Commit Your Changes

Ensure your commits are clear and adhere to the 50/72 rule:

  • Summary: Start with an imperative verb (Fix, Update, Add, Improve, Merge, Refactor etc) include the GitHub issue ID, and succinctly describe the change.
  • Body: Optionally, provide a detailed explanation, keeping lines to 72 characters.

Example of a Commit Message:

Fix #123: Update error handling in authentication module

This commit enhances error detection and adds comprehensive logging to address frequent issues reported by users.

For more detailed information on the 50/72 Rule: follow this link

6. Push Changes

Push your changes to the repository:

git push origin feature/123_add-logging-enhancements

7. Open a Pull Request

Create a pull request from your branch to the develop branch. It will be automatically assigned for review based on the CODEOWNERS file.

8. Testing and Validation

As part of the input and review requirements for the pull request, the engineer is responsible for:

a. Execute Testing Suites: Run all applicable test suites provided by the interface. If necessary, upgrade test suites and documentation to support new use cases (following the standard process for upgrades).

Note: Interface upgrades are outside the scope of this task and require a separate architecture change request. Any module changes are dependent on the successful release of updated test suites.

b. Document & Attach Results: Include comprehensive test results in the pull request, detailing any errors, warnings, or unexpected behaviour encountered during testing.

c. Submit for Review (Upon Success): Once all tests pass, submit the code for review via a pull request.

9. CODEOWNER Review and Approval

The pull request must be reviewed and explicitly approved by the designated CODEOWNERS. This review should include:

  • Verification of test results.
  • Assessment of code quality and adherence to standards.
  • Discussion and resolution of any concerns or questions.

Only after CODEOWNERS approval can the pull request proceed to the merge stage.

10. Merge the Pull Request

Once the code has been tested and approved by reviewers, the engineer is free to merge the branch using Git Flow:

git flow feature finish gh123_add-logging-enhancements

11. Code Ownership and Releases

CODEOWNERS are responsible for reviewing and approving changes. They also manage the release and tagging of components according to the project’s schedule.

Requirements for Contributions

Please ensure your contributions meet the following:

  • Adherence to Git Flow
  • Clear and Concise Commit Messages
  • Peer Review Approval
  • Open Discussions and Contributions
  • Thorough Testing and Validation (including test results)

By following these guidelines, you help maintain the quality and integrity of the project while fostering an inclusive and collaborative community environment. We look forward to your contributions, and thank you for being part of our community-driven project.

Refer also to FAQ: Release Engineers: Performing a release with git-flow

Clone this wiki locally