Branch Workflow — jan ↔ staging-2

The Problem

Dan and Nisarg both write code on the same repo (ScottRecycling/SR-Odoo) but on different branches:

• Dan → jan (development)
• Nisarg → staging-2 (deployment + his own changes)

These branches diverge. A full merge would be destructive. Changes must move selectively, module by module.

Rules

Before Dan writes code:

# 1. Always fetch staging-2 first
git fetch ScottRecycling staging-2

# 2. Check what Nisarg changed in the module you're about to touch
git diff jan...ScottRecycling/staging-2 -- sr_module_name/

# 3. If Nisarg has changes in that module:
#    - Read his changes first
#    - Code compatibly (don't rename things he's using)
#    - Flag in the daily meeting
#    - Note conflicts in the release file

Before Nisarg deploys Dan's code:

# 1. Read the release file in Sr-docs
# 2. Fetch Dan's branch
git fetch ScottRecycling jan

# 3. See what Dan changed
git log ScottRecycling/jan --oneline -10
git diff staging-2...ScottRecycling/jan -- sr_module_name/

# 4. Cherry-pick Dan's commits (NOT a full branch merge)
git cherry-pick <commit-hash>
# OR for a whole module:
git checkout ScottRecycling/jan -- sr_module_name/

# 5. Test, fix any conflicts, commit

Never do:

• git merge jan into staging-2 (too many unrelated changes)
• git merge staging-2 into jan (pulls in Nisarg's deployment-specific changes)
• Deploy to production without staging (1717) passing first

Checking for Conflicts

Before the daily meeting, Dan should run:

# Which modules have changes on BOTH branches?
git fetch ScottRecycling staging-2
for module in $(git diff jan...ScottRecycling/staging-2 --name-only | grep -oP '^sr_\w+' | sort -u); do
    jan_changes=$(git diff ScottRecycling/staging-2...jan --name-only -- "$module/" 2>/dev/null | wc -l)
    if [ "$jan_changes" -gt 0 ]; then
        echo "CONFLICT: $module has changes on BOTH branches"
    fi
done

When Both Changed the Same Module

This happens. Here's how to handle it:

1. Dan reviews Nisarg's changes in that module on staging-2
2. Identify the overlap — are they touching the same files? Same methods?
3. Three options:
4. No overlap: Nisarg can cherry-pick Dan's commits safely
5. Minor overlap: Nisarg cherry-picks and resolves conflicts manually
6. Major overlap: Dan and Nisarg pair on the merge in a meeting, test together
7. Document the resolution in the release file under "Conflicts with staging-2"

Module Ownership

To minimize conflicts, modules should have a primary owner:

Module	Primary	Secondary	Notes
sr_management	Dan	Nisarg	Core module — both touch it, coordinate carefully
sr_management_fixes	Dan	Nisarg	Queue system — Dan owns the logic
sr_scheduling	Dan	Nisarg	Both actively developing
sr_general_sales	Dan	—	Dan owns, Nisarg deploys
sr_inventory_processing	Dan	Nisarg	Both have changes — check before each session
sr_dashboards	Dan	Nisarg	Both developing
sr_multichannel_ecommerce	Dan	—	Dan owns
sr_seo_locations	Dan	—	Dan owns
sr_partner_deduplication	—	Nisarg	Nisarg owns
sr_distance_matrix	—	Nisarg	Nisarg owns
sr_open_route_service	—	Nisarg	Nisarg owns
sr_attendance_improvements	—	Nisarg	Nisarg owns