-
main(Production)- Always contains the production-ready code.
- When a feature set is complete and tested, merges (from
release/x.x.x) go intomain. - Hotfix branches come off of
main.
-
develop(Latest Development)- The working integration branch where multiple features come together for testing.
- Feature branches merge here frequently.
- Once
developis stable and ready for a release, we create arelease/x.x.xbranch fromdevelop.
-
feature/*(Active Development)- Short-lived branches named for the feature or task (e.g.,
feature/core,feature/streaming, etc.). - Merged back into
developwhen feature is complete (and tested).
- Short-lived branches named for the feature or task (e.g.,
-
release/x.x.x(Release Stabilization)- Created off of
developwhen we decide to freeze features and prepare for a release. - Merge into both
main(to deploy) and back intodevelop(to catch any last-minute fixes).
- Created off of
-
hotfix/*(Emergency Fixes)- Branch off of
mainto quickly patch production issues. - Merged back to both
main(to fix production) anddevelop(so the fix isn’t lost).
- Branch off of
main: Final, production code (stable).develop: Consolidated development and testing code.feature/core: Person A’s main feature branch.feature/streaming: Person B’s main feature branch.release/1.0.0,release/1.1.0, etc.: Release branches.hotfix/issue-123: Example hotfix branch offmainto fix a critical bug.
We’ll keep the same 4 Milestones as before, but integrate them into GitFlow:
- Milestone 1: Repository Setup & Basic Project Configuration
- Milestone 2: Independent Feature Development
- Milestone 3: Integration & Documentation
- Milestone 4: Testing, Polishing & Release
Below is how each milestone aligns with the GitFlow steps.
Goal: Prepare the project structure, initial commits, and ensure everyone can build/test locally.
-
Create Repo &
main- Initialize the repository with
mainas the default branch on GitHub/GitLab.
- Initialize the repository with
-
Create
develop- From
main, create adevelopbranch:git checkout main git checkout -b develop git push origin develop
- From
-
Create Feature Branches
- Person A:
git checkout -b feature/core develop - Person B:
git checkout -b feature/streaming develop
- Person A:
-
Shared Setup Tasks
- Initialize NPM/Node:
npm init -y - Add Dependencies: e.g.,
axios,eslint,jest, etc. - Project Folder Structure:
ollama-api-wrapper/ ├── docs/ ├── src/ ├── tests/ ├── package.json ├── .gitignore └── README.md
- Initialize NPM/Node:
-
Local Environment Verification
- Person A on
feature/core:- Install deps (
npm install), run lint/tests. - Commit the basic structure.
- Push to origin:
feature/core.
- Install deps (
- Person B on
feature/streaming:- Same local setup check.
- Commit any initial skeleton changes.
- Push to origin:
feature/streaming.
- Person A on
-
Merge Both Feature Branches into
develop- Once both have a stable starting point (just the skeleton), open PRs into
develop. - Person A: PR
feature/core→develop. - Person B: PR
feature/streaming→develop. - Approve & merge them. Now
develophas the initial structure from both sides. - Stop: This is the end of Milestone 1.
- Once both have a stable starting point (just the skeleton), open PRs into
At this point:
mainis still basically empty or minimal.developis the main dev branch with the initial project setup.
Goal: Build out the separate components in parallel, each in a feature branch.
-
Update Your Feature Branches
- After Milestone 1 merges into
develop, each person can pull the latestdevelopchanges into their feature branch. - Example:
git checkout feature/core git pull origin develop - This ensures both Person A and Person B have the same baseline.
- After Milestone 1 merges into
-
Implement & Commit
- Person A works in
feature/core, Person B infeature/streaming. - Commit frequently, push often.
- Person A works in
-
Open/Review Pull Requests (Iterative)
- Each person can do multiple merges from
feature/<branch>todeveloponce they finish a chunk of work.
- Each person can do multiple merges from
- Core Functions
-
generateCompletion(text, config) -
chat(messages, config) -
createModel(modelConfig) -
listModels() -
showModelInfo(modelName)
-
- Configuration & Error Handling
- Support for
host,port, etc. - Return meaningful error messages.
- Support for
- Unit Tests
- Write and pass all unit tests in
tests/core.test.js.
- Write and pass all unit tests in
- Streaming Functionality
-
streamChat(messages, config)for token-by-token streaming.
-
- Structured Output Parsing
- Implement logic if Ollama returns JSON or specialized data.
- Error Handling & Unit Tests
- Incomplete stream handling, test coverage in
tests/streaming.test.js.
- Incomplete stream handling, test coverage in
- Person A merges
feature/core→develop(once core features are done & tests pass). - Person B merges
feature/streaming→develop(once streaming features are done & tests pass). -
developnow contains both modules (core + streaming).
At this point, we have a more complete library on develop. main is still untouched because we haven’t released yet.
Goal: Combine modules cohesively and unify docs. Typically done on
develop.
-
Create a (Possible) Integration Feature Branch
- Optionally, create a
feature/integrationfromdevelopto do final integration tasks. - Or do them directly on
develop(if simpler).
- Optionally, create a
-
Integration Testing
- Write
tests/integration.test.jsthat calls both core and streaming functionality end-to-end.
- Write
-
Consolidate Documentation
- Merge
docs/core-usage.mdanddocs/streaming-usage.mdinto a singledocs/README.mdor the mainREADME.md. - Create
examples/folder with scripts demonstrating basic usage.
- Merge
-
Merge Integration/Docs Work into
develop- Once the integration tests and docs are done, merge the
feature/integration(if used) intodevelop.
- Once the integration tests and docs are done, merge the
-
develophas a fully integrated codebase with up-to-date docs. - All integration tests pass.
Goal: Final QA, create a release branch from
develop, then push tomain.
-
Create a Release Branch
- From
develop:git checkout develop git checkout -b release/1.0.0 git push origin release/1.0.0 - This branch is now for final tweaks, version bump, and preparing for a stable release.
- From
-
Polish & Test
- Additional QA, load testing, or code review.
- Bump version in
package.jsonto1.0.0. - Document any known issues or future enhancements.
-
Merge Release Branch into
main- Final “release” commit merges into
main:git checkout main git merge --no-ff release/1.0.0 - Tag it:
git tag -a v1.0.0 -m "Release 1.0.0" && git push --tags. - Also merge changes back into
develop(to ensure no release fixes are lost):git checkout develop git merge --no-ff release/1.0.0 release/1.0.0branch can be deleted once merged.
- Final “release” commit merges into
-
Publish
-
npm publish(if public). - Now
mainis the official version 1.0.0.
-
- Released version in
main. - Tag created (e.g.,
v1.0.0). - Code merged back to
develop.
Should a critical bug be found after merging to main, you would:
- Branch Off
main:hotfix/fix-urgent-bug - Fix & Commit
- Merge hotfix back to
main(to deploy the fix) and todevelop(so the fix is in the latest dev code). - Tag the new version if necessary.
This ensures the quick fix goes to production without waiting on the entire development cycle.
Here’s a concise version of the entire flow with the Git branching logic baked in:
-
Milestone 1
maincreated →developcreated → Each developer starts afeature/*branch.- Basic skeleton, NPM init, lint/test config done.
- Merge feature branches back into
developonce stable (just setup code).
-
Milestone 2
- Active development on
feature/core(Person A) &feature/streaming(Person B). - Each merges repeatedly into
develop(PR -> code review -> merge). - End result:
develophas all new features combined.
- Active development on
-
Milestone 3
- Possibly a
feature/integrationfromdevelop. - Integration tests, doc consolidation, examples.
- Merge final integrated code back to
develop.
- Possibly a
-
Milestone 4
- Create
release/x.x.xfromdevelop. - Final polish, version bump.
- Merge
release/x.x.x→main, then back →develop. - Tag & publish.
- Create
-
Hotfix
- If needed,
hotfix/*frommain. - Merge back to
main+develop.
- If needed,
This workflow ensures:
mainalways reflects production-ready releases.developis the up-to-date testing/integration environment.feature/*branches isolate new work, preventing conflict.release/*branches give you stable snapshots before final deployment.hotfix/*patches production quickly and merges changes back intodevelop.