Git là gì mà lại giúp bạn và cả team làm việc tốt hơn?

Bài viết được sự cho phép của tác giả Phạm Bình

I. Từ vấn đề cho tới GIT là gì

1.1 Vấn đề

Chúng ta cùng tìm hiểu vấn đề thông qua một ví dụ do mình bịa ra như sau:

Bình và Sơn làm chung một dự án website thương mại điện tử, sau khi nhận yêu cầu, Bình và Sơn chia nhau công việc. Cách làm việc là mỗi khi có ai code xong một phần tính năng, thì sẽ copy code của mình gửi cho người kia thông qua USB để ghép vào dự án chung.

Thời gian đầu, code chưa có gì phức tạp, Bình và Sơn vẫn trao đổi code của mình qua USB bình thường. Nhưng sau một thời gian, code trở nên phức tạp, Bình và Sơn liên tục gặp sai sót trong quá trình copy code qua lại cho nhau, và tốn thời gian để giải quyết các sai sót đó. Vì không nghĩ đến điều này, nên dự án của Bình và Sơn bị thất bại do quá hạn deadline.

Tuy là ví dụ hư cấu, nhưng trong thực tế vẫn có các tình huống tương tự như vậy xảy ra, và trong cuộc đời của mỗi developer, thì hầu hết mọi người đều từng có một lần trao đổi và ghép code qua USB như vậy.

Quay trở lại với ví dụ về Bình và Sơn, dự án thất bại là do quá hạn deadline, mà nguyên nhân sâu xa là do cách làm việc không tốt. Khi copy code qua lại với nhau như vậy, việc xảy ra sai sót cũng là điều dễ hiểu vì:

• Sẽ rất khó để ghép code, khi cả 2 người cùng sửa trên một file, và còn khó hơn khi hai người cùng sửa trên một dòng.
• Code có thể bị “rơi rụng” (copy thiếu) trong lúc ghép code.
• Với những tính năng nhiều code, thì thời gian ghép code có thể mất cả ngày.

Thực tế, khi làm việc theo cách của Bình và Sơn (hay cách nào tương tự vậy) thì còn có nhiều hạn chế khác bên cạnh các hạn chế kể trên:

• Khó khăn khi bổ sung thêm người mới vào code cùng, càng nhiều người làm thì tỉ lệ sai sót càng cao.
• Tốn thời gian để giải quyết các sai sót không đáng có.
• Khó làm việc độc lập.

Vậy giải pháp cho các vấn đề trên là gì? Chính là GIT

1.2 Git là gì?

Để tìm hiểu GIT là gì, trước tiên mình muốn bạn biết về VCS là gì trước.

VCS – Version Control System (Hệ thống quản lý phiên bản). Cái tên VCS đã phần nào nói lên tính năng của hệ thống này, VCS sẽ lưu lại toàn bộ mã nguồn và ghi chép đầy đủ trạng thái thay đổi của các file, với từng trạng thái thay đổi mỗi file, đều được log lại thành một phiên bản.

Ví dụ dự án A có 10 thay đổi, thì VCS sẽ log lại thành 10 phiên bản khác nhau, và bạn có thể xem lại các phiên bản này.

Lưu ý: VCS ám chỉ một dạng hệ thống, chứ không phải tên một hệ thống cụ thể.

GIT đơn giản là một hệ thống thuộc dạng VCS. Tức là ngoài GIT ra vẫn còn nhiều hệ thống khác tương tự như GIT. Nhưng ngày nay, khi nói tới VCS, người ta chỉ hình dung tới GIT, vì GIT có một số đặc điểm nổi bật hơn các VCS khác. Tuy nhiên dưới góc độ của một người mới bắt đầu tìm hiểu về VCS nói chung và GIT nói riêng, mình cho rằng bạn sẽ không quan tâm tới việc so sánh GIT với các VCS khác, nên mình xin phép không đề cập tới phần này. Chúng ta tạm thời khẳng định với nhau rằng “GIT là lựa chọn thích hợp nhất cho một VCS trong thời điểm hiện tại“.

1.3 Vai trò của GIT trong phát triển phần mềm

