2.2. Standards: Forking And Branching

Forking and branching in Git are distinct tools, each with its own purpose:

• Forking: Creating an independent copy of a repository on your own account, typically for personal experimentation or contributions to external projects.
• Branching: Creating parallel versions within the same repository, ideal for collaborative development and managing feature work.

Importantly, forking and branching are not mutually exclusive. You can still fork a repository and create branches within your fork. However, it's crucial to choose the right collaboration model for the project's specific needs.

Forking vs. Branching – Choosing the Right Path for Collaboration

GitHub defines forking and branching as follows:

• Fork: "A fork is a personal copy of another user's repository that lives on your account. Forks allow you to freely make changes to a project without affecting the original upstream repository."
• Branch: "A branch is a parallel version of a repository. It is contained within the repository, but does not affect the primary or main branch, allowing you to work freely without disrupting the 'live' version."

Collaboration Models:

• Divergence (Forking):
  • Best suited for scenarios where you want to experiment, create your own variations, or contribute back to an open-source project where you don't have direct write access.
  • Your fork is a completely separate entity from the original repository, allowing you to explore new ideas without risk.
• Convergence (Branching):
  • Ideal for collaborative development within a single project or team.
  • Branches allow multiple contributors to work on different features simultaneously, with the intention of merging their changes back into the main branch.
  • Facilitates code review, testing, and controlled integration of changes.

RDK Collaboration: A Case for Branching

Given the collaborative nature of RDK development, the branching model aligns more closely with the goals:

1. Shared Codebase: All contributors work on the same repository, ensuring everyone is on the same page.
2. Controlled Contributions: Changes are made on branches, subjected to code reviews, and then merged into the main branch upon approval, maintaining quality and consistency.
3. Streamlined Integration: Merging branches is less cumbersome than merging forks, making the integration process smoother.

When Forking Might Be Useful in RDK:

• Initial Exploration: If you're new to a project and want to experiment without immediately contributing, you might fork the repository to get a feel for the codebase.
• Major Divergence: If you have a fundamentally different vision for a project, a fork can allow you to explore that path independently.

Key Points:

• Forking: Individual work, experimentation, contributing to external projects.
• Branching: Collaborative work within a team, controlled integration of changes.
• RDK Collaboration: Favours branching for its streamlined collaboration and code integration benefits.