Arkive/arkive
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Branch model: develop is behind main (foundation PR #1 merged into main, not develop) #4

New issue
Closed
opened 2026-06-03 23:47:08 -04:00 by McJuniorstein · 1 comment
McJuniorstein commented 2026-06-03 23:47:08 -04:00
Member
Copy link

Observation

develop and main are out of sync, in the opposite direction from what CONTRIBUTING.md describes:

  • main contains the full Phase 0 foundation (README, CONTRIBUTING, CHANGELOG, all meta/policies/, ADR-0001, docs/).
  • develop contains only README.md — the bare scaffold commit (93e6b1d).

This happened because PR #1 ("Add Arkive project foundation documents") was merged into main, while develop was never updated.

Why it matters

CONTRIBUTING.md states the intended model:

  • main is stable only.
  • develop is the integration branch.
  • Pull requests should normally target develop.

Right now develop can't serve as the integration branch — it's missing the foundation that feature work (e.g. the Issue #3 schemas) depends on. Any branch cut from develop lacks the policies, CHANGELOG, etc.

Good news: the fix is zero-risk

develop is a direct ancestor of main (git merge-base --is-ancestor develop main → true). There is no divergence and nothing to merge — develop can be fast-forwarded straight up to main with no conflicts and no merge commit.

Recommended fix

  1. Fast-forward develop to main so develop == main.
  2. Resume the documented flow: feature branches off develop → PRs into develop → promote to main for releases.
git checkout develop
git merge --ff-only main
git push origin develop

Decision needed

  • Confirm the fast-forward fix above, or state a different preferred model (e.g. keep merging foundation work into main and treat develop differently).
  • This also determines where the Issue #3 schema PR should target. The branch feature/issue-3-metadata-schemas-v0.1 is currently based on main (so it has the foundation); once develop is synced it can target develop cleanly either way.
## Observation `develop` and `main` are out of sync, in the opposite direction from what `CONTRIBUTING.md` describes: - **`main`** contains the full Phase 0 foundation (README, CONTRIBUTING, CHANGELOG, all `meta/policies/`, ADR-0001, `docs/`). - **`develop`** contains only `README.md` — the bare scaffold commit (`93e6b1d`). This happened because PR #1 ("Add Arkive project foundation documents") was merged into **`main`**, while `develop` was never updated. ## Why it matters `CONTRIBUTING.md` states the intended model: > - `main` is stable only. > - `develop` is the integration branch. > - Pull requests should normally target `develop`. Right now `develop` can't serve as the integration branch — it's missing the foundation that feature work (e.g. the Issue #3 schemas) depends on. Any branch cut from `develop` lacks the policies, CHANGELOG, etc. ## Good news: the fix is zero-risk `develop` is a **direct ancestor** of `main` (`git merge-base --is-ancestor develop main` → true). There is no divergence and nothing to merge — `develop` can be **fast-forwarded** straight up to `main` with no conflicts and no merge commit. ## Recommended fix 1. Fast-forward `develop` to `main` so `develop == main`. 2. Resume the documented flow: feature branches off `develop` → PRs into `develop` → promote to `main` for releases. ```bash git checkout develop git merge --ff-only main git push origin develop ``` ## Decision needed - Confirm the fast-forward fix above, **or** state a different preferred model (e.g. keep merging foundation work into `main` and treat `develop` differently). - This also determines where the **Issue #3** schema PR should target. The branch `feature/issue-3-metadata-schemas-v0.1` is currently based on `main` (so it has the foundation); once `develop` is synced it can target `develop` cleanly either way.
JackFrostbyte commented 2026-06-04 00:15:44 -04:00
Owner
Copy link

Issue resolved.

develop has been brought back in sync with the foundation work that was accidentally merged into main through PR #1.

Resolution performed:

ac9cb0c Merge main into develop to restore issue #1 foundation

Current branch state now confirms that:

  • develop contains the Phase 0 / issue #1 foundation files.
  • main still contains the original PR #1 merge.
  • develop is again usable as the integration branch.
  • Future feature branches and PRs should target develop as documented in CONTRIBUTING.md.

Note: the original recommended fix was a clean fast-forward, but because a revert commit had already been created on develop, the repair was completed by merging main back into develop to restore the missing foundation content.

Closing as fixed.

Issue resolved. develop has been brought back in sync with the foundation work that was accidentally merged into main through PR #1. Resolution performed: ``` ac9cb0c Merge main into develop to restore issue #1 foundation ``` Current branch state now confirms that: * develop contains the Phase 0 / issue #1 foundation files. * main still contains the original PR #1 merge. * develop is again usable as the integration branch. * Future feature branches and PRs should target develop as documented in CONTRIBUTING.md. Note: the original recommended fix was a clean fast-forward, but because a revert commit had already been created on develop, the repair was completed by merging main back into develop to restore the missing foundation content. Closing as fixed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature/issue-3-metadata-schemas-v0.1
develop
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Arkive/arkive#4
No description provided.