Ngày nay, bất kỳ dự án phần mềm nào cũng nên áp dụng GIT, vì GIT giúp giải quyết một số vấn đề quan trọng sau:

Là nơi lưu trữ source code
Hãy tưởng tượng GIT là một “đám mây” lưu trữ như Google Drive, Dropbox, tuy nhiên GIT được thiết kế riêng để lưu trữ source code.

Quản lý phiên bản source code
Hãy tưởng tượng bạn đang phát triển một sản phẩm có rất nhiều người sử dụng. Vì sản phẩm có nhiều người dùng, nên yêu cầu tính ổn định phải cực kỳ cao. Vì yêu cầu tính ổn định cao, nên bạn không được phép code trực tiếp vào phiên bản source code đang chạy ổn định, mà phải code vào một phiên bản khác – gọi là phiên bản dev. Trong lúc bạn đang code ở phiên bản dev, thì phiên bản chạy ổn định vẫn có các cập nhật hằng ngày. Vậy vấn đề gặp phải là làm sao để có thể phát triển được nhiều phiên bản source cùng lúc. Thì với GIT, việc phát triển nhiều phiên bản cùng lúc vô cùng dễ dàng, việc code thêm ở phiên bản này sẽ không ảnh hưởng tới code ở phiên bản khác.

Có thể merge code (ghép code) từ nhiều người
Đây chính là một trong những lý do quan trọng nhất khiến người ta sử dụng VCS nói chung và GIT nói riêng. Với GIT, việc merge code từ nhiều người có thể diễn ra tự động, nếu trong quá trình merge code mà có xảy ra xung đột (mà GIT gọi là conflict) thì GIT sẽ cảnh báo để chúng ta biết.

Blame code (vui thôi nhé)
Giả sử bạn phải sửa code của người khác, khi đọc code, bạn phát hiện một đoạn code ngu kinh khủng, bạn muốn tìm xem ai là người code đoạn này để chửi cho bõ tức. Thì GIT có thể cho bạn biết đó là kẻ nào.

Tham khảo Job FrontEnd HOT trên TopDev!

1.4 Làm việc với GIT như thế nào

Một số khái niệm

Để biết cách làm việc với GIT, mình sẽ chỉ bạn mấy khái niệm cơ bản trong GIT trước:

• Repository (hay nhiều người gọi tắt là repo): Là nơi lưu trữ source code, mỗi repository sẽ đại diện cho một dự án. Repository sẽ chia làm 2 loại, là Local repository và Remote repository.
• Local repository: Là repository được đặt trên máy tính của bạn.
• Remote repository: Là repository được đặt trên GIT server.
• Init repository: Là thao tác khởi tạo một Local repository.
• Clone: Là thao tác nhân bản một Remote repository thành Local repository trên máy của bạn.
• Branch (Nhánh): GIT quản lý các phiên bản source dưới dạng cây có nhiều nhánh, mỗi nhánh là một phiên bản. Các nhánh có thể được tách ra, hoặc ghép vào nhau. Branch trong GIT được chia làm 2 loại, là branch master (nhánh chính) và các branch khác do bạn tạo ra trong quá trình làm việc.
• Branch master: Là nhánh đầu tiên khi khởi tạo một GIT repository, branch master thường là nơi chứa source code đang chạy ổn định.
• Checkout: Là thao tác chuyển qua chuyển lại giữa các branch. Khi nói “checkout master branch”, nghĩa là chuyển sang nhánh master.
• Pull (kéo): Là thao tác đồng bộ code từ Remote repository xuống Local repository.
• Commit: Là thao tác “xác nhận” một sự thay đổi của code. Thường thì mỗi tính năng sau khi được hoàn thiện sẽ thực hiện một commit.
• Push (đẩy): Là thao tác đồng bộ code từ Local repository lên Remote repository.
• Merge: Là thao tác ghép code lại với nhau.
• Conflict: Là sự xung đột khi merge code.

Cách làm việc với GIT

Phần này mình sẽ trình bày một số thao tác và đặc điểm cơ bản khi áp dụng GIT trong dự án:

