Học Git

Git thật hữu dụng, nhưng với những người mới tập làm quen với Git thì sẽ thấy ngộp nếu phải nhảy ngay vào giao diện dòng lệnh. Các client cung cấp giao diện đồ hoạ cho Git như Sourcetree hoặc GitKraken tuy đã làm tăng sự thân thiện và trực quan lên rất nhiều, nhưng vẫn chưa thể làm bạn hết bối rối vì chúng vẫn phải trưng ra nhiều nút bấm. Dù sao thì chúng được sinh ra để bạn dùng Git, chứ không phải để dạy bạn dùng Git.

Thực sự là có rất nhiều tài liệu hướng dẫn Git, nhưng chúng đều bắt bạn phải đọc. Mà ta thường không sẵn sàng để đọc một tài liệu khi ta mới thấy nó. Khi đang dành tâm trí cho một công việc nhưng phải tạm hoãn giữa chừng để học một công cụ, ta sẽ không nhức đầu khi đó là công cụ vật lý, nhưng lại nhức đầu khi đó là công cụ số. Có lẽ xem video đỡ nhức đầu hơn. Trong những video mình đã xem, mình thấy bài thuyết trình Git For Ages 4 And Up là hấp dẫn và dễ hiểu cho người mới bắt đầu hơn cả. Tác giả dùng các món đồ chơi gỗ để minh hoạ duy nhất một điều: Tất cả những gì Git làm chỉ để làm một việc là điều khiển các đồ thị. Việc dùng những vật thể trong không gian khiến bạn có thể mường tượng được cách bạn sẽ thao tác với Git bằng cơ thể của mình thế nào. Nhớ rằng, công cụ là sự nối dài của cơ thể, không phải của não.

Các trò chơi giúp học Git

Trò chơi	Mô tả
GitByBit	Là phần mở rộng của VS Code, có câu chuyện mở đầu hấp dẫn
Git Branching	Chạy trực tiếp trên web, không cần cài đặt
git gud	Giống Git Branching nhưng chạy trực tiếp trên terminal. Phải cài Python trước
githug	Giống git gud nhưng cần cài Ruby
git-sim	Tạo ảnh, video giải thích cách Git vận hành trên dự án thực tế của bạn. Phải cài Python trước
Devlands	Tạo một vùng đất Minecraft cho dự án thực tế của bạn. Chưa ra mắt

Kinh nghiệm tra cứu

Đọc phần Discussion và Examples trên tài liệu hướng dẫn chính thức sẽ đỡ rối hơn

• NDP Software :: Git Cheatsheet
  
• Git Help Desk

Khi bạn đã thành thạo Git rồi, bạn có thể xem thêm danh sách awesome Git này này

Một số hiểu biết hữu ích

• Nhiều người hay nhầm lẫn GitHub với Git là một. Thực ra chúng khác nhau. Các repo Git chỉ được lưu trên máy của bạn, còn các repo GitHub thì được lưu trên server của GitHub. Chẳng qua là GitHub cung cấp những cách thức để bạn điều khiển cái repo được lưu trên máy của họ, như thể bạn đang ngồi ở ngay công ty của họ để làm việc. Việc bạn truy cập vào website của GitHub cũng giống như là bạn đang teamview máy họ vậy.
• Các commit trong Git được nối lại với nhau bằng các mã hash. Chính vì vậy nên có thể xem Git là một dạng xích khối (blockchain). Sự khác biệt nằm ở chỗ các xích khối trong tiền mã hoá được thiết kế để chúng ta có thể tin tưởng lẫn nhau, nên chúng có sẵn thuật toán đồng thuận trong đó. Nếu bạn chỉ dùng một mình thì Git với xích khối không khác gì nhau.
• Trong Git có hai loại lệnh: lệnh sứ (porcelain) và lệnh ống nước (plumbing). Để hiểu được ý nghĩa của chúng, cần quay lại lý do Git được tạo ra: giải quyết nhu cầu của Linus, một người viết nhân hệ điều hành. Hệ điều hành mà ông này viết, Linux, có triết lý là các chương trình cần được thiết kế sao cho nó làm tốt duy nhất một nhiệm vụ, và làm tốt việc làm cùng nhau. Kết quả của việc này là người dùng Linux thường hay nối các lệnh lại với nhau để dữ liệu được chảy từ chương trình này sang chương trình kia, và kỹ thuật này được gọi là nối ống nước (pipe). Tức là các lệnh ống nước của Git là các lệnh thường hay được dùng để nối với các lệnh Linux khác. Mà mấy cái ống nước này thường bị chôn sâu trong tường, việc thay thế chúng là khó khăn. Tức là cho dù Git có nâng cấp phiên bản gì đi nữa thì các lệnh ống nước cũng sẽ không bị thay đổi, và lập trình viên có thể yên tâm nâng cấp Git mà script họ viết không cần phải cập nhật lại. Còn mấy cái đồ sứ như bồn cầu, bồn rửa mặt thì dễ dùng và dễ thay đổi, nên nó để dành cho người dùng sử dụng.

Discord

Các ghi chú khác

