-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local
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ệnhgit 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
-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local