• Git được cài đặt sẵn trên Linux và hỗ trợ các hệ điều hành phổ biến, bạn có thể download GIT miễn phí ở đây.
• GIT nên được sử dụng trên Command Line thay vì các phần mềm hỗ trợ GIT trên GUI.
• GIT có thể có nhiều Remote repository và Local repository. Remote repository sẽ đặt ở trên GIT server, còn Local repository đặt trên máy của bạn. Remote repository và Local repository sẽ được liên kết với nhau.
• GIT quản lý tất cả các sự thay đổi như: thêm file mới, sửa file, xóa file, chmod thư mục,… bất kỳ điều gì làm thay đổi source code đều được GIT quản lý.
• Khi bạn code, bạn sẽ code trên trên Local repository. Sau khi code xong tính năng, bạn thực hiện thao tác commit để xác nhận sự thay đổi của code.
• Để đẩy các commit từ Local repository lên Remote repository, bạn sử dụng thao tác push. Các thành viên khác trong team muốn cập nhật các code mới do bạn bổ sung, thì thực hiện thao tác pull để đồng bộ code từ Remote repo về Local repo của họ.
• Khi pull code từ Remote repo về Local repo sẽ xảy ra thao tác merge code. Nếu không bị conflict code giữa Local repo và Remote repo, việc merge code sẽ diễn ra tự động, nếu xảy ra conflict, GIT sẽ thông báo cho bạn biết.
• Nếu bạn muốn khởi tạo một Local repo từ Remote repo thì sử dụng thao tác clone.
• Branch master đang hoạt động ổn định, bạn không muốn code trực tiếp trên branch master, thì từ nhánh master bạn có thể tạo ra một nhánh khác – tạm gọi là nhánh xxx. Nhánh xxx lúc này chứa toàn bộ code của nhánh master, bạn có thể thoải mái thực hiện các thao tác commit, push, pull trên nhánh này mà không làm ảnh hưởng tới nhánh master. Khi tính năng trên nhánh xxx hoạt động ổn định, bạn có thể yên tâm merge code ở nhánh xxx vào nhánh master.

II. Git với Github

Chắc sẽ có nhiều bạn bị nhầm lần giữa GIT và Github.

Thực ra GIT và Github vốn không thể so sánh với nhau, vì GIT là tên một hệ thống, còn Github là tên một đơn vị cung cấp dịch vụ GIT. Có thể hiểu nhanh rằng GIT và Github cũng tương tự như Porn và Pornhub vậy.

Như mình đề cập ở trên, git có 2 dạng repository là Local repo được đặt trên máy của các lập trình viên, và Remote repo được đặt trên GIT server. Điều này có nghĩa là, để sử dụng GIT, thì việc cài đặt GIT trên máy tính của bạn là chưa đủ, bạn cần phải có một server đóng vai trò như một GIT server nữa, và Github là đơn vị cung cấp GIT server miễn phí bạn.

Thực tế thì Github còn có nhiều tác dụng hơn là cung cấp GIT server miễn phí. Với cộng đồng lập trình viên nói chung, Github còn giống như một mạng xã hội. Có điều mạng xã hội này show project thay thì show status hay show ảnh, nút like được thay bằng nút star, phần comment thì được thay bằng issues 

III. Cách sử dụng GIT cơ bản

Phần này mình sẽ hướng dẫn các bạn cách sử dụng GIT, cụ thể chúng ta sẽ sử dụng dịch vụ GIT miễn phí của Github – Một trong những nền tảng cung cấp dịch vụ GIT phổ biến nhất hệ mặt trời.

Trước tiên hãy đảm bảo máy tính của bạn đã cài đặt GIT, bạn có thể kiểm tra bằng cách thực hiện lệnh git --version trong terminal.

git --version

Nếu thấy xuất hiện thông tin phiên bản của GIT, thì có nghĩa là máy tính của bạn đã cài đặt. Ngược lại, bạn phải download và cài đặt GIT vào máy trước khi thực hiện các bước sau đây.

3.1 Đăng ký tài khoản Github.com

Bạn truy cập vào https://github.com/join, điền thông tin vào form để đăng ký tài khoản.

