Git Work Flow based on My Team Need

Everything before AI is something that we have learned with the energy of our passion, so even if the AI exists to make even our job easier but I think the passion must always be preserved.

Currently, I work with my teammate of serveral person to develop an App and this is the flow that I think match for us. So there is an understanding between us how to keep git work with the uniform method.

At some point, I also try discuss back and for with LLM about what’s best and match with our flow, however LLM not always give the most suitable one unless I drive them precisely. So, technically I dont always trust them at 100%. Eventually, I’m the one who take the responsibility for my working.

Firstly, this is the branch structure.

Remote (GitLab): — production — staging

Local: — production ← mirror of remote production — staging ← mirror of remote staging

— 20260326/feature/create-stocktf… ← your active fix branch (clone from production) — 20260326/fix/… ← your active fix branch (clone from production

The Workflow Step by Step

1. Start a fix or a new feature

Clone from production. Whenever there is a new feature or a bug we always create clone from prod branch because we assume that branch always the cleanest and well tested.

// context on local git, and have cloned all required branches for dev
git checkout production           # at local
git pull origin production        # make sure your local production is latest
git checkout -b fix/20260326/failed-updated-trx # create and checkout new branch

2. Develop & test locally

Fix the cloned-branch. Write internal unit tests then run local tests. Iterate here until all is okay.

3. Open an MR (Merge Request) into staging for get peer review

// push branch for fix
git push origin fix/20260326/failed-updated-trx

Open an MR in GitLab targeting staging, then merge with our fix branch. This step forces us to write a description of what changed and why, and gives a teammate a chance to catch something before QA spends time on it.

4. QA tests on staging

We have QA team to test our fixed bug or new feature in our staging environment. After the MR done in staging they will test it to make sure it comply with all the bussiness things. QA team does their UI, Postman, and other testing against staging.

If they find issues, I go back to my fix branch, redevelop, push again — the MR updates automatically. No new branch needed.

# back on your fix branch
# make changes
git push origin fix/20260326/failed-updated-trx  # MR auto-updates

This process is repeated until QA passes.

5. Rebase on production before merging — critical step

Before I touch production, sync my fix branch on top of the latest production state. This catches anything merged into production while you were working.

what is Rebase actually?

<< context now at branch “fix/20260326/failed-updated-trx” >>

git fetch origin # command for updating all the newest code came to each branch from remote git rebase origin/production # command for rebasing

Note:

Git takes your commits D and E, temporarily removes them, fast-forwards your branch to the latest production commit tip (G), then replays your commits on top:

Before rebase: production: A — B — C — F — G # Meanwhile, my teammate merges a different hotfix directly into production, so it got new F-G commits

my fix branch: A — B — C — D — E # My Updated commits here are D-E

After rebase: ==> git rebase origin/production production: A — B — C — F — G my fix branch: A — B — C — F — G — D’ — E’

D’ and E’ are my same changes, just replanted on top of the current production. The prime mark is important— Git rewrites those commits with new hashes because their parent has changed.

The purpose?

This Rebase will avoid OUR TEAM from UNNOTICABLE condition of No conflict and Different files. So my code is now silently broken on production the moment you merge. A rebase would have forced me to reconcile against F and G before merging, and our team (who find this) would have caught this during testing — not in production.

So, this is the step by step…

# make sure you have the latest state of remote
git fetch origin

# while on your fix branch
git rebase origin/production

# if there are conflicts, resolve them, then
git rebase --continue

# now your branch sits cleanly on top of current production
# open your MR to production

6. Open a second MR into production

Open a separate MR in GitLab targeting production, merge the fix branch. Do not merge directly. This gives a final checkpoint — you or a teammate reviews the diff one more time against production specifically.

After this, I wait for the automating testing before deploy is started. If all is well then the production has built and patch is done.

7. Merge to production & clean up

After MR is approved and merged, I need to pull the production remote to local and delete the fix branch at local to omit not used branches, so everything is clean. Don’t forget to remove the remote fix branch to on Gitlab.

git checkout production
git pull origin production   # sync local production with the merge result
git branch -d fix/20260326-update-status-transaction  # delete local fix branch

Untill here, I think that’s all I can explain as simple as possible. Besides, there are several other methods to work with in Git Workflow process. And the best one is the one that match our team condition. So this flow might fit for you, or probably not.

If any of you have any comment or constuctive feedback, please comment below so we can discuss what can be improved.

Thank youuuuuu.