Bạn là lập trình viên, và đôi khi bạn muốn đưa về trạng thái trước khi quậy phá của file code nào đó? Cách đơn giản nhất đó là sao chép lại file trước khi chỉnh sửa. Trường hợp dùng phương pháp này thì sẽ phải thường xuyên thực hiện việc thêm ngày đã thay đổi vào tên thư mục hay file. Tuy nhiên, việc tự mình sao chép file mỗi lần chỉnh sửa thì sẽ rất vất vả, và cũng dễ xảy ra nhầm lẫn. Và để giải quyết những vấn đề này thì các hệ thống quản lý phiên bản như Git đã được ra đời. Git là một trong những Hệ thống Quản lý Phiên bản Phân tán, vốn được phát triển nhằm quản lý mã nguồn (source code) của Linux. Trên Git, ta có thể lưu trạng thái của file dưới dạng lịch sử cập nhật. Vì thế, có thể đưa file đã chỉnh sửa một lần về trạng thái cũ hay có thể biết được file đã được chỉnh sửa chỗ nào.
 Show
Repository hay được gọi tắt là Repo, đơn giản là nơi chứa tất cả những thông tin cần thiết để duy trì và quản lý các sửa đổi và lịch sử của toàn bộ project. Trong Repo có 2 cấu trúc dữ liệu chính là Object Store và Index. Tất cả dữ liệu của Repo đèu được chứa trong thư mục bạn đang làm việc dưới dạng folder ẩn có tên là .git
Đầu tiên, repository của Git được phân thành 2 loại là remote repository và local repository.
Do repository phân thành 2 loại là local và remote nên với những công việc bình thường thì có thể sử dụng local repository. Khi muốn public nội dung công việc mà mình đã làm trên local repository, thì ta sẽ upload lên remote repository rồi public. Thêm nữa, thông qua remote repository bạn cũng có thể lấy về nội dung thay đổi của người khác.
Nguồn ảnh: www.git-tower.com Đây là một trong những thế mạnh của git là nhánh. Với git, việc quản lý nhánh rất dễ dàng. Mỗi nhánh trong Git gần giống như một workspace. Việc nhảy vào một nhánh để làm việc trong đó tương tự việc chuyển qua ngữ cảnh làm việc mới, và sau đó có thể nhanh chóng quay lại ngữ cảnh cũ. Nhánh (branch) được dùng để phát triển tính năng mới mà không làm ảnh hưởng đến code hiện tại. Nhánh master là nhánh “mặc định” khi bạn tạo một repository. Nhánh master thông thường là nhánh chính của ứng dụng. Ví dụ bạn thử nghiệm một tính năng mới và muốn không ảnh hưởng đến code chính bạn có thể tạo một nhánh mới và sau khi xong sẽ hợp nhất lại với nhánh master. Việc hợp nhất 2 nhánh lại được gọi là merge.
Nguồn ảnh: http://rogerdudler.github.io/git-guide/index.vi.html Trộn source từ một nhánh khác vào nhánh hiện tại. Bạn sẽ hiểu sâu hơn về nó trong các ví dụ ở các bài sau. Chú ý:
Conflic là trường hợp có 2 sự thay đổi trong một dòng code và máy tính không thể tự quyết định dòng code nào là “đúng”. Đúng ở đây có nghĩa là “ý đồ của lập trình viên”. Để giải quyết mâu thuẫn bạn phải dùng “tay không” để sữa các xung đột này. Bạn chỉ việc nhìn vào file bị conflict và tự quyết định dòng code nào giữ lại, dòng nào xóa bỏ.
Để ghi lại việc thêm/thay đổi file hay thư mục vào repository thì sẽ thực hiện thao tác gọi là Commit. Khi thực hiện commit, trong repository sẽ tạo ra commit (hoặc revision) đã ghi lại sự khác biệt từ trạng thái đã commit lần trước với trạng thái hiện tại. Commit này đang được chứa tại repository, các commit nối tiếp với nhau theo thứ tự thời gian. Bằng việc lần theo commit này từ trạng thái mới nhất thì có thể biết được lịch sử thay đổi trong quá khứ hoặc nội dung thay đổi đó.
Các commit này, được đặt tên bởi 40 ký tự alphabet (mã md5 thì phải) không trùng nhau được băm từ thông tin commit. Bằng việc đặt tên cho commit, có thể chỉ định commit nào từ trong repository. Mỗi commit đều có yêu cầu phải có commit message, để giải thích commit này là bạn đã làm gì trong này. Để kết nối được với một repo khác người ta sử dụng một khái niệm gọi là remote. Trên thực tế khi làm việc với nhau thì không như vậy, vì không phải máy ai cũng cài một “git server” để người khác kết nối được với mình. Thông thường thì chúng ta sẽ sử dụng một repo chung và các máy kết nối vào repo đó. Có 2 “git repo server” được sử dụng nhiều là github.com và bitbucket.org. Trên thực tế khi có 2 người cùng làm việc với 1 project thì thông thường sẽ tạo một repo trên github hoặc bitbucket và repo trên máy người A sẽ kết nối với repo trên github và máy người B cũng kết nối với repo trên github/bitbucket. Từ đó source code của người A và người B sẽ được đồng bộ với nhau thông qua repo trên github/bitbucket. Vì vậy, trước khi sử dụng git thì bạn nên đăng kí một tài khoản trên github.com hoặc bitbucket.org. Trên Git, những thư mục được đặt trong sự quản lý của Git mà mọi người đang thực hiện công việc trong thực tế được gọi là working tree. Và trên Git, giữa repository và working tree tồn tại một nơi gọi là index. Index là nơi để chuẩn bị cho việc commit lên repository.
Nguồn ảnh: backlogtool Trên Git, khi đã thực hiện commit thì trạng thái sẽ không được ghi trực tiếp trong repository từ working tree, mà sẽ ghi trạng thái đã được thiết lập của index được xây dựng ở giữa đó. Vì thế, để ghi lại trạng thái của file bằng commit thì trước hết cần thông báo file trong index. Còn khá nhiều định nghĩa trên Git, trên đây mình chỉ nói một vài định nghĩa quan trọng, mình sẽ cố gắng cập nhật đầy đủ sau. Ở bài sau mình sẽ hướng dẫn cách sử dụng Git, sử dụng github, các làm việc trên git và xử lý các trường hợp thường gặp khi teamwork với Git. Bài viết được post tại LvDuit Blog và LvDuit Wordpress.
Lưu ý: Đây là một bài viết vô cùng hữu ích giành cho những bạn chưa biết gì về GIT, nhưng lại ít giá trị với những bạn đang đi tìm một seri học GIT đầy đủ. 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ì:
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:
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 (2020), 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ềmNgà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 Quản lý phiên bản source code Có thể merge code (ghép code) từ nhiều người Blame code (vui thôi nhé) 1.4 Làm việc với GIT như thế nàoMộ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:
Cách làm việc với GITPhầ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:
II. GIT vs GithubChắ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ảnPhầ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 --versionNế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.comBạ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ênSau 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 đó:
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:
Ở đâ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 masterKhi 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 masterChi 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, pushgit addMộ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à:
git statusLệ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 commitLệ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 pushLệ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 branchTrong đó 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 mastergit pullLệ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 branchVớ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 master3.3 Branch, checkoutPhầ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ạoViệ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: Chúc các bạn học tập hiệu quả. |
