Introduction

In version control systems like Git, a repository branch is a parallel line of development within the project’s version history. Each branch represents a timeline of your hardware design cycles. 

For most projects, we recommend hardware engineers and electrical engineers having just two branches, which are long-lived: ^_main and ^_develop. The ^_main branch is the production-ready hardware branch, while the ^_develop branch is used for working on changes or the next iteration of the hardware. Having the production-ready files separate from the work in progress allows hardware engineers to work on improvements and new features. Electrical engineers can also experiment with designs without affecting the main project. Working in a ^_development branch together also fosters collaboration and promotes transparency.

Here are other ways you can use branches in your projects:

1. Feature branches:
   • Feature branches are created to develop new features or functionalities independently of the main branch. Once the feature is complete, the changes can be merged back into the main branch.
2. Bug fix branches:
   • Bug fix branches are used to isolate and resolve specific issues or bugs in the codebase without affecting ongoing development in the main branch.
3. Release branches:
   • Release branches are created to prepare for a new hardware release. They allow engineers to stabilize the designs, fix any last-minute issues, and ensure that the release is ready for production.
4. Hotfix branches:
   • Hotfix branches are similar to bug fix branches but are created to address critical issues or bugs that require immediate attention. Hotfixes are typically applied to the main branch and, if necessary, merged into other active branches.
5. Topic branches:
   • Topic branches are created for specific topics or tasks that may span multiple features or bug fixes. They provide a way to group related changes together for better organization.
6. Long-term support (LTS) branches:
   • In some projects, especially those with long-term support requirements, LTS branches may be maintained to provide ongoing updates and bug fixes for specific releases.
7. Experimental branches:
   • Engineers may create experimental branches to test new ideas out by multiple team members before the changes are merged back into the main branch.
   • Branch protections change without affecting the stability of the main branch. If the experiment is successful, the changes can be merged into the main branch.
8. Collaborative branches:
   • Teams often use collaborative branches to work on shared features or projects. These branches facilitate concurrent development. AllSpice has a feature called branch protections, which are mechanisms to enforce certain rules and restrictions on branches within a Git repository. They are particularly useful in hardware development workflows to enhance collaboration, maintain quality, and prevent accidental or unauthorized changes. Branch protections are important for all long-lived branches, but especially the _^main production branch. The repository administrator enables and configures branch protections.

Types of repository branch protections

1. Push restrictions:
   • Protections can prevent accidental or unauthorized deletion of branches, especially important branches like _^main. This helps maintain a complete and accurate history of the project.
   • Enforcing restrictions on force pushes or direct pushes to protected branches can prevent unintentional changes and maintain the integrity of the commit history.

2. Git pull request approvals:
   • Requiring at least one approval ensures that no one accidentally commits to the production branch without changes being peer-reviewed first, fostering collaboration and maintaining design quality.
   • _{^{Dismiss stale approvals}} will require a new review if additional changes are made to the design review after the approval.
   • You can enable the configuration of required checks or status checks that must pass before a branch can be merged. These checks may include automated tests and other validation processes that help ensure the stability and reliability of the design.

3. Git pull request merge
   • Determine who can merge design reviews and under what conditions, such as an allowed list of specific users if there are no rejected reviews.

Benefits of repository branch protections

1. Quality assurance:
   • By enforcing design reviews and automated checks, branch protections contribute to maintaining high-quality standards within the repository.
2. Prevention of accidental changes:
   • Protections help prevent accidental changes to critical branches, reducing the likelihood of introducing errors or disrupting the production-readiness of a design.
3. Hardware collaboration facilitation:
   • Design review enforcement encourages collaboration among team members, fostering a culture of shared responsibility and knowledge transfer.
4. Security enhancement:
   • Protections contribute to the security of the project by preventing unauthorized changes and ensuring that only validated and approved designs are merged.

Git repository branch protections are helpful in hardware development by enforcing rules that enhance collaboration, maintain project integrity, and prevent unintended changes to production-ready designs. They contribute to a more controlled and secure hardware development workflow, especially in collaborative and complex development environments.