Github sẽ yêu cầu bạn xác thực tài khoản qua email, thế nên hãy để ý mail box của bạn nhé.

Sau khi đăng ký xong, hãy đăng nhập vào Github để chuẩn bị cho bước tiếp theo.

3.1 Tạo repository đầu tiên

Sau khi đăng nhập, bạn tìm nút “New repository” như hình.

Nhấp vào “New repository”, bạn sẽ được chuyển tới trang tạo repository như hình.

Điền các thông tin cần thiết rồi nhấn “Create repository”, trong đó:

• Repository name: Tên repository của bạn, bạn nên nhập dạng “ten-repository”
• Description: Nhập mô tả về repository của bạn, thông tin này để trống cũng được.
• Public hay Private: Public thì bất kỳ ai cũng có thể xem và clone repo của bạn, Private thì chỉ có bạn hoặc những người bạn cho phép mới có thể thực hiện các thao tác đó. Ở đây bạn hãy chọn Public dễ thao tác hơn, chúng ta sẽ tìm hiểu về Private repo sau.

Sau đó, bạn sẽ được chuyển tới trang chi tiết repository như hình.

Vậy là bạn đã tạo thành công một GIT repository.

Đừng vội hoảng loạn với các dòng lệnh khó hiểu mà Github gợi ý cho bạn trong trang này nhé, hãy bình tĩnh đọc chúng và bạn sẽ hiểu thôi.

Cụ thể là bạn vừa tạo xong một Remote repository mới tinh chưa có code, và Github đang gợi ý cho bạn một số cách để đẩy những file đầu tiên lên Remote repository này. Theo như Github gợi ý, thì bạn có 3 cách:

• Cách 1: Tạo một Local repository trên máy tính của bạn, liên kết nó với Remote repository này, tạo commit đầu tiên rồi đẩy commit đó lên nhánh master.
• Cách 2: Nếu bạn có sẵn một Local repository, thì chỉ cần liên kết nó với Remote repository này, và đẩy các commit lên master.
• Cách 3: Import từ một repository khác.

Ở đây mình sẽ thực hiện theo Cách 1. Bạn mở CLI lên và chạy lần lượt các lệnh sau (Hãy đế ý tới phần mình chú thích sau mỗi lệnh nhé).

mkdir my-local-repository # Tạo một thư mục có tên là "my-local-repository"
cd my-local-repository # Di chuyển vào thư mục vừa tạo
echo "# first-repository" >> README.md # Tạo một file README.md với nội dung "# first-repository"
git init # Khởi tạo một GIT Local repository
git add README.md # Thêm file README.md vào commit
git commit -m "first commit" # Xác nhận sự thay đổi
git remote add origin https://github.com/phambinhnet/first-repository.git # Link tới remote repository
git push -u origin master # Đẩy code lên nhánh master

Khi chạy lệnh git push ..., git sẽ yêu cầu bạn nhập username và password.

Sau khi chạy xong, tại trang chi tiết Repository trên Github, bạn tải lại trang sẽ thấy kết quả như hình:

Vậy là bạn đã thực hiện thành công thao tác push code từ Local repository lên Remote repository.

Nếu Local repository của bạn tiếp tục có sự thay đổi và bạn muốn đồng bộ (push) nó lên Remote repository, thì bạn cũng chỉ cần thực hiện lại các bước:

git add <tên file, tên thư mục, . hoặc *> # Thêm các sự thay đổi vào commit
git commit -m "ghi chú về sự thay đổi"
git push origin master

Chi tiết hơn về các lệnh git add, git commit, git push thì mình sẽ trình bày ở phần tiếp theo.

3.2 Add, status, pull, commit, push

git add

Một commit có thể bao gồm nhiều sự thay đổi, để thêm sự thay đổi vào commit, bạn sử dụng lệnh git add pattern. Trong đó, pattern có thể là:

• Đường dẫn tới một file hoặc thư mục
• Sử dụng pattern là * nếu bạn muốn add tất cả sự thay đổi trong thư mục hiện tại (bao gồm cả các thư mục con).
• Sử dụng pattern là . nếu bạn muốn thêm tất cả sự thay đổi

