HOW TO USE GIT

Nhật Huy

Mục lục

I. Local repository

1. Thiết lập chứng thực cá nhân
2. git init
3. git status
4. Tạo local repository bằng "git add"
5. git commit
6. Log
7. Branch – Kỹ thuật phân nhánh
8. Git Reset
9. Git revert
10. gitignore

II. Remote repository

11. Github
12. Git credential config
13. Git clone & pull
14. Pull request (teamwork)
15. Resolve Conflicts
16. Một số vấn đề khác

1. Thiết lập chứng thực cá nhân

$ git config --global user.name "byenet"

$ git config --global user.email "[email protected]"

2. "git init":

Lệnh khởi tạo sử dụng GIT repository cho thư mục hiện tại.
- $ git init

3. "git status":

Dùng để xem status của git project.
$ git status
- Phần tử màu đỏ thì ở working Drectory (untracked) (working Drectory là thư mục local ta đang làm việc).
- Phần tử màu xanh thì ở Staging Area (tracked).
- Tracked – Là tập tin đã được đánh dấu theo dõi trong Git để bạn làm việc với nó. Và trạng thái Tracked nó sẽ có thêm các trạng thái phụ khác là Unmodified (chưa chỉnh sửa gì), Modified (đã chỉnh sửa) và Staged (đã sẵn sàng để commit).
- Untracked – Là tập tin còn lại mà bạn sẽ không muốn làm việc với nó trong Git
Staging Area là gì?
Staging Area nghĩa là khu vực sẽ lưu trữ những thay đổi của bạn trên tập tin để nó có thể được commit, vì muốn commit tập tin nào thì tập tin đó phải nằm trong Staging Area. Một tập tin khi nằm trong Staging Area sẽ có trạng thái là Stagged (xem thêm ở dưới).

Và để đưa một tập tin vào Staging Area thì bạn sẽ cần phải sử dụng lệnh git add tên_file mà mình đã có ví dụ phía dưới.

⬆ back to top

4. Tạo local repository bằng "git add":

git add README.md
- Thêm file README.md vào cho GIT quản lý (Staging Area).
  $ git add README.md
git add *
- Thêm tất cả các file chưa add vào GIT quản lý.
  $ git add * hoặc $ git add .

⬆ back to top

5. "git commit":

commit: nghĩa là một hành động để Git lưu lại một bản chụp (snapshot) của các sự thay đổi trong thư mục làm việc, và các tập tin và thư mục được thay đổi đã phải nằm trong Staging Area. Mỗi lần commit nó sẽ được lưu lại lịch sử chỉnh sửa của mã nguồn kèm theo tên và địa chỉ email của người commit. Ngoài ra trong Git bạn cũng có thể khôi phục lại tập tin trong lịch sử commit của nó để chia cho một phân nhánh (branch) khác, đây là mấu chốt của việc bạn sẽ dễ dàng khôi phục lại các thay đổi trước đó mà mình có giới thiệu qua ở phần giới thiệu serie này.
"git commit -m '...' ": Lệnh commit sẽ có cấu trúc git commit -m "Lời nhắn", lúc này tất cả các tập đang trong trạng thái tracked (file mới) hoặc một tập tin đã được tracked nhưng có một sự thay đổi mới thì sẽ được commit.
- $ git commit -m 'Add_all_file'
Nếu có file nào được thêm hay thay đổi ta update bằng cách add rồi commit lại (kiểm tra bằng git status).
"git commit -a -m '...' ": Nếu có file nào được thêm hay thay đổi, lệnh này sẽ add luôn những thay đổi đó vào staging area (đỡ phải add).
"git commit -amend -a": Nếu có file nào được thêm hay thay đổi, mà muốn thêm nó vào commit trước đó luôn không muốn tạo thêm commit thì dùng lệnh này ( "-a" sẽ add luôn những thay đổi đó vào staging area (đỡ phải add)) (khi dùng lệnh này sẽ có phần hiện ra message commit cho mình xem có chỉnh sửa không, nếu có chỉnh sửa message commit thì làm như sài vim của linux ấn "a" để insert sau khi insert ấn "esc" và gõ ":wq" để thoát).

⬆ back to top

6. Log

Để xem lịch sử của các lần commit trước đó, bạn sử dụng lệnh "git log".
- $ git log
Dùng "git log -p" để xem chi tiết.
- $ git log -p
Hay Dùng nhiều là "git log --oneline" để xem lịch sử cho gọn tiện xem nhanh.
Dùng "git show" với id của lần commit để xem chi tiết commit đó.
- $ git show d72845cbd2f5856a7815385b03648356affb162d
Dùng "git diff" để xem những file đã được thay đổi khác gì với lúc chưa thay đổi (Modified (đã chỉnh sửa) + là đã thêm mới, - là bỏ bớt đi).
- $ git diff
Dùng lệnh "gitk" hoặc các extension hỗ trợ của vs code nếu muốn xem bằng GUI.
- $ gitk
- Dùng extension GitLens của VScode.

⬆ back to top

7. Branch – Kỹ thuật phân nhánh

vd: Khi ta làm 1 project có nhiều trang nhiều chức năng, thường mỗi khi viết 1 chức năng nào đó ta sẽ làm ra 1 branch mới để nó không bị ảnh hưởng đến nhánh chính master, cho đến khi ta code hoàn thành xong chức năng không có lỗi và hài lòng với thay đổi những commit trên các nhánh khác thì lúc đó ta mới tiến hành ghép vào nhánh master...đảm bảo cho nhánh master không bị lỗi gì.
Cách tạo 1 branch: "git branch tên_branch"
- $ git branch feature/dog-class
kiểm tra và thấy có 1 branch mới được tạo nhưng ta vẫn ở branch cũ master.
Để chuyển brank, truy cập kiểm tra mã nguồn trong branch đó để làm việc: "git checkout tên_branch"
- ngoài ra ta có thể làm tắt vừa tạo vừa chuyển qua branch mới:
  $ git checkout -b feature/dog-class
Ta thấy khi về branch branch feature/dog-class lúc này ta comment module export của Dog.js lại. nhưng khi quay về branch master thì mọi thứ còn nguyên không thay đổi => code sẽ thay đổi tùy theo brank mà ta code cho tới khi ta hài lòng thì mới ghép branch phụ vào master.
Khi ta đã code thành công, đã hài lòng ở các branch phụ, ta sẽ tiến hành gộp (merge) nó vào branch chính (master)(kéo những thay đổi từ 1 branch khác vào 1 branch nào đấy không nhất thiết phải là master).
- merge theo trình tự đang ở branch A thì merge branch B vào A (vd ta muốn merge branch feature/dog-class vào branch chính master để đồng bộ thì ta kiểm tra xem ta đã đứng ở branch master chưa nếu chưa thì checkout về master sau đó dùng lệnh merge branch feature/dog-class bây giờ dữ liệu code đã được đồng bộ từ feature/dog-class vào master và code 2 bên là giống nhau).
  $ git merge feature/dog-class
Xóa branch: $ git branch -d <branchname>

⬆ back to top

8. Git Reset

Bỏ tập tin ra khỏi Staging Area (chuyển 1 file đã git add rồi về trạng thái trước đó):
- Nếu bạn đã đưa một tập tin nào đó vào Staging Area nhưng bây giờ bạn muốn loại bỏ nó ra khỏi đây để không phải bị commit theo thì có thể sử dụng lệnh "git reset HEAD tên_file".
Undo commit
- git reset --soft commit_Id nó sẽ quay lại commit có id mà ta chỉ định và nó sẽ mở, hủy đi tất cả các commit mà bạn đã commit sau cái commit mà bạn đã chỉ định và các file sẽ trở về staging Area (đã được add nhưng chưa commit lên lan9). VD: Ta đã commit với nhãn là lan9 giờ ta sẽ trở về lúc commit mà nhãn là lan8 bằng cách dùng lệnh trên và đánh id của commit lan8 vào nó sẽ trở về commit lan8 và hủy commit lan9.
- git reset --mixed commit_Id cũng tương tự như reset --soft trên nhưng chỉ khác là các file được add trong lan8 de lên lan9 không còn ở trong staging Area nữa mà trở về working drectory luôn (nghĩa là các file sẽ trở về luôn trạng thái ở lần 8 vì nó không tồn tại trong working drectory luôn nên chắc chắn mọi thay đổi sẽ quay về).
- git reset --hard commit_Id tương tự nhưng trạng thái của commit sẽ biến mất sạch sẽ và không còn file nào trong staging area hoặc working directory luôn.

