SOLVIT PROJECT GUIDELINES

1. Code Review Process

1. Developer creates a Pull Request (PR):

   • Push code to the relevant branch.
   • Submit a PR for review following the PR template.

2. Automatic checks:

   • CI system should run automated tests.
   • Linting and formatting checks should be executed.

3. Code Review by Peers:

   • Reviewers should be assigned quickly to not block the work of other teammates.
   • Reviewers check the PR for clarity, code style, performance, and adherence to project requirements.
   • Reviewers comment on areas that need improvement and suggest solutions.

4. Feedback Handling:

   • The author addresses the feedback by either updating the code or discussing the suggestions.

5. Merge:

   • Once approved, the PR can be merged into the main branch.
   • If the branch has conflicts, follow the communication protocol to resolve them.

Pull Request (PR) Template:

## Pull Request Title:
(Descriptive title of what the pull request does)

### Description:
(Provide a clear and concise description of what this pull request is addressing)
- What issue does it solve? 
- What functionality does it add? 

### Related Issues (if applicable):
- Fixes #IssueNumber (link to issue)

### Changes Made:
- List out major changes in the PR
- Explain any technical decisions or trade-offs made during development

### How to Test:
- Outline the steps necessary to test this PR

### Screenshots (if applicable):
(Add screenshots to explain visual changes)

---
### Checklist:
- [ ] My code follows the coding standards for this project
- [ ] I have written new tests and/or updated existing tests
- [ ] I have manually tested the functionality
- [ ] The code is free of any known bugs
- [ ] Documentation has been updated if needed

2. Communication Protocol for Handling Complex Merges or Potential Conflicts

1. Communicate Early:

   • If you anticipate a conflict or see changes in the code that might overlap, flag this early in the team’s chat.
     • "I’m working on [branch name], and I see that [other branch name] has changes in [specific files]. Let’s discuss the best approach to merge."

2. Merge in Small, Frequent Increments:

   • Large merges are riskier. If possible, aim to merge smaller, incremental updates to avoid a huge conflict later.

3. Conflict Resolution:

   • Step 1: Identify conflicting files and resolve conflicts locally.
   • Step 2: Test the merged code to ensure everything still works.
   • Step 3: Push the resolved code and ask for a final review from the involved team members before merging.

3. Branch Naming Conventions

1. Feature Branches: For new features or enhancements.

   • feature/feature_name
   • Example: feature/user_authentication

2. Bug Fixes: For resolving bugs or issues.

   • bugfix/issue_number-description
   • Example: bugfix/123-login_crash

3. Release Branches: Used for preparing for a release.

   • release/version_number
   • Example: release/1.0.0

4. Chore or Documentation Updates: For non-functional updates (e.g., documentation, CI configuration, etc.).

   • chore/description
   • Example: chore/update_readme

5. Experiment: For experimental features that might not be merged.

   • experiment/feature_name
   • Example: experiment/new_ui_design

3. Useful Git commands for working with branches

Action	Command
List branches (local, remote, all)	git branch, git branch -r, git branch -a
Create a new branch	git branch <branch-name>
Create and switch to a new branch	git checkout -b <branch-name>
Switch branches	git checkout <branch-name>
Rename a branch (current, not current)	git branch -m <new-name>, git branch -m <old-name> <new-name>
Delete a branch	git branch -d <branch-name>, git branch -D <branch-name>
Delete a remote branch	git push origin --delete <branch-name>
Merge branches	git merge <branch-name>
Rebase branches	git rebase <branch-name>
Compare branches	git diff <branch-1> <branch-2>
Push branch and set upstream	git push --set-upstream origin <branch-name>