Discover Meteor - Chương 5

Trong chương này bạn sẽ:

• Tìm hiểu cách sử dụng GitHub

GitHub là một kho lưu trữ dữ liệu cho các dự án mã nguồn mở dựa trên hệ thống quản lý version Git, và chức năng chính của nó là làm cho việc chia sẻ mã nguồn và cộng tác trên các dự án được dễ dàng hơn. Nhưng nó cũng là một công cụ học tập tuyệt vời. Trong chương sidebar này, chúng ta sẽ lướt qua một vài cách sử dụng GitHub giúp bạn đi suốt cuốn sách Khám phá Meteor.

Chương Sidebar này giả định bạn không quen với Git và GitHub. Nếu bạn đã quen thuộc với cả hai, bạn có thể bỏ qua chương này để đi tiếp!

Commit

Khối làm việc cơ bản của một kho git là commit. Bạn có thể tưởng tượng commit như là một bản chụp lại trạng thái của mã nguồn tại một thời điểm.

Thay vì chỉ đơn giản là cung cấp cho bạn mã thành phẩm cho Microscope, chúng tôi đã thực hiện những bản chụp tại mỗi bước cho bạn, và bạn có thể xem tất cả chúng trực tuyến trên GitHub.

Ví dụ, đây là trạng thái của commit cuối cùng trong chương trước:

Thứ mà bạn đang nhìn thấy là “diff” (viết tắt cho “difference” - thay đổi) của file post_item.js, hay nói cách khác là thay đổi được tạo bởi commit hiện tại. Trong trường hợp này, chúng ta đã tạo file post_item.js từ trạng thái trống, vì vậy tất cả nội dung của nó được đánh dấu với màu xanh.

Hãy so sánh với một ví dụ từ commit sau này trong cuốn sách:

Lần này, chỉ có các dòng đã sửa đổi được đánh dấu màu xanh.

Và tất nhiên, đôi khi bạn không thêm hoặc thay đổi dòng mã, mà xóa chúng:

Chúng ta đã được thấy tác dụng của GitHub lần đầu tiên: thấy được sơ lược những thay đổi về code.

Truy vấn code của một commit

Màn hình hiển thị commit của Git cho chúng ta thấy những thay đổi trong commit đó, nhưng đôi khi chúng ta cũng muốn biết được những file đã không thay đổi, để chắc chắn rằng mọi đoạn code làm đúng chức năng của nó trong bước hiện tại.

GitHub cũng có thể giúp chúng ta làm việc này. Khi bạn đang ở trên một trang commit, bấm vào button Browse code:

Bây giờ bạn sẽ có quyền truy cập vào repo với trạng thái của một commit cụ thể:

GitHub không cung cấp cho chúng ta nhiều gợi ý về commit mà chúng ta đang theo dõi, nhưng bạn có thể so sánh với hiển thị của nhánh master “bình thường” để thấy được cấu trúc file có sự thay đổi:

Truy cập local một commit

Chúng ta vừa thấy làm thế nào để truy cập toàn bộ code của một commit trực tuyến trên GitHub. Nhưng sẽ như thế nào nếu bạn cũng muốn làm điều tương tự ở local? Ví dụ, bạn muốn chạy ứng dụng local tại một commit cụ thể nào đó để thấy được hoạt động của nó tại thời điểm đó.

Để làm được điều này, chúng ta sẽ bắt đầu thực hành lần đầu (trong cuốn sách này) với tiện ích dòng lệnh git. Cho người mới bắt đầu, chắc chắn rằng bạn đã cài đặt Git. Sau đó clone (hay nói cách khác, tải một bản copy về local) repository Microscope với:

git clone git@github.com:DiscoverMeteor/Microscope.git github_microscope

github_microscope ở cuối câu lệnh đơn giản chỉ là tên của thư mục local mà bạn muốn clone ứng dụng vào. Giả định rằng bạn đã có một thư mục microscope tồn tại, hãy chọn một tên thư mục khác (không nhất thiết phải trùng tên với repo GitHub).

Hãy cd vào repository để chúng ta có thể bắt đầu sử dụng tiện ích dòng lệnh git:

cd github_microscope

Bây giờ khi mà chúng ta đã clone repository từ GitHub, chúng ta đã thực sự tải toàn bộ code của ứng dụng, nghĩa là chúng ta đang có code ở commit cuối cùng.

May mắn là, có một cách để quay ngược trở lại và “check out” (kiểm tra lại) một commit cụ thể nào đó mà không ảnh hưởng tới các phần khác. Hãy thử lệnh sau:

git checkout chapter3-1
Note: checking out 'chapter3-1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at a004b56... Added basic posts list template and static data.

Git thông báo cho chúng ta biết rằng chúng ta đang ở trạng thái “detached HEAD”, nghĩa là theo Git, chúng ta có thể quan sát commit trong quá khứ nhưng không thể thay đổi chúng. Bạn có thể suy nghĩ nó giống như là một chiếc gậy phù thuỷ điều tra quá khứ thông qua quả cầu chiêm tinh.

(Lưu ý rằng Git cũng có các lệnh cho phép bạn thay đổi commit trong quá khứ. Điều này cũng giống như là cỗ máy vượt thời gian trở về một thời điểm trong quá khứ và chạm vào một con bướn, nhưng nó nằm ngoài phạm vi của phần giới thiệu này).

Lý do bạn có thể đơn giản gõ chapter3-1 là do chúng tôi đã tạo nhãn trước đó cho tất cả commit của Microscope với ký hiệu của từng chương. Nếu không phải vậy, bạn đã cần phải tìm ra hash của commit hoặc một định danh đơn trị nào đó.

Một lần nữa, GitHub giúp chúng ta làm việc dễ dàng hơn. Bạn có thể tìm ra hash của commit tại góc dưới bên phải của phần xanh da trời trên ô chứa phần đầu commit, giống như hình sau:

Hãy cùng thử với hash thay vì dùng nhãn như trước:

git checkout c7af59e425cd4e17c20cf99e51c8cd78f82c9932
Previous HEAD position was a004b56... Added basic posts list template and static data.
HEAD is now at c7af59e... Augmented the postsList route to take a limit

Cuối cùng, làm thế nào để chúng ta thoát khỏi việc nhìn vào quả cầu ma thuật và quay trở lại hiện tại? Chúng ta sẽ bảo Git rằng chúng ta muốn điều chỉnh về nhánh master:

git checkout master

Lưu ý rằng bạn cũng có thể chạy lệnh meteor tại bất kỳ thời điểm nào, ngay cả khi trong trạng thái “detached HEAD”. Có thể bạn sẽ phải chạy lệnh meteor update trước nếu như Meteor phàn nàn về việc thiếu package, vì package không nằm trong Git repo của Microscope.

Viễn cảnh lịch sử

Sau đây là một kịch bản phổ biến khác: bạn nhìn vào một file và thấy rằng đã có một vài thay đổi so với trước đó. Có điều là, bạn không nhớ ra khi nào file đó đã thay đổi. Bạn có thể tìm kiếm từng commit một cho tới khi bạn thấy commit đúng, tuy nhiên cũng có cách dễ dàng hơn bằng việc dùng tính năng History của GitHub.

Đầu tiên, truy cập vào file của bạn trên GitHub, sau đó định vị button “History”:

Bây giờ bạn đã có được danh sách những commit mà ảnh hưởng tới file đó:

Trò chơi đổ lỗi

Để kết thúc, hãy cùng nhìn vào button Blame:

Hiển thị gọn gàng này giúp chúng ta thấy được ai đã thay đổi file, và với commit nào (hay nói cách khác, ai để đổ lỗi khi mà mọi thứ không còn hoạt động như ý):

Bây giờ Git - và cả GitHub - đã trở thành một công cụ khá phức tạp, do vậy chúng tôi không hi vọng có thể giải thích tất cả mọi thứ trong một chương đơn lẻ. Thực tế, chúng ta đã chỉ lướt ngắn gọn qua bề nổi của những công cụ này. Nhưng hi vọng, một chút kiến thức này sẽ giúp bạn theo dõi suốt cuốn sách này.