⬆ back to top

9. Git revert

nghĩa là trả lại revert lại trạng thái lúc trước (vd: viết ra 1 dòng mà thấy sai không ok thì ta có thể revert lại, quay lại trạng thái trước khi có dòng đấy, xóa nó đi chẳng hạn.). Dùng trong trường hợp 1 commit cách đây vài commit mà muốn bỏ nó đi (bỏ đi những thay đổi mà lần commit đó đã commit đã thay đổi) => nó rất nguy hiểm nên tránh dùng. (dùng reset thì tất cả commit sau nó bị mất đi. Trong trường hợp không muốn nó bị mất đi mà chỉ muốn reset lại 1 commit trong số đó thì ta dùng revert). Nó sẽ tạo ra 1 commit mới đảo ngược lại commit mình muốn revert (dùng chính id commit mà ta muốn revert về).
- git revert commit_Id
- Dùng :wq như vi để lưu ta kiểm tra lại và thu được một commit revert từ commit hồi nãy.

⬆ back to top

10. gitignore

.gitignore là 1 file nằm trong project của mình. mục đích là để ta có thể bỏ qua 1 số file mà ta không muốn commit, nó sẽ không hiển thị ra mỗi khi ta gõ git status (ví dụ khi dùng node packet thì sẽ có file node module và file này khá nặng và chỉ là source các module, ta khai báo file này vào .gitignore thì nó sẽ không commit theo, khi đẩy code lên remote server thì nó sẽ không tồn tại trên đó mà ta chỉ commit file package.json file này sẽ lưu toàn bộ cấu hình của node module. lúc cần thì kéo về và gõ lệnh npm install là các package lại được cài lại và file node modules lại tồn tại.
- khởi tạo project node và download chalk module để demo:
- Dùng git status ta có thể thấy node_modules đang hiện trong working directory.
- Tạo file .gitignore và khai báo node_modules.
- Lúc này ta gõ lại git status lại và thấy node_modules đã biến mất khỏi local repository

⬆ back to top

11. Github

Đa phần vẫn nhầm lẫn Git vs GitHub là một bởi vì cứ nói đến Git là nghĩ tới GitHub. Đó là một sự hiểu lầm vì Git là tên gọi của một mô hình hệ thống, các máy tính có thể clone lại mã nguồn từ một repository , còn GitHub là tên của một công ty cũng cấp dịch vụ máy chủ repository công cộng, mỗi người có thể truy cập vào website trang chủ để tạo tài khoản trên đó và tạo ra kho chứa source của riêng mình khi làm việc.
- Trang chủ Github
Tạo repository trên Github và làm việc.
Demo cách đưa code lên Githup cơ bản.
- Copy link dưới đây trong repository mới tạo.
- Thêm remote repository: Trường hợp bạn cần thêm một cái remote để lấy dữ liệu khi cần thì có thể sử dụng lệnh $ git remote add origin linkCopyRespository
  VD: $ git remote add origin https://github.com/byenet/hoc-git.git
  Cái origin trong đoạn đó chính là tên remote repository. Mặc định khi clone một repository thì nó tự đặt tên là origin.
- Đổi tên remote: Nếu bạn không thích tên origin thì có thể đổi tên nó lại nó bằng tên khác cho dễ quản lý nếu như bạn có nhiều remote trong một dự án với lệnh git remote rename ten_cu ten_moi. Ví dụ mình cần đổi từ origin sang thach thì sẽ đổi như sau:
- git push -u (nếu chưa sync với repository lần nào thì dùng lệnh này, còn đã sync trước đây rồi thì chỉ cẩn dùng lệnh git push) để đẩy các tập tin đã được commit lên Github. Lưu ý rằng bạn sẽ cần nhập tài khoản và mật khẩu Github.
  trên github đã được sync.
- Nếu đã sync với repository trước đây thì ta dùng git push để đẩy code lên.
Xóa remote repository:
$ git remote rm remote_name

⬆ back to top

12. Git credential config

Cài đặt Git credential helper. Một số Git clound hỗ trợ kết nối đến bằng HTTP, mỗi khi tương tác với các Git clound này cần sử dụng username/password. Bạn có thể lưu trữ lại chứng nhận thay cho việc phải cung cấp username/password. Git credential Manager sẽ quản lý các chứng nhận đó.
- git config --global credential.helper "cache --timeout=18000"
  - cache --timeout=18000 là dữ liệu được lưu trong cache ram với thời gian là 18000 ms (5 tiếng) nghĩa là sau 5 tiếng mới phải đánh lại mật khẩu một lần.

⬆ back to top

13. Git clone & pull

git clone
- Lệnh này sẽ sao chép toàn bộ dữ liệu trên repository và sao chép luôn các thiết lập về repository, tức là nó sẽ tự động tạo một master branch trên máy tính của bạn. Lệnh này chỉ nên sử dụng khi bạn cần tạo mới một Git mới trên máy tính với toàn bộ dữ liệu và thiết lập của một remote repository. (khi repository trống và ta clone repository của người khác về dùng, nó sẽ clone luôn cả những lần commit của repository đó, clone toàn bộ về...khi làm việc teamwork đây là cách phổ biến, cho lần đầu đưa dự án vào quản lý hoặc khi bạn đi làm và join và dự án các bạn cũng sẽ thực hiện việc clone project đã có của team trên server về máy tính của các bạn.).
- Copy link remote repository để tiến hành clone.
- Tại repository muốn clone về dùng lệnh git clone để tiến hành clone remote repository về repository của mình. git clone link_remoteRepository
git pull
- Nếu bạn đang làm việc chung với cả một team, bạn sẽ nhận thấy, khi repo được cập nhật lên GitHub, thì các thay đổi sẽ không còn local nữa. Nếu đúng như vậy, bạn có thể sử dụng git pull remote_origin branch_name để pull các thay đổi gần nhất từ remote branch đó.
  - Ở bên repo chính ta tiến hành commit và push cập nhật lại remote repo.
  - Ở repo local mà ta clone ra ta tiến hành git pull lấy cập nhật mới nhất từ repo remote vừa được update kia về.

⬆ back to top

14. Pull request (teamwork)

Khi làm teamwork thì leader sẽ chia project ra từng phần, ra nhiều branch trên github phụ thuộc vào chức năng bạn làm có thể là login, thanh toán hay giỏ hàng,... sau đó bạn sẽ lên git hub lấy branch của mình về làm, làm xong bạn thấy không có lỗi thì tiến hành commit và push brach đó lên repo remote của team, tạo ra 1 pull request để leader tiến hành test code. Leader nhận được pull request thì tiến hành test và review code, review code online trên github, nếu ổn thì leader fetch branch về local để test offline nếu tất cả code, chức năng chạy tốt thì leader sẽ approve pull request của bạn. Sau đó leader tiến hành merge branch bạn code vào branch master(branch chính).

a) Tạo branch, xử lý ở local repo

