+2

Series Git CLI Thực chiến #3: Đưa code "lên mây" – Giao tiếp với Remote Repository và CI/CD

Ở Bài 2, file main.go chứa logic xử lý giao dịch offline của hệ thống AFC đã nằm an toàn trong kho lưu trữ cục bộ (Local Repository). Tuy nhiên, nếu máy tính của anh em vô tình hỏng ổ cứng, mã nguồn đó vẫn có nguy cơ bay màu vĩnh viễn.

Quan trọng hơn, nếu code chỉ nằm trên máy cá nhân, thì bác quản gia Jenkins của chúng ta lấy mã nguồn ở đâu để kích hoạt luồng CI/CD tự động?

Để giải quyết bài toán làm việc nhóm và tự động hóa, chúng ta cần kết nối cái "xưởng mộc" ở dưới đất của mình với một cái kho chứa trên mây. Hôm nay, chúng ta sẽ làm quen với Remote Repository.

1. Remote Repository là gì?

Remote Repository đơn giản là một kho lưu trữ Git được đặt trên mạng Internet hoặc mạng nội bộ của công ty. Các nền tảng phổ biến nhất hiện nay là GitHub, GitLab, và Bitbucket.

Hãy hình dung kiến trúc như thế này:

  • Anh em Dev A và Dev B đều có một bản sao mã nguồn (Local Repo) trên máy tính của mình.
  • Cả hai cùng hướng về một kho trung tâm (Remote Repo) trên GitHub.
  • Khi dev code xong một tính năng, họ Push (Đẩy) code lên kho trung tâm.
  • Khi có bản cập nhật mới từ đồng nghiệp, họ Pull (Kéo) code từ kho trung tâm về máy mình.
  • Server Jenkins cũng đóng vai trò như một client, liên tục đứng "nghe" (thông qua Webhook). Khi có code mới đẩy lên kho trung tâm, Jenkins lập tức kéo mã nguồn đó về để tiến hành đóng gói Docker.

2. Thiết lập tọa độ kết nối: git remote

Giả sử anh em đã lên GitHub và tạo một repository mới tên là afc-transaction-service. GitHub sẽ cấp cho anh em một đường dẫn (URL), ví dụ: https://github.com/YourUsername/afc-transaction-service.git.

Mở Terminal tại thư mục dự án đang làm dở ở Bài 2, chúng ta dùng lệnh sau để báo cho Git biết cái kho trên mạng nằm ở đâu:

git remote add origin https://github.com/YourUsername/afc-transaction-service.git
  • remote add: Lệnh thêm một địa chỉ từ xa.
  • origin: Đây chỉ là một tên gọi đại diện cho cái URL dài ngoằng kia để anh em đỡ phải gõ lại nhiều lần. Anh em hoàn toàn có thể đặt là cong-ty hay kho-chinh, nhưng giới lập trình mặc định ngầm hiểu với nhau từ origin (bản gốc).

Để kiểm tra xem tọa độ đã được gắn thành công chưa, anh em gõ:

git remote -v

3. Lần cất cánh đầu tiên: git push

Code đã có, tọa độ đã lưu. Bây giờ là lúc bắn code từ máy cá nhân lên GitHub.

git push -u origin main
  • push: Hành động đẩy các commit từ Local lên Remote.
  • origin: Tên kho đích đến.
  • main: Tên nhánh (branch) mà anh em đang đứng (ở các bản Git cũ, nhánh mặc định tên là master).
  • -u (viết tắt của --set-upstream): Đây là tham số cực kỳ quan trọng cho lần đẩy đầu tiên. Nó tạo một sợi dây liên kết chặt chẽ giữa nhánh main ở máy anh em và nhánh main trên mạng. Nhờ cái cờ -u này, từ những lần sau, anh em chỉ cần gõ cộc lốc git push là Git tự hiểu phải đẩy đi đâu.

4. Đồng bộ hóa với đồng nghiệp: git pull

Thực tế đi làm, hiếm khi anh em làm dự án một mình. Giả sử trong lúc anh em đang ngồi viết Unit Test ở nhà, một đồng nghiệp trên công ty vừa fix xong một lỗi nghiêm trọng và đã push lên nhánh main trên GitHub.

Nếu lúc này anh em gõ git push, Git sẽ báo lỗi đỏ lòm (Reject). Nó nói rằng: "Kho trên mạng đang có code mới hơn máy của anh, anh phải cập nhật về trước khi đẩy cái mới lên!"

Để kéo bản cập nhật đó về và gộp vào máy mình, ta dùng lệnh:

git pull origin main

Nguyên tắc vàng khi làm việc nhóm: Luôn git pull để lấy code mới nhất về trước khi git push code của mình lên.

5. Phục hình dự án từ con số 0: git clone

Hãy đổi góc nhìn một chút. Giả sử anh em vừa được nhận vào một dự án mới tinh tại Hasaki. Ngày đầu tiên đi làm, được cấp một cái máy tính trắng tinh, việc đầu tiên anh em làm để có source code làm việc là gì?

Lúc này, anh em không cần phải git init hay git remote lằng nhằng nữa. Chỉ cần đúng 1 lệnh duy nhất để "bê" nguyên cái kho từ trên mạng về máy:

git clone https://github.com/YourUsername/afc-transaction-service.git

Lệnh clone là một lệnh gộp siêu mạnh. Nó tự động tạo thư mục, tự động tải toàn bộ file, tự động tải cả thư mục ẩn .git (tức là toàn bộ lịch sử từ thuở sơ khai của dự án), và tự động cài sẵn cái biến origin luôn. Kéo về xong là anh em mở VS Code lên chiến ngay lập tức.

Tổng kết Bài 3

Anh em đã hoàn thiện chu trình luân chuyển dữ liệu cơ bản của Git. Hiện tại, mã nguồn đã sẵn sàng trên GitHub để kích hoạt các đường ống CI/CD.

Tuy nhiên, nếu tất cả mọi người (Team Frontend, Team Backend) đều đè đầu cưỡi cổ nhau gõ git push thẳng lên nhánh main cùng một lúc, dự án sẽ biến thành một đống hỗn độn (Conflict) không thể cứu vãn.

Để tổ chức công việc chuyên nghiệp và giữ cho nhánh main luôn "sạch sẽ" để phục vụ Production, chúng ta phải sử dụng đến khái niệm quyền lực nhất của Git: Phân nhánh (Branching). Hẹn anh em ở Bài 4 để khám phá sức mạnh của việc bẻ cong không gian và thời gian trong source code!


All rights reserved

Viblo
Hãy đăng ký một tài khoản Viblo để nhận được nhiều bài viết thú vị hơn.
Đăng kí