Git Versioning & Workflow Scenarios (FAQ2)
This document explains how to use your local Git setup (bare repo on server + working copies) for versioned development in two scenarios:

Scenario A: Working directly on the Linux server.

Scenario B: Developing on a non‑server macOS machine and syncing with the server.

It assumes:

Bare repository on server: /home/intel145/websites/gitrepo/git.git

Working copy on server: /home/intel145/websites/apps/git

Working copy on macOS: ~/projects/git (or similar)

You use a single main branch and tags (v1, v2, v2.1, etc.) for releases.

You keep a VERSION file in the repo root to track the current version.

Core concepts
Bare repo (git.git):

Only stores history.

No working files.

You never edit or run Git commands like commit inside it.

Think of it as the “central server”.

Working copy:

Normal Git repo with checked‑out files.

This is where you edit, test, commit, and run git-bump-version.

You can have multiple working copies (on server, on Mac, etc.) all pointing to the same bare repo.

Branches vs tags:

main: the current development line.

Tags (v1, v2, v2.1): fixed points in history marking releases.

You do not need a branch per version unless you must maintain multiple versions in parallel.

Version number:

Stored in a single VERSION file in the repo root.

Updated and committed when you prepare a release.

Your application reads this file (or a generated config) at runtime.

You do not embed version numbers into every file.

Scenario A – Working on the server
Starting point: repository is at v1
On the server:

bash
cd /home/intel145/websites/apps/git
git log --oneline -5
git tag -l
# You should see a tag v1 somewhere in history.
Your working copy is currently at some commit; you can check out the exact v1 state if needed:

bash
git checkout v1   # move to the commit tagged v1
If you want to continue development from v1 on main:

bash
git checkout main
# Ensure main includes v1:
git log --oneline --graph --decorate -10
Step 1 – Develop v2 locally
Make sure you’re on main:

bash
cd /home/intel145/websites/apps/git
git checkout main
git pull git main   # sync with bare repo if needed
Edit files, test, iterate as needed.

When ready, stage and commit your changes:

bash
git add -A
git commit -m "Implement v2 features"
At this point, your local main has new commits that are not yet in the bare repo.

Step 2 – Mark this state as v2 and push
Now you want “everything I just committed” to be v2.

Update the version to 2.0.0 (or just “2” if you prefer):

bash
./git-bump-version 2.0.0
This will:

Set VERSION to 2.0.0.

Commit that change.

Create tag v2.0.0.

Push commits and tags to the bare repo:

bash
git push git main
git push git --tags
Now:

The bare repo (git.git) has all your v2 commits.

Tag v2.0.0 points to the latest commit.

Anyone cloning or pulling will get v2 when they update.

Step 3 – Start work on v2.1
You now want to develop the next incremental version, v2.1.

Ensure you’re on main and up to date:

bash
git checkout main
git pull git main
Make changes, test, then stage and commit:

bash
git add -A
git commit -m "Work towards v2.1"
When you’re ready to call this v2.1:

bash
./git-bump-version 2.1.0
git push git main
git push git --tags
Do you add the version number now?
Yes, but only in the VERSION file, via git-bump-version. You do not manually edit version strings in every file.

Scenario B – Developing on a non‑server macOS machine
You have:

Server bare repo: /home/intel145/websites/gitrepo/git.git (accessible via SSH or mounted path).

Mac working directory: e.g. ~/projects/git.

You want to:

Get v1, v2, or latest for testing.

Make changes.

Push back so the server’s main and tags reflect v2.1.

Step 1 – Clone or fetch the repo on macOS
If you don’t have a local clone yet:

bash
mkdir -p ~/projects
cd ~/projects
git clone ssh://intel145@209.182.212.74:2222/home/intel145/websites/gitrepo/git.git git
cd git
(Adjust SSH user/host/path as needed.)

Now you have a working copy with main and all tags.

To see available versions:

bash
git tag -l
git log --oneline --graph --decorate -10
Step 2 – Check out v1, v2, or latest for testing
Latest (tip of main):

bash
git checkout main
git pull
Exact v1 snapshot (read‑only view):

bash
git checkout v1
# You’re now in “detached HEAD” at the v1 tag.
# Good for inspection or tests that don’t need commits.
Exact v2 snapshot:

bash
git checkout v2
If you want to start a new line of work based on v2 (e.g., v2.1 development):

bash
git checkout v2
git checkout -b v2.1-work
# Or simply continue on main if you don’t need a separate branch.
In most simple setups, you just stay on main and use tags for releases.

Step 3 – Make changes and prepare v2.1 on macOS
Ensure you’re on the branch you want (usually main):

bash
git checkout main
git pull
Edit files, run tests locally on macOS.

When ready, commit:

bash
git add -A
git commit -m "Implement v2.1 changes"
Mark as v2.1:

bash
./git-bump-version 2.1.0
Push back to the server:

bash
git push origin main
git push origin --tags
Now the server’s bare repo and any other working copies can update to v2.1.

Step 4 – Update server working copy to v2.1
Back on the server:

bash
cd /home/intel145/websites/apps/git
git checkout main
git pull git main
git fetch --tags
You now have the same v2.1 files locally as on your Mac.

Answers to your specific questions
I want what I have in the repository to be v1; I update files; test and add to repository – I want this all to be part of next version 2.

Keep main as your development line.

Commit your changes on main.

When ready, run ./git-bump-version 2.0.0 and push with tags.

All committed changes up to that point are “v2”.

I now want to push this all to the repository.

bash
git add -A
git commit -m "v2 work"
./git-bump-version 2.0.0
git push origin main
git push origin --tags
Next scenario; I want to get all the files in v2 for editing/testing for v2.1; I make changes to files; add locally (do I add version number now); now want to push to repository.

Check out main (which includes v2):

bash
git checkout main
git pull
Make changes, then:

bash
git add -A
git commit -m "v2.1 work"
./git-bump-version 2.1.0
git push origin main
git push origin --tags
You add the version number once, via git-bump-version, just before tagging the release.

Scenario 2: developing on non‑server macOS machine; need a copy of v1, v2 or latest files for testing; test make changes and want to push back to v2.1; is this the right approach?

Yes. The right approach is:

Clone the repo to macOS.

Use git checkout v1 / v2 / main to get the version you want.

Do your work on main (or a feature branch).

Commit, bump version, and push:

bash
git add -A
git commit -m "v2.1 work"
./git-bump-version 2.1.0
git push origin main
git push origin --tags
On the server, pull to update:

bash
git pull origin main
git fetch --tags
Minimal command recipes
Release a new version (any machine)
bash
git checkout main
git pull
# ... make and test changes ...
git add -A
git commit -m "Work for next release"
./git-bump-version 2.1.0    # or 2.0.0, 3.0.0, etc.
git push origin main
git push origin --tags
Inspect or test an old version (read‑only)
bash
git fetch --tags
git checkout v1    # or v2, v2.1, etc.
# run tests, inspect files
git checkout main  # go back to development
Start work based on a specific tag
bash
git checkout v2
git checkout -b v2.1-work   # optional branch
# ... work, commit ...
git checkout main
git merge v2.1-work         # if using a branch
./git-bump-version 2.1.0
git push origin main
git push origin --tags
Summary
Use one main branch for development.

Use tags (v1, v2, v2.1) to mark releases.

Keep version in a single VERSION file; update it with git-bump-version when releasing.

Work in working copies (server or macOS), never in the bare repo.

To release: commit → git-bump-version → push branch + tags.

To test old versions: git checkout <tag>; to continue dev: git checkout main.

This workflow scales from a single developer on one machine to multiple devs on multiple machines, all syncing to the same bare repo.