Collection / rules

---
alwaysApply: true
description:The standard way for production teams to connect frontend and backend branches and ensure integration before merging to main is to use temporary integration or "test" branches for local verification, automated testing, and code review. 
---

Here’s how these roles and branches typically connect in Git workflows:

### How Frontend and Backend Branches Connect

- Each team (frontend, backend) works on their own branch, e.g., `frontend` and `backend`—sometimes even separate repositories.
- To test if the frontend and backend integrate correctly, a developer creates a new integration branch, e.g., `integration-test` or `merge-preview`, locally or on the remote.
- Both `frontend` and `backend` branches are merged into this integration branch. This is where manual, unit, and automated integration (E2E, CI/CD) tests are run against the combined codebase.
- If conflicts arise, they are resolved in the integration branch. No work goes to `main` (or `production`) until all issues are resolved and tested.

### Ensuring Frontend/Backend Work Together

- **Automated Testing:** Continuous Integration (CI) jobs can run post-merge checks on the integration branch. Common strategies include spinning up containers for both services to test the API/UI interactions.
- **Manual Verification:** Local testing is performed on the integration branch, running both frontend and backend servers to verify UI/API flows and features. This can include mock API servers if the backend is not updated, or stubbing endpoints.
- **Code Review:** Before merging into `main`, peer reviews ensure protocol alignment, documented API contracts, and integration readiness (API endpoints, response formats, environment variables).

### Merging to Main (Production)

- After passing all checks, the integration branch is merged into `main`.
- If issues are found post-merge, the main branch can be reset or reverted safely to its previous state using Git commands like `git reset --hard origin/main`.
- For large teams, feature branches (backend or frontend-specific) may queue merges through a shared development/staging branch before entering the main branch, following workflows like GitHub Flow, Trunk-Based, or GitFlow.

### Key Best Practices

- Use integration/testing branches to validate code before impacting production.
- Automate as much of the integration testing as possible via CI/CD, incorporating both unit and e2e tests.
- Keep clear API documentation so both frontend and backend teams know how data should flow, reducing integration bugs.
- After merging to main, monitor for regressions and have a rollback plan (using Git reset/revert).

This approach minimizes disruption, ensures frontend and backend work correctly together, and maintains production quality by catching integration bugs before merging to the main branch.