git status

Lệnh git status cho phép bạn xem trạng thái của Local repository hiện tại, như có những file nào mới, có file nào bị chỉnh sửa, có file nào bị xóa,…

Thường thì trước khi sử dụng lệnh git add, mình sẽ chạy một lần lệnh git status để xem Local repo có những sự thay đổi nào, từ đấy mới biết đường mà add.

git commit

Lệnh git commit cho phép bạn xác nhận các sự thay đổi sau khi chúng đã được add. Cấu trúc của một lệnh git commit thường là như sau:

git commit -m "Mô tả về sự thay đổi"

Sau khi chạy xong lệnh git commit, mình cũng thường chạy lại lệnh git status thêm một lần nữa để xem có commit thiếu sự thay đổi nào không, cũng như để đảm bảo là đã commit thành công.

git push

Lệnh git push được sử dụng để đẩy các commit từ Local repo lên Remote repo.

Sau khi commit, thì các code thay đổi vẫn nằm tại Local repo, để đẩy chúng lên Remote repo thì bạn phải sử dụng lệnh git push. Đầy đủ câu lệnh này lên là:

git push origin branch

Trong đó origin là tên remote repository (tên các remote repo cũng thường là origin luôn), còn branch là nhánh muốn đẩy lên. Giả sử mình muốn đẩy các commit lên nhánh master thì mình sẽ chạy lệnh như sau:

git push origin master

git pull

Lệnh git pull được sử dụng để đồng bộ Remote repository về Local repository. Đầy đủ câu lệnh nên là:

git pull origin branch

Với origin và branch được mô tả giống như lệnh git push. Giả sử mình muốn đồng bộ Remote repo từ nhánh master về Local repo thì mình sẽ sử dụng lệnh sau:

git pull origin master

3.3 Branch, checkout

Phần này khá ngắn gọn thôi.

GIT quản lý các phiên bản source qua khái niệm branch, mặc định mỗi GIT repo sẽ có sẵn một branch là branch master.

Để tạo một branch mới, trước tiên bạn cần xác định là branch mới này sẽ được tách ra từ branch nào. Ví dụ mình tạo một branch mới được tách ra từ branch master thì mình sẽ thực hiện các lệnh như sau:

git checkout master # Chuyển qua nhánh master
git checkout -b ten_branch # Tạo branch mới đồng thời chuyển qua branch vừa tạo

Việc tách nhánh để làm việc sẽ khiến bạn quản lý sự thay đổi tốt hơn, cũng như giảm thiểu sai sót. Vì sau khi tách nhánh, bạn có thể thoải mái chỉnh sửa code trên nhánh vừa tách mà không lo ảnh hưởng tới các nhánh khác. Bạn có thể xem hình sau để hiểu rõ hơn (mỗi một chấm xanh là đại diện cho một commit).

Ở hình trên, bạn thấy nhánh new_feature được tách ra từ nhánh master, trên nhánh new_feature có 2 commit. Trước khi nhánh new_feature được merge vào master, nếu 2 commit kia có lỗi thì cũng sẽ không ảnh hưởng tới nhánh master.

IV. Lời kết

Đây là một bài viết dài và có nhiều kiến thức, nếu bạn có đọc một lần mà vẫn chưa hiểu thì cũng là chuyện bình thường. Cá nhân mình biết GIT từ thời năm 2 sinh viên, nhưng mãi cho tới khi ra trường và đi làm mới hiểu thật sự về cách làm việc với GIT. Nếu bạn cảm thấy khó hiểu, thì mình có một vài gợi ý sau:

• Đọc lại lần nữa, chậm rãi, từ từ.
• Đọc cùng người khác để thảo luận.
• Thực hiện theo ví dụ mình trình bày ở mục III.
• Tìm hiểu thêm các bài viết khác về GIT trên google.
• Tham khảo seri bài viết bài bản về GIT của backlog.com
• Hỏi mình ở mục Gửi câu hỏi

Chúc các bạn học tập hiệu quả.

Bài viết gốc được đăng tải tại phambinh.net

Những bài viết liên quan: