6 lợi ích tuyệt vời khi dùng Git

hovanban

Well-known member
Git là gì? Giống các hệ thống quản lý phiên bản khác, Git cũng hỗ trợ quản lý code và lịch sử thay đổi. Tuy nhiên, Git ưu việt hơn vì có khả năng tách nhánh (branch), hỗ trợ rất tốt cho teamwork, những việc như phân chia task, tổng hợp code trở nên dễ dàng hơn nhiều.

Định nghĩa 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). Nhờ Git, việc quản lý code và làm việc nhóm của developer trở nên đơn giản, thuận tiện hơn. Khi được hỏi tính năng yêu thích nhất của Git là gì, anh Hiền cho rằng đối với anh, đó là Git Hooks – Cho phép những đoạn script ở phía client hoặc server có thể được kích hoạt tự động khi bạn chạy một lệnh git.

Ví dụ, bạn có thể cho server chạy tự động mọi unit tests trước khi chấp nhận merge vào nhánh master.
Dĩ nhiên, nó sẽ không viết dùm unit tests “ngon lành cành đào” cho bạn, nhưng tôi nghĩ nó sẽ tạo động lực tốt hơn. Bởi vì test kĩ sẽ giúp đảm bảo rằng các tính năng bạn đang xây dựng không bị phá hỏng bởi những commit khác.

– Anh Vương Đức Hiền
Githooks là một tính năng thú vị của Git.

Sự giống/khác nhau giữa các hệ thống quản lý phiên bản khác và Git là gì?

1. Giống:

Vì Git cũng là một hệ thống quản lý phiên bản (viết tắt: VCS), nên Git hỗ trợ:
  • Quản lý code và lịch sử thay đổi:
Ví dụ, bạn chỉnh sửa code và “trót dại” làm ra một đống bug? Bạn muốn quay trở lại trạng thái trước khi “nghịch ngợm”? Nếu không dùng VCS, bạn sẽ phải sao chép lại file trước khi chỉnh sửa, đồng thời phải thường xuyên cập nhật tên thư mục và tên file.
  • Làm việc nhóm:
Khi các thành viên trong nhóm muốn trao đổi code với nhau nhưng nếu không dùng VCS, họ sẽ phải:
  1. Chép từng module, đoạn code vào usb rồi đưa cho nhau
  2. Hoặc gửi các đoạn code nhỏ qua ứng dụng chat, mail…
Những cách trên đều rất thủ công, tốn resources và tiềm ẩn nhiều rủi ro. Các VCS (bao gồm Git) ra đời để khắc phục điều này.

2. Khác:

Git tiếp cận theo hướng phân tán (distributed approach) trong khi các VCS khác tiếp cận theo hướng tập trung (centralized). Điểm khác biệt lớn nhất của Git là gì? Đó là khả năng tách nhánh (branch). Nhờ vào khả năng này mà Git đã mang đến những tính năng vượt trội dưới đây.

Những tính năng ưu việt của Git là gì so với SVN?

Nhờ tiếp cận theo hướng phân tán, Git mang đến những lợi ích vô cùng to lớn như hỗ trợ rất tốt cho teamwork, phân chia task, tổng hợp code trở nên dễ dàng hơn nhiều, cụ thể:

1. Sắp xếp công việc tốt hơn

Nghĩa là, bạn có thể tập trung giải quyết từng task mà không phải bận tâm lo lắng cho những task liên quan. Nếu không dùng Git, khả năng cao là mọi người sẽ làm việc giẫm chân nhau, những task sắp hoàn thành sẽ bị trì hoãn. Ngoài ra, tất cả mọi task lớn nhỏ sẽ buộc phải hoàn thành hết trước khi deploy, bởi vì chỉ cần 1 task vẫn đang dang dở, cả phần mềm có thể bị sập.

2. Linh hoạt hơn khi phải làm cùng lúc nhiều task

Bởi vì bạn có thể cấu trúc công việc dễ dàng hơn nên việc làm nhiều task cùng lúc vô cùng dễ dàng. Ví dụ, cùng một lúc, chúng ta thường có một team làm tính năng mới, một vài team khác nâng cấp các tính năng hiện có, và một người fix bug. Git hỗ trợ rất tốt cho làm việc nhóm

3. Tự tin hơn khi thử nghiệm những ý tưởng mới