Có nhiều cách leader có thể tạo các branch xong bạn clone về làm rồi push lên lại. Ở đây thì bên nhân viên sẽ tạo 1 branch sau đó push lên sau ( việc này tương tự như đã làm ở local repo).
$ git checkout -b <feature_branch>
Code feature theo yêu cầu đến khi nào hoàn thành không còn bug thì push lên remote repo.

b) push lên remote repo (github)

Pushing
- Khi push từ local repository lên remote repository, cần làm sao cho nhánh đã push sẽ được merge fast-forward. Nếu phát sinh xung đột, push sẽ bị từ chối.
- Trường hợp muốn chia sẻ nhánh đã tạo tại local repository, cần phải push rõ ràng. Cho nên, miễn là không push thì sẽ không gây ảnh hưởng cho remote repository, và có thể tự do tạo branch của chính mình.
Dùng lệnh git push remote_origin branch_name để push code sau khi commit xong lên github.
- github khi ta chưa push branch lên (chỉ có 1 branch master).
- push branch lên github.
- github khi ta push branch lên (ngoài branch master còn có thêm branch feature/horse-class.

c) Creat a pull request on github and Review code, approve the pull request and merge code online

Mình sẽ tạo 1 yêu cầu để được pull code cho leader biết mình đã commit. sau khi leader nhận được sẽ tiến hành review code này xem đủ yêu cầu được pull chưa. Ta tạo pull request bắng giao diện như các hình dưới đây.
Nhân viên tạo pull request.
Leader review code online.
Nhân viên xem nhận xét của leader và sửa code sau đó commit và push code lên cho leader xem lại
Leader review lại và nếu ổn thì approve the pull request và merge code vào master