• -:

  • Các lệnh Git thường dùng
  • Các lỗi Git thường gặp
  • Có thể xem Git là một dạng xích khối
  • Git giúp ta du hành thời gian
  • Facebook chuyển sang Mercurial vì nhóm phát triển Git năm 2012 không mặn mà với monorepo
  • Git được sinh ra để giải quyết nhu cầu của Linus, một người viết nhân hệ điều hành
  • Real-time collaboration isn’t necessary in most cases, but asynchronous collaboration
  • Tất cả những gì Git làm chỉ để làm một việc là điều khiển các đồ thị

• Blob, tree, ref. Bên trong Git:

  • Blob, tree, commit và annotated tag là các object chính
  • Bản chất của Git chỉ là những cặp giá trị key – value
  • Commitist và treeist
  • Các commit được nối với nhau bằng hash
  • Có thể hiểu blob là hash của một tệp, tree là hash của một thư mục, còn commit thực ra chỉ là hash của cả thư mục tổng
  • Key là hash của object, value là nội dung object
  • Có thể xem nội dung file với hash là như nhau. Nhưng file thì có thể có kích thước vô cùng lớn, còn hash thì luôn chỉ có 40 ký tự
  • Lệnh sứ là các lệnh dành cho người dùng. Lệnh ống nước là các lệnh lõi để dùng kèm với các lệnh Unix khác
  • [[🔠Ký tự, văn bản. Quản lý, viết và xuất bản nội dung/Đồng bộ, sao lưu/Git/Blob, tree, ref. Bên trong Git/Ref/Cái nào có ref thì git gc sẽ không đụng tới.md|Cái nào có ref thì git gc sẽ không đụng tới]]
  • Có 2 chỗ để lưu ref
  • git reflog giúp xem lại các ref không có trong lịch sử commit
  • git reflog là phao cứu sinh cho những lỗi lầm khi dùng Git
  • HEAD là commit hiện tại
  • @ là viết tắt của HEAD
  • Trạng thái mất đầu (detached HEAD) là khi HEAD chỉ trực tiếp vào commit chứ không phải vào nhánh
  • Ref là hệ thống đặt tên các object
  • Dấu ngã và dấu mũ là để chỉ các commit trước đó

• Chia sẻ, cập nhật dự án:

  • origin, upstream là những cái tên thường dùng cho remote
  • pull không lấy file mới về, mà lấy commit mới về

• Lưu trữ (snapshotting):

  • Git không biết gì về folder
  • pathspecs giúp chọn đường dẫn một cách linh hoạt và tinh tế hơn
  • Khi amend, rebase, push force thì author date vẫn giữ nguyên, còn commit date mới cập nhật
  • git status giúp xem những file nào đã được vào stage
  • Reset soft dùng để gộp nhiều commit lại với nhau. Reset hard dùng để xoá bỏ những gì đã ghi sau commit được chọn
  • Stash không lưu file chưa được stage
  • Stash là một commit, có cha là commit HEAD và mẹ là commit từ index
  • Stash cung cấp các lệnh dễ chịu hơn cho những lưu trữ tạm thời, dù về mặt kỹ thuật thì dùng commit và branch có nhiều ưu điểm hơn
  • Chỉ có duy nhất stash mới nhất là có ref, tất cả các stash còn lại thì không
  • git add -A làm cho index giống như ở working directory. git commit -am chỉ áp dụng cho những file đã có sẵn trong index
  • Stage, cache, index là những cái tên khác nhau cho cùng một thứ
  • Untracked, staged, unchanged và unstaged là 4 trạng thái chính của một file
  • Thứ ta đang trực tiếp chỉnh sửa mà ta tưởng là dữ liệu của mình thực chất là thứ được vay mượn từ commit
  • Việc commit giúp ta phá code mà không sợ gì, giống như có đồ bảo hộ rồi thì tha hồ nghịch điện cao thế

• Tách, gộp, chuyển nhánh:

  • Git tag
  • Fast forward
  • Khi viết tính năng mới nên tạo branch mới
  • git merge B nên được hiểu là git merge A with B. git rebase A nên được hiểu là git rebase B to A
  • Khi merge, ours là branch hiện tại. Khi rebase, theirs là branch hiện tại
  • Merge dùng để bảo lưu sự song song của các thay đổi đã xảy ra trên code. Rebase dùng để đảm bảo cây lịch sử phản ánh sự tuần tự trong quá trình thay đổi code của mình
  • Rebase thích hợp khi phải merge nhiều branch, do nó làm cây lịch sử gọn hơn

• Thăm dò, so sánh:

  • 2 chấm và 3 chấm trong log và diff
  • Cây lịch sử có thể được dùng như là bản lưu những gì đã diễn ra, hoặc là một câu chuyện kể về chúng
  • diff does not take into account untracked files
  • git diff chỉ so sánh working tree với index, không phải HEAD. Muốn so sánh với HEAD phải dùng git diff HEAD
  • git diff thường dùng
  • git log –all chỉ hiện những commit nào tiếp cận được từ một ref
  • git log giúp xem lịch sử các commit
  • ls-files chỉ làm việc với index

GitHub - GitAlias/gitalias: Git alias commands for faster easier version control