Bạn có thể tách biệt việc thử nghiệm với dự án chính, điều này giúp nâng cao chất lượng code cũng như tính sáng tạo. Nhìn chung, hiện nay Git được coi là tiêu chuẩn bất thành văn trong ngành. Nếu chưa biết về Git, bạn nên dành thời gian để bắt đầu tìm hiểu ngay. Vì, sớm hay muộn, bạn cũng sẽ thuộc về một team phải dựa dẫm vào nó.

4. Git cho phép chúng ta làm việc offline

Theo anh Thành Nhân, ở thời điểm hiện tại thì Git ưu việt hơn hẳn so với các hệ thống quản lý phiên bản tập trung như SVN. Ví dụ, Git cho phép chúng ta làm việc offline trong một khoảng thời gian. Bạn chỉ cần internet cho nhu cầu hợp tác nhóm, hoặc lưu lịch sử commit code lên remote repos. Ngược lại, với SVN, mỗi khi sử dụng đều cần có kết nối đến máy chủ SVN.

5. Cách lưu trữ thông tin

Anh Jonathan chia sẻ rằng nếu so sánh với SVN và TFS, rõ ràng là Git hơn hẳn. Sự khác biệt cốt lõi trong cách quản lý storage và các nhánh của Git khiến cho việc merging cũng hoàn toàn khác.

Bên cạnh đó, cũng nhờ cách Git lưu trữ thông tin mà bạn có thể thực hiện vô vàn những điều thú vị để viết lại lịch sử commit.

Bổ dung thêm về tính năng này, anh Thành Nhân đưa ra một ví dụ khác. Khi tách nhánh, Git chỉ sử dụng 41 bytes cho một nhánh mới, giúp tiết kiệm không gian lưu trữ mà vẫn đảm bảo tốt nhu cầu công việc. Còn SVN, theo tôi biết, sẽ copy toàn bộ source code thành một bản mới khi tách nhánh.

6. Git miễn phí

Anh Đức Hiền cho rằng, nguyên do mà Git được yêu thích đến như vậy phần lớn là vì Git miễn phí. Nghĩa là, mọi người đều có thể bắt đầu sử dụng những chức năng cơ bản của Git mà không cần bất kì cơ sở hạ tầng server nào. Ngay cả Microsoft cũng đã bắt đầu dùng Git để host Windows source code.

Đặc biệt, Git được “sinh sau đẻ muộn” hơn nhiều, cho nên tốc độ phát triển nhanh chóng của nó lại càng đáng kinh ngạc.

Những lưu ý khi làm việc với Git là gì?
  • Phải tìm hiểu các nguyên tắc cốt lõi của Git
“Không có gì tệ hơn cảnh đang vắt giò lên cổ chạy deadline, mà vẫn còn phải quằn quại học cách dùng Git. Tốt hơn hết, bạn nên dành thời gian để tìm hiểu Git trước, rồi thử dùng với một vài dự án thử nghiệm, để tránh làm ảnh hưởng đến công việc chính. Hãy tìm hiểu Git là gì và giá trị của Git trước!”
– Anh Jonathan Khor
Anh Jonathan gợi ý bạn nên đọc cuốn Pro Git. Bạn không cần đọc cuốn sách này để biết cách dùng Git, nhưng nếu muốn sử dụng Git hiệu quả, bạn nên đọc kĩ.

Để tóm tắt lại, nếu là newbie, có 3 điều cơ bản bạn cần tìm hiểu/ghi nhớ về Git là gì?

  1. Git là một đồ thị có hướng và không có vòng lặp
  2. Commit có tính bất biến
  3. Các nhánh chỉ là con trỏ. Mọi điều còn lại đều bắt nguồn từ đây
  • Không nên áp dụng cách dùng CVS và SVN vào Git
Jonathan: Ví dụ như các nhánh. Với Git, nhánh chỉ là các con trỏ đến các commit, còn với SVN thì chúng là bản copy của toàn bộ thư mục. Giải pháp: hãy tìm hiểu Git kĩ hơn! Quay trở lại với lưu ý trên.

Thành Nhân: Không phân biệt được local repo, remote repo, vẫn áp dụng tư tưởng của SVN khi dùng Git.

Đức Hiền: Còn tôi cảm thấy một vài IDEs, ví dụ như Eclipse, được thiết kế để hoạt động với hệ thống CVS cũ kĩ, nhưng lại gắn cách dùng của Git lên. Vì vậy, việc tích hợp không được thực sự thuận tiện như những tính năng khác của Git. (CVS – Concurrrent Versions System, hệ thống quản lý các phiên bản phần mềm mã nguồn mở từ những năm 1980).
  • Những lưu ý khi commit
