-
-
Notifications
You must be signed in to change notification settings - Fork 423
Docs: clarify upstream remote setup and fork sync steps for contributors #3236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Docs: clarify upstream remote setup and fork sync steps for contributors #3236
Conversation
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughAdded a "Keep Your Fork in Sync with Upstream" section to Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
CONTRIBUTING.md (1)
524-528: Consider mentioninggit rebaseas an alternative togit merge(optional).The current workflow uses
git merge upstream/mainto sync, which is safe and beginner-friendly. If your project prefers to keep the commit history linear (a common practice), you could optionally mentiongit rebase upstream/mainas 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
📒 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
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Just a few suggestions:
| To avoid working on an outdated copy of Nest (and to reduce merge conflicts), contributors may find it helpful to keep their fork synchronized with the main OWASP repository. | ||
| <details> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think indenting this block might help with the visual identification of expanded content.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Applied this locally.
1bd605a
|
|
Hi @arkid15r , |



Proposed change
Resolves #3221
This PR adds a small, documentation-only section to
CONTRIBUTING.mdclarifying how contributors can:upstreamremote for the main OWASP/Nest repositorymainbranch withupstream/mainbefore starting new workThe 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
make check-testlocally and all tests passed