Docs: clarify upstream remote setup and fork sync steps for contributors

[SuyashJain17]

Proposed change

Resolves #3221

This PR adds a small, documentation-only section to CONTRIBUTING.md clarifying how contributors can:

• configure the upstream remote for the main OWASP/Nest repository
• sync their local main branch with upstream/main before starting new work

The intent is to document the expected fork-sync workflow in one place, helping contributors avoid working from outdated forks and reducing rebase requests during review.

Checklist

• Required: I read and followed the contributing guidelines
• Required: I ran make check-test locally and all tests passed
• I used AI for code, documentation, or tests in this PR

[coderabbitai]

Warning

Rate limit exceeded

@arkid15r has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 2 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 1bd605a and 0bc502d.

📒 Files selected for processing (1)

• CONTRIBUTING.md

Walkthrough

Added a "Keep Your Fork in Sync with Upstream" section to CONTRIBUTING.md with steps to add an upstream remote and sync local main with upstream/main. Also updated two issue/link references to use capitalized OWASP/Nest. No code or public API changes.

Changes

Cohort / File(s)	Summary
Documentation CONTRIBUTING.md	Added fork-sync instructions (how to add an upstream remote and sync local main with upstream/main); updated two issue/link references to use capitalized OWASP/Nest and corrected Issues URL paths.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• arkid15r
• kasya

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main documentation change: clarifying upstream remote setup and fork sync steps for contributors.
Description check	✅ Passed	The description is directly related to the changeset, explaining the documentation additions, the linked issue, and the rationale for the changes.
Linked Issues check	✅ Passed	The PR fully addresses the requirements from issue #3221 by adding documentation sections explaining upstream remote setup and fork synchronization.
Out of Scope Changes check	✅ Passed	All changes are documentation-only additions to CONTRIBUTING.md focused on the fork sync workflow; no out-of-scope modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

CONTRIBUTING.md (1)

524-528: Consider mentioning git rebase as an alternative to git merge (optional).

The current workflow uses git merge upstream/main to sync, which is safe and beginner-friendly. If your project prefers to keep the commit history linear (a common practice), you could optionally mention git rebase upstream/main as an alternative to line 527. However, the current merge-based approach is perfectly valid and may be preferable for general contributor guidance.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 45521fb and a5d04e1.

📒 Files selected for processing (1)

• CONTRIBUTING.md

🧰 Additional context used

🧠 Learnings (4)

📓 Common learnings

Learnt from: rudransh-shrivastava
Repo: OWASP/Nest PR: 3205
File: docker-compose/local.yaml:32-32
Timestamp: 2026-01-05T16:20:39.976Z
Learning: In the OWASP/Nest repository, feature branches use unique volume name suffixes in docker-compose files to prevent volume clashes across parallel development efforts. For example, the feature/nest-zappa-migration branch uses `-zappa` suffix for all volume names (backend-venv-zappa, cache-data-zappa, db-data-zappa, etc.) to ensure isolated environments when switching between branches.

📚 Learning: 2025-07-28T14:51:14.736Z

Learnt from: adithya-naik
Repo: OWASP/Nest PR: 1894
File: frontend/src/components/TopContributorsList.tsx:74-74
Timestamp: 2025-07-28T14:51:14.736Z
Learning: In the OWASP/Nest project, the maintainer adithya-naik prefers not to create separate components for code that's only used in two specific cases, following the YAGNI principle to avoid over-engineering when the duplication is limited and manageable.

Applied to files:

• CONTRIBUTING.md

📚 Learning: 2026-01-05T16:20:39.976Z

Learnt from: rudransh-shrivastava
Repo: OWASP/Nest PR: 3205
File: docker-compose/local.yaml:32-32
Timestamp: 2026-01-05T16:20:39.976Z
Learning: In the OWASP/Nest repository, feature branches use unique volume name suffixes in docker-compose files to prevent volume clashes across parallel development efforts. For example, the feature/nest-zappa-migration branch uses `-zappa` suffix for all volume names (backend-venv-zappa, cache-data-zappa, db-data-zappa, etc.) to ensure isolated environments when switching between branches.

Applied to files:

• CONTRIBUTING.md

📚 Learning: 2025-10-17T15:25:55.624Z

Learnt from: rudransh-shrivastava
Repo: OWASP/Nest PR: 2431
File: infrastructure/providers.tf:1-3
Timestamp: 2025-10-17T15:25:55.624Z
Learning: The infrastructure code in the OWASP/Nest repository (infrastructure/ directory) is intended for quick testing purposes only, not for production deployment.

Applied to files:

• CONTRIBUTING.md

🔇 Additional comments (1)

CONTRIBUTING.md (1)

494-530: Well-written fork sync documentation with clear, accurate instructions.

The new "Keep Your Fork in Sync with Upstream" section is well-integrated into the Contributing Workflow, logically positioned before the detailed contribution steps. The instructions are accurate, properly formatted, and follow standard GitHub fork synchronization practices. The explanation of why this matters (avoiding outdated copies and reducing merge conflicts) adds helpful context.

[rudransh-shrivastava]

Looks good to me!
Just a few suggestions:

[rudransh-shrivastava]

I think indenting this block might help with the visual identification of expanded content.

[SuyashJain17]

Applied this locally.

[SuyashJain17]

Hi @arkid15r ,
Requesting a review whenever you’re available.
Thanks!

[arkid15r]

Looks good, thank you!

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarQube Cloud