Mình sẽ end cái seri lười biếng này hôm nay.
I, Thay đổi dưới tầng file.
Rồi, như đã bàn ở phần 1 ( https://bachthing.com/basic-series-git-1-git-la-gi-git-khac-svn-sao/ ). Git xây dựng theo hướng decentralization hay nói cách khác bạn tương tác với đối tượng chính chính là local repository.
Vì lý do đó, để học git đầu tiên chúng ta phải học cách tương tác với bộ lệnh local. Chúng ta sẽ chưa học tới github hay gitlab, đó là phần remote repo và sẽ là bái tiếp theo.
Đống demo hình ảnh ở đây mình sẽ dùng trên linux, nhưng mà cơ bản nó không có sự khác biệt nào đâu.
Đầu tiên chúng ta sẽ tạo một folder git.
cd /yourfolder/gittest
git init
Khi đó git sẽ tạo một file ẩn .git. Tất cả nền tảng chính của git tồn tại ở bên trong. Khi này chúng ta có một file git cấu trúc như sau.
được rồi giờ sẽ tạo một file bên trong file gittest.
Mình tạo một file tên bach.txt . Vậy thì bây giờ chúng ta sẽ tới những lệnh đầu tiên. Đầu tiên.
git status
Lệnh này sẽ check gitfolder để tìm ra các thay đổi về file. Tiếp dó report lại và nhận yêu cầu thay đổi của người dùng.
Chúng ta có một untracked file. Vậy có nghĩa là một file mới thêm vào. Git không tự động thêm vào hệ thống source lưu trữ.
Vậy mục đích của việc này là gì?
Trong bài 2 chúng ta đã nói qua về cơ chế các cây commit của git, bản thân việc chúng ta làm sắp tới là để chọn ra các đối tượng để chốt sổ các bản commit code, điều này là cần thiết vì nếu các bạn chọn file thay đổi để commit code thì chúng ta có thể tách một lần code thành vài lần commit dựa theo file được add. Để lách lụật công ty, để tối ưu source control hay gì là ở bạn.
Rồi, giờ add file.
git add bach.txt
Và check lại status.
Vậy là các bạn đã add thêm một file mới vào commit waitting đợt này.
Khi này cấu trúc file đã thay đổi.
Giờ bạn đã thấy một folder d3 chứa file 006c3e-daivailinhhon.
vậy là file đã được add, chúng ta cùng xem file git này chứa thông tin gì bằng cách dùng lệnh .
git cat-file -p d3006c3e13e3ad62a8067367dfccd140379956e8
chuỗi chính là ghép tên của folder và file bên trong.
Và chúng ta thấy file này chứa thông tin của file bach.txt. Vậy là bạn đã có một blob như nói ở các bài trước.
Nhưng tất nhiên chuyện chưa dừng ở đây, để hoàn thành quy trình chúng ta phải commit git hay nói cách khác tạo một điểm chốt cho source vision.
Giờ chúng ta commit và check lại bằng lệnh log
vậy là file đã được add thành công. Khi này trong object xuất hiện một folder 83 và file con. Cùng xem nó là gì nhé.
Rồi, file mới chính là file b8 và d3e khi chúng ta xem nội dung.
Vậy file đầu chính là commit, nó chứa thông tin đợt commit và comment “ađd ….”
Tiếp theo trong đó trỏ tới tầng dưới của nó chính là blob bach.txt.
Khi nhẩy xuống tầng dưới của nó chúng ta có thể xem cả giá trị của file bach.txt.
Done, vậy đã dễ dàng hiểu việc thay đổi của file lưu trữ dưới dạng nút.
Bây giờ cùng thử đổi giá trị của file.
Đẩy nhanh lên một tí, giờ mình dùng echo để sửa giá trị file của bach.txt
Khi này status đổi sang trạng trái modified.
Tiếp tục add file và check lại status xong đó xem lại cấu trúc file ngầm ở trong.
Chúng ta có thêm 2 file mới dễ dàng thấy đây là một file chứa tree commit mới và file chứa giá trị mới của bach.txt vì bach.txt đã bị thay đổi.
Ở đây chúng ta sẽ dùng thêm một lệnh mới là diff để xem sự thay đổi của file.
Khi đấy chúng ta sẽ thấy so sánh file bach.txt hiện tại với bản bach.txt tại commit b8d3e chính là commit đầu tiên. Chúng ta đã xoá alo alo thay bằng hey hey.
II, Commit View
Vậy thì chúng ta cơ bản đã nhìn thấy những gì git lưu trữ. Vậy thì để tương tác với git hiệu quả chúng ta phải sử dụng nó ra sao. Phần này chúng ta sẽ chủ yếu nói về branch và rebase. Ở đây chúng ta sẽ xem file dưới lệnh
git log --all --graph --decorate
Lệnh này sẽ show commit tree đẹp mắt hơn.
OK, ở commit mới ở trên chúng ta thấy (HEAD -> master)
Bản chất dấu Head này trỏ vào chính là cây mà chúng ta đang thấy file của mình hiển thiện, nói cách khác khi file bạn ở điểm commit nào thì giá trị commit bên trong đó chính là các file và folder đó sẽ được giải mã và đặt nó thành dạng file truy cập mà bạn nhìn thấy ở bên ngoài code.
Vậy nói cách khác tương tác với HEAD chúng ta tương tác với các version code đã được đánh dấu qua commit.
Chúng ta có thể chuyển đổi giữa các commit bằng lệnh
git checkout <code commit>
Vậy điều này mang ý nghĩa gì, điều này mang ý nghĩa tất cả những tính năng quan trọng của git sẽ bắt đầu từ đây. Cơ chế dạng cây này cho phép bạn tạo các nhánh riêng biệt cho những cá nhân hay nhiệm vụ riêng việt
git branch <branchname>
Chúng ta tạo ra một nhánh từ vị trí HEAD. Sử dụng các nhánh đó như các bản code khác nhau base từ vị trí code HEAD.
Chúng ta tạo ra một nhánh mới gọi là bug và chuyển code của mình sang nhánh đó
Khi này vì bug chưa hề có code mới và nó tương đồng với code của master nên chúng ta có (HEAH -> bug, master). Vậy ta hãy thử thêm 1 file mới vào code.
Vậy là chúng ta đã nhìn thấy nhánh bug di chuyển nhưng chưa phân tách vì code mới ở master vẫn có thể tính là một điểm quá khứ của bug. Vì vậy chúng ta chuyển về master add thêm file rồi xem sao.
Bắt đầu thấy phân nhánh rồi. bạn có thể 2 nhánh của chúng ta ở 2 chỗ khác nhau, điều này trong thực tiễn cần áp dụng rất nhiều để tối ưu hoá code và giảm thiếu số lần merge cho ít hơn svn. Chúng ta chỉ merge ở giai đoạn cuối thôi và cho một tên tay to làm việc này.
Rồi các thao tác dựa theo các bài toán thực tế.
Bài 1, bạn tách ra làm một tính năng riêng biệt hoàn toàn, nhưng bạn muốn cái phần code gốc mà mình base trên dùng code mới từ nhánh cha. Ở đây chúng ta dùng lệnh rebase.
Chúng ta chạy lệnh
git rebase <nhánh base>
Mình ở đây chuyển về nhánh bug rồi rebase nó với master.
Lúc này khi check file tất cả các file ở cả nhánh cũ nhất tới 2 file riêng biệt ở bug và master mới đều xuất hiện
Mình thấy rất nhiều người dùng rebase cực thường xuyên để merge code. Tuy nhiên đây là một cách khá tối cổ vì nó hoạt động như các bạn dùng svn vậy. Mong các bạn khi xây dựng project tách các nhánh riêng biệt ra và chỉ dồn chúng vào cùng nhau khi chốt bug và tính năng.
Lệnh thứ 2 quan trọng là lệnh merge. Lệnh này thì đơn giản là sẽ dồn code vào với nhánh được chọn và nhánh HEAD.
Về cơ bản lỗi xuất hiện ở rebase và merge sẽ tương đồng nhau nhưng mong các bạn hiểu rõ, chúng ta nên hạn chế việc merge các code nhánh cho tới khi chốt các tính năng, hay nói cách khác chỉ nên merge và rebase khi chốt nhánh, đừng bao giờ dùng lệnh rebase như một thói quen để biến code thành một đường thẳng. Thế là bạn đang tự sỉ nhục phần mềm và trí thông minh của bản thân đấy.
Mình viết không có tâm nhưng mà kệ đi.