Với anh Thành Nhân, anh cho rằng đừng nên commit vô tội vạ khi chưa biết các biện pháp dọn lại commit tree, gây rối commit log. Cách phòng ngừa tốt nhất là xem kỹ tài liệu về phần này, đồng thời test thử trên các dự án demo. Riêng phần commit log, trong team nên có thống nhất trước, hoặc nên nhờ người có kinh nghiệm hướng dẫn.

Có những người commit “vô tội vạ“, nhưng cũng có người quên phải commit. Và đó chính là anh Jonathan.
Khi reset một nhánh, tôi quên commit các thay đổi. Vậy là đổ xuống sông xuống biển mọi thứ đã làm.
Từ đó trở đi, trước khi reset một nhánh, tôi luôn viết thêm một lệnh để commit các thay đổi trước, rồi mới reset. Bằng cách này, nếu muốn xem lại những thay đổi trước đó, tôi có thể dùng reflog.
  • Những lưu ý khi check-in
Đây là những lưu ý của anh Đức Hiền từ chính kinh nghiệm, sai lầm của bản thân anh:
  1. Check in những files không thực sự liên quan vào một VCS: Việc này đặc biệt hay xảy ra với các dự án Python, khi mọi người check in các .pyc files của họ. Bạn có thể thiết lập .gitignore để lờ chúng đi. Và cũng nên dùng githooks để dọn dẹp chúng lúc đổi nhánh.
  2. Check in những thứ hoàn toàn không nên: Ví dụ, mọi người rất hay hardcode mấy thứ như mysql passwords. Về khía cạnh bảo mật, lỗi này đúng là kinh dị. Mặt khác, nó cũng có nghĩa là bạn không thể chạy các chương trình tích hợp liên tục (Continuous Intergration – CI) vì tài khoản trong môi trường production (mong là) khác với môi trường test.
  3. Quên không check-in code mới: Hậu quả là mấy ngày làm việc thành công cốc, chỉ vì không để ý đến cảnh báo của Git. Và trong trường hợp này, điều duy nhất có thể làm là rút kinh nghiệm để không lặp lại sai lầm tương tự mà thôi.
  • Phân nhánh thường xuyên
Dù chỉ làm việc một mình, bạn vẫn nên “branch early, branch often”, đừng nên làm mọi thứ trên nhánh master để:
  1. Tránh hình thành thói quen xấu
  2. Tận dụng được tính năng xịn nhất của một VCS
Hãy chắc chắn là bạn có một nhánh staging với các tính năng đã được unit test đầy đủ trước khi nhập vào nhánh master.
  • UI của Git cần được cải thiện
Cá nhân anh Jonathan thấy rằng, UI của Git chưa thật sự tốt và không cung cấp đủ những tính năng nâng cao mà một người developer có thể cần.
  1. Giao diện để rebase một nhánh rất sơ sài: Có vẻ như chúng chỉ hợp với nhu cầu sử dụng cơ bản. Bên cạnh đó, khi xảy ra lỗi thì không phải lúc nào chúng cũng được xử lý tốt.
  2. Việc hiển thị những thay đổi trên files hay change sets: Hầu hết UI hiển thị chúng theo hàng ngang, với phiên bản cũ ở trên và phiên bản mới ở dưới. Lẽ ra họ nên đổi thành hiển thị theo hàng dọc thì sẽ dễ theo dõi hơn. Chưa hết, một số UI cho phép sử dụng chương trình bên ngoài như Beyond Compare để xem sự thay đổi, nhưng một số UI khác thì không.
  3. Mở file đang xem trong IDE cũng chưa thực sự tốt: Không phải UI nào cũng cho phép thao tác này chỉ với phím tắt hay double click. Trong khi, một người developer phải review code hàng ngày, và tính năng này cực kì quan trọng vì sẽ giúp họ chuyển đến ngay file đang xem.
CÔNG TY TNHH TƯ VẤN TRUYỀN THÔNG MINARA
ĐỊA CHỈ:
- 182 Trần Bình Trọng, P.3, Q.5, Tp.HCM
- 27 Đường số 16, Trung Tâm Hành Chính Dĩ An, Bình Dương.
Điện thoại: 097.777.1060
Email: info@minara.vn
Website: www.minara.vn
 
Bên trên