Chia sẻ kiến thức lập trình

Một số kinh nghiệm với Git

Cơn ác mộng ngày mới vào nghề!

Viết mãi về code rồi pattern rồi thì cũng nên viết 1 bài về công cụ quản lý #version của source code mọi người nhỉ, cho nó đa dạng.
Lần đầu tiên mình tiếp xúc với #Git là năm 2012 thì phải, hồi đó mình đang là sinh viên và mình dùng #Github để lưu source code vì hồi đó máy tính của mình không được mạnh cho lắm, chỉ sợ tèo bất cứ lúc nào. Lúc ấy thì cũng chẳng có khái niệm gì về quản lý version, chỉ đơn giản là:

git add .
git commit -m 'update'
git push origin master

Cho đến khi đi làm thì chính sự thiếu hiểu biết về #Git đã khiến mình bao phen đau đớn, và mình tin chắc rằng rất nhiều anh em ở đây cũng từng trải như mình.

Một số kinh nghiệm

Bài viết này mình sẽ nói đến một số đau thương và kinh nghiệm giải quyết vấn đề nhé:

1. Add bừa bãi các file

Hồi đó công ty mình làm dùng #Bitbucket (vì nó miễn phí cho 5 người cho một #private #repository), mình làm #cocos2dx thế là mình làm câu lệnh <git add .> và thế là tất cả file .so, .o toàn là các file rất nặng lên #Bitbucket thế rồi đến một hôm #Repo của mình đến 2GB là giới hạn của Bitbuket, mình không thể làm gì được nữa, tất cả các thành viên khác cũng chịu luôn và hậu quả là mình phảỉ bỏ cái repo đó, tạo một cái repo mới, và commit từ đầu, kinh nghiệm cho mình đó là:
=> Luôn sử dụng file .gitignore để bỏ qua các file không cần thiết, những file được build ra, các file log và các file mặc định của project, nhìn chung là chỉ có add source code lên thôi, cái gì không phải source code thì có thể để ở đâu đó rồi trong file README.md thì ghi hướng dẫn để cài đặt project

2. Merge và làm mất code

Dự án bọn mình cần phát triển nhanh, nên tất cả mọi người chung nhau nhóm dev, đến khi commit thì phải pull của người khác về, và thế là bùm, mất code, bao nhiêu công sức đã bị mất đi mà sau đó tất cả các thành viên phải đi dò dẫm tình tí một là xem đã mất dòng nào ở đâu để khôi phục lại, mà không phải biết mất ngay đâu, lúc deploy code, test thử mới biết, hậu quả là làm ảnh hưởng tới tiến độ dự án và chất lượng của sản phẩm, kinh nghiệm cho mình đó là:

  • Khi merge code luôn luôn phải có mặt người đang bị #conflict source code với mình, vì mình sẽ khó có thể hiểu người khác đang làm gì
  • Trước khi pull thì hãy luôn dùng câu lệnh git stash và sau khi pull xong hãy dùng câu lệnh git stash pop để lấy source code của mình ra, làm như vậy để đảm bảo source code đã được #merge là mới nhất và khi có conflict thì cũng chỉ có conflict do source code của mình gây ra mà thôi tránh mất code của người khác
  • Nếu muốn thực sự an toàn thì hãy tạo ra một nhánh tạm tên là merge, merge trên nhánh đó rồi mới merge vào nhanh dev

3. Commit conflict file

Mình là fan của command line, nhưng mà lúc đó thì ít kinh nghiệm nên cẩu thả sửa không hết các file bị conflict lên #remote, hậu quả là các member khác không thể build và run được, làm ảnh hưởng rất nhiều đến dự án, tất cả mọi người phải dừng commit để mình rollback lại phiên bản trước khi merge, kinh nghiệm cho mình là:

  • Sử dụng công cụ để merge, ví dụ như #Eclipse, hay #Intellij hỗ trợ rất tốt, nếu dùng câu lệnh thì sử dụng git diff --name-only --diff-filter=U để xem có file nào bị conflict nữa không
  • Luôn build lại dự án và test thử lại sau khi đã merge

Đây 3 trong số muôn vàn kinh nghiệm mình đã trải qua thời còn Amateur, mình sẽ chia nhỏ các kinh nghiệm khác ra thành nhiều bài viết đọc cho đỡ chán nhé, 🙂

Lưu ý quan trọng

Theo kinh nghiệm của bản thân, khi anh em dev có sai sót với Git thường tìm cách để giấu nhẹm đi, nhưng điều này cực kì nguy hiểm. Vậy nên khi có sai sót với git xảy ra, chúng ta phải ngay lập tức thông báo cho cả team để tìm hướng giải quyết. Mình đã nhiều lần giấu dốt và giờ nghĩ lại điều đó là không nên, với git thì hầu như ai cũng sẽ gặp sai sót 1 vài lần, từ lớn đến bé, nhẹ thì phải loay hoay giải quyết, commit lại, nặng thì mất code, ăn bug vậy nên khi sử dụng git với team đông người phải thực sự cẩn thận nhé mọi người, 🙂.

Tổng kết

Đối với những anh em làm quản lý dự án thì mình nghĩ biết Git là bắt buộc, bởi vì mỗi commit thì đối với một #PM thì đó là một cột mốc đánh dấu sự phát triển của dự án, phải có trách nhiệm bảo vệ thành quá đó thật cẩn thận để đảm bảo được tiến độ của dự án nhé.

Tham khảo

  1. Ignore files
  2. Các mẫu .gitignore cơ bản
Share: