> For AI agents: the complete documentation index is available at https://nhanbe.id.vn/llms.txt, the full documentation bundle is available at https://nhanbe.id.vn/llms-full.txt.

# 

## 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

| Đặc điểm                          | `git fetch origin`                            | `git pull origin`                       |
| --------------------------------- | --------------------------------------------- | --------------------------------------- |
| Tải commit mới về                 | có                                            | có                                      |
| gộp code vào nhánh hiện tại       | Không                                         | Có (tự động merge hoặc rebase)          |
| Nguy cơ gây conflict ngay lập tức | Không bao giờ                                 | Có thể xảy ra ngay                      |
| Mục đích sử dụng                  | Xem trước thay đổi, so sánh, kiểm tra an toàn | Cập nhật nhanh code mới để tiếp tục làm |

## Quy trình

```bash
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.

```bash
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

```bash
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

```bash
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

```bash
# 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 <cac-file-vua-sua>
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.