#Git config for mono repo

git config feature.manyFiles true # support mono repo
git config core.fsmonitor true # speedup git status, git add, git diff
git config core.untrackedCache true # speedup detect new files (untracked files)
git config fetch.prune true
get fetch --prune # fetch and prune remote removed branch

git config --local --list # view repo config

git config --global branch.autoSetupMerge simple # tranh push len branch Release.

git config --global push.autoSetupRemote true # khong cần thêm -u origin feature/branch-name nữa

#Git basic

1. git fetch origin

Dùng để tải toàn bộ lịch sử commit, branch, tag mới nhất từ remote server (origin) về local. Nhưng hoàn toàn không merge hay thay đổi bất kỳ dòng code nào.

1.1 Cơ chế của git fetch Trong git local bạn có 2 loại nhánh:

• Nhánh local: main, feature/login
• Nhánh Remote-tracking: ví dụ origin/main, origin/Release_R1.0.0-A

Khi chạy git fetch origin: Git liên hệ với server origin để xem có commit hoặc nhánh mới nào không. -> Git kéo dữ liệu đó về và cập nhật vào các nhánh origin/<tên-nhánh> trong thư mục .git/.

2. git pull origin

git pull = git fetch + git merge

#Quy trình

git fetch origin

# 1. Branch chinh, tach tu A của Release
git switch -c feature/f1-title1-A origin/R_1.0.0-A

# ... code, commit message.
git push # PR #1 -> R_1.0.0-A

# 2. Sau khi PR#1 tạo xong, làm PR#2 cho branch Release
git switch -c feature/f1-title1 origin/R_1.0.0
git cherry-pick -x <sha-đầu..>^..<sha-cuối> # lấy các commit từ branch ở bước 1
git push # PR#2 -> R_1.0.0

Lưu ý.

• Cherry-pick từ commit gốc trên feature branch, đừng cherry-pick commit squash đã merge vào A (SHA khác, dễ conflict). Nên làm PR#2 ngay khi PR#1 xong, đừng chờ PR#1 được merge.
• Dùng -x để có dòng cherry picked from. giúp dễ truy vết.
• Commit nhỏ, mỗi commit một ý và luôn có ticket ID. Cherry pick một khoảng commit sạch hơn so với một commit khổng lồ.
• Khi conflic ở PR#2, giải quyết xong dùng git cherry-pick --continue. Nếu thấy sai hướng, git cherry-pick --abort

#Nếu nhảy nhiều Release: dùng worktree

Đừng stash rồi đổi branch liên tục. Mỗi release làm 1 thư mục riêng.

git worktree add ../myrepo-r640 -b feature/r640/ABC-123-fix origin/Release_IA_R6.4.0-AMS
git worktree add ../myrepo-r630 -b feature/r630/ABC-99-bug   origin/Release_IA_R6.3.0-AMS
git worktree list
git worktree remove ../myrepo-r630     # khi xong

• Mỗi worktree có target/ và node_modules riêng, cần npm ci và build lại từ đầu.

• Nếu không muốn dùng worktree: git stash push -u -m "ABC-123 wip", hoặc tốt hơn là commit WIP rồi git commit --amend sau.

Sau cherry-pick, commit nào "tương đương" đã có bên kia git cherry -v origin/R1.0.0 HEAD

#Daily

git fetch origin
git rebase origin/R_1.0.0

Mỗi ngày chỉ cần gỡ conflict nếu có.

Nếu branch bạn đã push (PR draft), sau khi rebase dùng

git push --force-with-lease

Chỉ làm vậy nếu branch đó chỉ có mình bạn dùng.

#Check Conflict sớm

# file nào đã sửa khi bạn tách branch
git diff --name-only HEAD...origin/R_1.0.0

# Giao với file đang sửa
git diff --name-only origin/R_1.0.0...HEAD

# Thử merge "try"
git merge-tree --write-tree HEAD origin/R_1.0.0

Lệnh cuối in ra conflict nếu có.

#Note

git fetch origin

git rebase origin/R_1.0.0 (giải quyết conflict nếu có).

Gộp các commit vụn/WIP thành commit sạch đẹp (git rebase -i hoặc squash).

Build và test lại toàn bộ.

Push lên remote (nếu đã từng push bản WIP trước đó thì lúc này mới dùng --force-with-lease).

Giải quyết bằng git rebase (Khuyên dùng - Giữ lịch sử commit phẳng, sạch) Quy trình này đặt các commit của bạn lên trên commit mới nhất của release, giúp commit history thẳng và dễ cherry-pick sang branch release thứ hai.

Đảm bảo thư mục làm việc sạch sẽ: Kiểm tra xem còn file nào chưa commit không:

Bash git status (Nếu còn code dở dang, hãy commit lại hoặc cất tạm bằng git stash).

Kéo dữ liệu mới nhất từ remote về:

Bash git fetch origin Bắt đầu rebase vào nhánh release mục tiêu:

Bash git rebase origin/Release_IA_R6.X.X-AMS Git sẽ dừng lại tại commit gây ra conflict và thông báo danh sách các file bị đụng độ.

Xử lý conflict trong IDE (VS Code / IntelliJ):

Mở các file bị conflict (các file có dấu hiệu <<<<<<<, =======, >>>>>>>).

Chọn giữ code của bạn (Accept Current Change), giữ code của release (Accept Incoming Change), hoặc kết hợp cả hai theo đúng logic nghiệp vụ.

Lưu các file đã sửa.

Đánh dấu file đã giải quyết và tiếp tục rebase:

Bash git add git rebase --continue (Nếu còn commit khác bị conflict, lặp lại bước 4 và 5. Tuyệt đối không dùng git commit trong lúc rebase).

Build và test lại toàn bộ:

Chạy build (Maven/npm/yarn) và test cục bộ để đảm bảo code sau khi ghép không bị vỡ logic hay lỗi cú pháp.

Đẩy code đè lên remote feature branch: Vì rebase làm thay đổi commit hash, bạn phải dùng cờ an toàn --force-with-lease:

Bash git push --force-with-lease origin feature/ticket-1 Lúc này trên Azure DevOps, PR của bạn sẽ tự động cập nhật và biến mất trạng thái conflict.