Git và GitHub

Khi mới bắt đầu học lập trình, đặc biệt là khi làm việc với source code, chắc hẳn bạn đã từng nghe đến hai cái tên Git và GitHub. Và một trong nhưng hiểu lầm phổ biến nhất của người mới là cho rằng Git và GitHub là một.

Nghe qua thì điều này cũng khá dễ hiểu vì cả hai đều xuất hiện trong quá trình quản lý và chia sẻ code, nhiều tài liệu còn thường xuyên nhắc đến chũng cùng nhau. Bạn có thể thấy những câu như “đẩy code lên GitHub bằng Git”, “tạo repository GitHub” hay “dùng Git để quản lý project”. Vì vậy không ít người nghĩ rằng Git chính là GitHub, hoặc GitHub đơn giản chi là phiên bản online của Git.

Nhưng thực tế không phải vậy.

Git và GitHub có mối liên hệ rất chặt chẽ, nhưng chúng là hai thứ khác nhau và đảm nhận những vai trò khác nhau.

Nếu ví việc phát triển phần mềm giống như xây dựng một công trình, thì Git giống như hệ thống giúp bạn ghi lại toàn bộ lịch sử xây dựng và quản lý từng phiên bản của công trình, còn GitHub giống như một không gian trực tuyến nơi bạn có thể lưu trữ công trình đó, chia sẻ với người khác và cùng nhau làm việc.

Hiểu đúng sự khác nhau này là bước đầu tiên để sử dụng Git/GitHub hiệu quả.

Trước hết trong bài viết này chũng ta sẽ tập trung vào việc tìm hiểu Git.

Vậy thực sự Git là gì ?

Để hiểu Git, trước tiên hãy thử tưởng tượng bạn đang thực hiện một project lập trình cùng với một nhóm bạn.

Ban đầu, project chỉ có một vài file và mọi thứ khá đơn giản. Nhưng sau một thời gian, project bắt đầu phát triển: người này thêm một chức năng mới, người khác sửa giao diện, một thành viên khác lại chỉnh sửa logic xử lý. Các file liên tục thay đổi và số lượng phiên bản ngày càng nhiều.

Lúc này, một vấn đề rất dễ xảy ra:

Làm thế nào để biết code đã thay đổi những gì? Ai đã thay đổi? Thay đổi vào thời điểm nào? Và nếu một thay đổi làm project bị lỗi thì có thể quay lại phiên bản trước hay không?

Nếu không có một công cụ quản lý phiên bản, nhiều người sẽ phải tự tạo các bản sao như:

project
project-final
project-final-2
project-final-new
project-final-new-update
project-final-new-update-ok

Nghe có vẻ quen thuộc?

Đây chính là một trong những vấn đề mà Git được tạo ra để giải quyết.

Git là gì?

Git là một hệ thống quản lý phiên bản phân tán (Distributed Version Control System – DVCS), được sử dụng để theo dõi và quản lý những thay đổi trong source code theo thời gian.

Thay vì phải tạo hàng loạt bản sao của project, Git cho phép chúng ta lưu lại các mốc thay đổi (commit) trong lịch sử của project.

Mỗi commit giống như một snapshot của project tại một thời điểm.

Nhờ đó, Developer có thể xem lại lịch sử thay đổi, so sánh các phiển bản và trong nhiều trường hợp có thể quay lại trạng thái trước đo khi cần.

Nhưng git không chỉ đơn giản là công cụ lưu lại code.

Git còn cung cấp nhiều cơ chế quan trọng như branch, merge, rebase, reset, revert, cherry-pick… giúp developer có thể làm việc với nhiều hướng phát triển khác nhau mà vẫn kiểm soát được lịch sử của project.

Đặc biệt, Git được thiết kế theo mô hình phân tán, nghĩa là mỗi developer có thể có một bản sao đầy đủ của repository trên máy tính của mình. Điều này cho phép nhiều thao tác với lịch sử Git được thực hiện ngay cả khi không kết nối Internet.

Vậy để hiểu Git một cách thực tế hơn, chúng ta cần đi sâu vào cách Git lưu trữ và quản lý những thay đổi của source code.

Trước tiên, hãy bắt đầu với Repository, Working Directory, Staging Area và Commit – bốn khái niệm nền tảng mà bất kỳ người mới học Git nào cũng cần nắm rõ.

4 khái niệm nền tảng cần hiểu khi làm việc với Git

Sau khi hiểu Git là gì, câu hỏi tiếp theo sẽ là: Git thực sự quản lý code như thế nào?

Để trả lời câu hỏi này, trước khi tìm hiểu những lệnh phức tạp như branch, merge, rebase hay cherry-pick, chúng ta cần nắm chắc 4 khái niệm nền tảng:

1. Working Directory
2. Staging Area
3. Repository
4. Commit

Có thể hình dung quá trình làm việc với Git như sau:

Working Directory
       │
     git add
       ▼
 Staging Area
       │
   git commit
       ▼
   Repository
       │
    git push
       ▼
 GitHub / Remote

1. Working Directory – nơi bạn trực tiếp làm việc

Working Directory là thư mục project mà bạn đang trực tiếp chỉnh sửa.

Ví dụ một project Frontend:

my-project/
├── src/
│   ├── App.jsx
│   ├── Header.jsx
│   └── Footer.jsx
├── public/
├── package.json
└── README.md

Khi bạn mở project bằng VS Code và bắt đầu sửa Header.jsx, những thay đổi đó đang nằm trong Working Directory.

Git sẽ theo dõi những thay đổi này và cho bạn biết file nào đã được chỉnh sửa thông qua:

git status

Ví dụ:

modified: src/Header.jsx

Điều quan trọng cần nhớ là:

Working Directory là nơi bạn viết và chỉnh sửa code, chưa phải nơi Git lưu thay đổi vào lịch sử.

2. Staging Area – nơi chuẩn bị cho Commit

Sau khi hoàn thành một thay đổi, bạn có thể đưa nó vào Staging Area bằng lệnh:

git add .

Hoặc chỉ thêm một file:

git add src/Header.jsx

Staging Area có thể hiểu đơn giản là một khu vực trung gian để bạn lựa chọn:

Những thay đổi nào sẽ được đưa vào commit tiếp theo?

Ví dụ bạn đã thay đổi 3 file:

Header.jsx
Footer.jsx
Login.jsx

Nhưng hiện tại bạn chỉ muốn commit phần Header:

git add Header.jsx

Lúc này:

Working Directory
├── Header.jsx    → Staged
├── Footer.jsx    → Modified
└── Login.jsx     → Modified

Điều này cho phép bạn kiểm soát chính xác nội dung của từng commit.

3. Repository – nơi Git lưu lịch sử

Repository là nơi Git lưu trữ thông tin và lịch sử của project.

Khi chạy:

git init

Git tạo một thư mục ẩn:

.git/

Thư mục này chứa những dữ liệu cần thiết để Git quản lý repository.

Một repository có thể chứa lịch sử như:

C0 → C1 → C2 → C3

Mỗi commit là một mốc trong lịch sử.

Nhờ repository, Git có thể biết project đã thay đổi như thế nào qua thời gian.

Có thể hiểu đơn giản:

Working Directory
       │
       │ git add
       ▼
Staging Area
       │
       │ git commit
       ▼
Repository
       │
       ├── C0
       ├── C1
       ├── C2
       └── C3

4. Commit – một mốc thay đổi trong lịch sử

Commit là một trong những khái niệm quan trọng nhất của Git.

Khi bạn chạy:

git commit -m "feat: add header"

Git tạo ra một commit chứa những thay đổi đã được đưa vào Staging Area.

Có thể xem commit như một mốc đánh dấu trong lịch sử phát triển của project.

Ví dụ:

C0 → C1 → C2 → C3

Trong đó:

C0: tạo project
C1: thêm Header
C2: thêm Login
C3: hoàn thiện Responsive

Commit message nên mô tả rõ thay đổi được thực hiện.

Ví dụ:

git commit -m "feat: add login page"
git commit -m "fix: fix navbar responsive"
git commit -m "refactor: simplify auth logic"

Thay vì những message quá chung chung:

git commit -m "update"
git commit -m "fix"
git commit -m "done"

Một commit tốt nên trả lời được câu hỏi:

Commit này đã thay đổi điều gì?

Nhìn lại toàn bộ quy trình

Bây giờ chúng ta có thể ghép 4 khái niệm lại thành một quy trình hoàn chỉnh:

       Viết / sửa code
              │
              ▼
      Working Directory
              │
          git add
              │
              ▼
       Staging Area
              │
        git commit
              │
              ▼
         Repository
              │
          git push
              │
              ▼
       GitHub / Remote

Ví dụ trong một project thực tế:

# Kiểm tra thay đổi
git status

# Đưa thay đổi vào staging
git add .

# Tạo commit
git commit -m "feat: add login page"

# Đẩy commit lên GitHub
git push

Chỉ với 4 khái niệm này, bạn đã có nền tảng để hiểu phần lớn workflow Git cơ bản.

Sau đó, những khái niệm như Branch, Merge, Rebase, Pull Request và Code Review sẽ trở nên dễ hiểu hơn rất nhiều.

Git và GitHub thường được nhắc đến cùng nhau đến mức người mới rất dễ nghĩ rằng chúng là một. Tuy nhiên, chúng đảm nhận hai vai trò khác nhau.

Git là công cụ giúp developer quản lý phiên bản và lịch sử thay đổi của source code.

GitHub là một nền tảng trực tuyến sử dụng Git, cung cấp nơi lưu trữ repository và nhiều công cụ hỗ trợ cộng tác như Pull Request, Code Review, Issues và CI/CD.

Nếu xem toàn bộ quá trình phát triển phần mềm như một hệ thống:

Git
│
├── Theo dõi thay đổi
├── Commit
├── Branch
├── Merge
└── Rebase

GitHub
│
├── Repository online
├── Pull Request
├── Code Review
├── Issues
└── Collaboration

Vì vậy, thay vì ghi nhớ hàng loạt câu lệnh Git một cách máy móc, điều quan trọng hơn là hiểu Git đang quản lý điều gì và mỗi thao tác đang làm thay đổi trạng thái nào.

Khi đã nắm được nền tảng này, việc học các lệnh nâng cao và quy trình làm việc nhóm với GitHub sẽ trở nên trực quan hơn rất nhiều.

Và đó cũng là lúc Git không còn chỉ là một danh sách các câu lệnh cần ghi nhớ, mà trở thành một công cụ giúp developer kiểm soát code, lịch sử phát triển và quá trình cộng tác trong một dự án phần mềm.

Bài viết khác

Lỗi bảo mật Zero Day trên .net framework và Office kb4041083

Lỗi này khiến cho hacker có thể sử dụng các file office để chiếm quyền điều khiển máy tính windows

Đọc thêm

Cập nhật bản vá chống tấn công krack ( key reinstall attack ) trên windows 7,8,10

Phương thức tấn công krack key reinstall attack mới được phát hiện có thể hack toàn bộ mạng wifi toàn cầu. Người dùng có thể bị mất các thông tin quan trọng như tài khoản email, mật khẩu, thông tin ngân hàng, bị chiếm quyền điều khiển và thậm chí bị đánh cặp dữ liệu […]

Đọc thêm