d) fetch branch into local to test code offline (optional)

Review code online thì leader chỉ xem được code có sạch không, xem sơ về logic code, cách code,... để mà xem và test được code xem nó có chạy đúng không, chạy ok chưa rồi mới tiến hành merge code và approve the pull request. Mục này sẽ demo lại quá trình push code, pull request của nhân viên, leader sẽ xem và fetch code về local test.
Nhân viên code và pull request như đã làm.
Leader review code online and fetch branch into local to test code offline
- Fetching
  - Khi thực hiện pull, merge nội dung của remote repository sẽ tự động được tiến hành. Tuy nhiên, cũng có trường hợp chỉ đơn giản muốn kiểm tra nội dung của remote repository mà không muốn merge. Những lúc như vậy hãy sử dụng fetch.
  - Khi thực hiện fetch, chỉ có thể tiến hành lấy lịch sử mới nhất của remote repository. Commit đã lấy, sẽ được đưa vào như nhánh không tên. Branch này có thể checkout bằng tên là FETCH_HEAD.
  - Ví dụ, với mỗi origin của local repository và remote repository, khi tiến hành fetch với trạng thái có commit tiến triển từ B, thì sẽ thành lịch sử giống như sơ đồ bên dưới.
  - Từ trạng thái này, trường hợp tích hợp nội dung của remote repository vào master của local repository thì sẽ merge FETCH_HEAD hoặc pull lại.
- Leader review code online
- Leader fetch branch into local to test code offline
Sau khi leader test code thành công thì sẽ lại tiến đến những bước cuối như phần review code online (nhận xét sau đó merge pull,... mình không nhắc lại).

⬆ back to top

15. Resolve Conflicts

Khi làm việc nhóm, pull, push, merge code, sẽ có trường hợp hai người cùng chỉnh sửa một file, một dòng code, khi đồng bộ sẽ xảy ra xung đột (conflict).
Khi bạn làm việc với nhiều branch, nhảy qua nhảy về, commit, sửa chung một dòng code, cũng sẽ xảy ra conflict.
Trên đây là hai tình huống thường gặp về git conflict.
Đầu tiên, cần phải hiểu rõ rằng git rebase cũng giải quyết những vấn đề tương tự với git merge. Cả 2 câu lệnh đều được tạo ra để tích hợp những thay đổi từ 1 nhánh vào 1 nhánh khác. Nhưng chúng làm theo cách khác nhau Khi bạn đang làm code 1 chức năng bục mặt ở một branch Feature. Một ngày đẹp trời, 1 thằng trong team bạn update branch master với vài commit mới, vậy để tích hợp những commit đó cũng như tránh việc conflict sau này, bạn phải làm gì. Có 2 lựa chọn cho bạn: merging hoặc rebasing

a) Resolve conflict using git rebase

Git Rebase là một chức năng được dùng khi gắn nhánh đã hoàn thành công việc vào nhánh gốc . Về mặt nội dung thì là việc điều chỉnh nhánh công việc gắn vào với nhánh gốc nên các commit sẽ được đăng kí theo thứ tự gắn vào . Chính vì thế sẽ có đặc trưng là dễ nhìn hơn sau khi xác nhận commit.
khi sử dụng git rebase để hợp nhất 2 nhánh lại thì bạn sẽ có một lịch sử đẹp hơn, thằng hàng hơn và dễ nhìn hơn git merge. Nhưng rebasing đúng như cái nghĩa đen của nó là phá hủy, nó di chuyển toàn bộ nhánh mà bạn muốn hợp nhất lên đầu nhánh chính và viết lại lịch sử commit của nhánh đó.
Hãy nhớ rằng bạn chỉ nên dùng git rebase trong nhánh của riêng bạn và đừng dùng nó với bất cứ thứ dùng đã được đẩy lên remote nếu không muốn bị mọi người trong team ghét. Và nếu bạn chưa hiểu nhiều về rebasing thì tốt nhất bạn nên sử dụng merging vì nó an toàn hơn.
Ở đây ta demo 2 nhân viên A,B code 2 branch khác nhau với 2 feature khác nhau là feature/horse-run và feature/horse-jump. Cả hai cùng thay đổi 1 file Horse.js rồi commit và gửi pull request lên branch master của remote repo. Vậy khi master của remote repo được merge với feature/horse-jumb thì master của remote repo đã bị thay đổi, lúc merge với feature/horse-run thì sẽ có conflict xảy ra.
Nhân viên A tạo branch feature/horse-run và code thêm method run cho file Horse.js. sau đó gửi pull request lên remote repo.
Nhân viên B tạo branch feature/horse-jump và code thêm method jump cho file Horse.js. sau đó cũng gửi pull request lên remote repo.
Ta có được 2 pull request từ 2 branch feature/horse-run và feature/horse-jump.
Ta tiến hành merge feature/jump vào master của remote repo.
Lúc này branch master của remote repo đã thay đổi vì đã merge feature/horse-jump vào. cụ thể là file Horse.js đã thay đổi. Bây giờ ta tiếp tục merge branch feature/horse-run vào thì sẽ thấy gây ra conflict.
Để resolve conflict này ta sẽ về repo của branch feature/horse-run (nơi cần giải quyết xung đột để được merge vào master của remote repo). từ đây ta chuyển về branch master của repo này rồi tiến hành pull tới master của remote repo để đồng bộ.
Sau đó chuyển về branch feature/horse-run và tiến hành rebase master xem thử file nào bị conflict và conflict chỗ nào để tiến hành chỉnh sửa loại bỏ conflict.
Ta thấy vấn đề ở file Horse.js ta tiến hành xem xét và chỉnh sửa file theo ý muốn để tiến hành rebase.
Sau khi sửa xong ta tiến hành commit thay đổi và git rebase --continue
Sau khi rebase thành công ta tiến hành gửi pull request feature/horse-run lên remote repo với hậu tố -f (vì lịch sử thay đổi) và ta thấy merge đã thành công.
Nếu có vấn đề gì xảy ra trong quá trình rebase thì bạn có thể hủy quá trình rebase bằng lệnh bên dưới.
git rebase --abort

b) Resolve conflict using Merge

Cũng gặp conflict như trường hợp trên nhưng ta sẽ giải quyết confict này bằng Merge.
Ưu điểm: Merging không làm thay đổi hệ thống. Những nhánh đang tồn tại sẽ không bị ảnh hưởng gì cả.
Nhược điểm: Branch Feature sẽ có thêm 1 commit merge mỗi lần bạn cần tích hợp những thay đổi từ các nhánh khác vào nó. Nếu branch master liên tục bị thay đổi thì lịch sử commit của branch Feature sẽ rất khó nhìn. Nó sẽ gây rất nhiều khó khăn trong việc xem lại lịch sử commit của dự án
Ta sẽ demo tương tự như mục a, 2 nhân viên A,B code 2 branch khác nhau với 2 feature khác nhau là feature/mouse-run và feature/mouse-sleep. Cả hai cùng thay đổi 1 file Mouse.js rồi commit và gửi pull request lên branch master của remote repo. Vậy khi master của remote repo được merge với feature/mouse-sleep thì master của remote repo đã bị thay đổi, lúc merge với feature/mouse-run thì sẽ có conflict xảy ra.
Nhân viên A code branch feature/mouse-run thay đổi file Mouse.js và commit push lên remote server.
Nhân viên B code branch feature/mouse-sleep thay đổi file Muose.js và commit push lên remote server.
Tiến hành creat pull request và merge pull request của feature/mouse-sleep trước
Lúc này file Mouse.js của remote repo đã bị thay đổi nếu ta tiếp tục merge feature/mouse-sleep vào thì sẽ gây ra conflict.
Để giải quyết xung đột ta về branch nơi mà cần merge vào branch master của remote repo để giải quyết, ta về branch feature/mouse-run và chuyển về branch master sau đó đồng bộ với remote repo bằng cách pull.
Sau đó ta chuyển về branch bị conflict khi merge là branch feature/mouse-run và đánh lệnh merge vào master để xem file nào bị conflict.
Ta thấy file Mouse.js bị conflict ta vào file Mouse.js và chỉnh sửa theo ý mình để hết conflict.
Sau khi chỉnh sửa phù hợp thì ta tiến hành commit lại và tiếp tục tạo pull request lên master của remote repo (lúc push không cần -f vì lịch sử không bị gộp).
Ta thấy merge pull request thành công và không còn conflict.