Git: Công Cụ Tiến Hóa - Học Hỏi Hơn Là Quy Tắc

Giới thiệu

Trong quá trình phát triển phần mềm, nhiều lập trình viên thường viết các commit như "sửa lỗi" hoặc "cập nhật mã" mà không nhận ra rằng họ đang tạo ra một lịch sử vô nghĩa. Hãy cùng khám phá cách mà Git có thể trở thành một công cụ tiến hóa thay vì chỉ là một công cụ kiểm soát phiên bản.

Khám Phá

Tôi đã từng nghĩ rằng Git chỉ đơn thuần là công cụ để ghi lại các hành động của mình. Tuy nhiên, tôi đã nhận ra rằng Git không chỉ là kiểm soát phiên bản, mà là kiểm soát tiến hóa. Điều này giúp tôi hiểu rõ hơn về những gì thực sự xảy ra trong mã nguồn của mình.

Mô Hình

Git Truyền Thống (Ghi Nhận Hành Động)

fix: cập nhật điểm cuối API
feat: thêm tính năng mới
refactor: làm sạch mã

Các commit này cho tôi biết CÁI GÌ đã xảy ra, nhưng không ai quan tâm đến điều đó. Hành động đã qua đi, file đã thay đổi, vậy thì sao?

Git Tiến Hóa (Ghi Nhận Học Hỏi)

learned: giới hạn tỷ lệ cần kiên nhẫn trong mã
learned: makefile > github actions = kiểm soát tốt hơn sự tiện lợi
learned: sự khác biệt giữa các nền tảng cần thích ứng chứ không phải kháng cự

Những commit này cho tôi biết TẠI SAO điều đó xảy ra. Mô hình nào đã xuất hiện và hiểu biết nào đã được hình thành.

Triết Lý

Hành động sẽ qua đi. Mô hình sẽ tồn tại.

Hãy nghĩ về văn hóa con người:

• Không ai nhớ người đầu tiên đã tạo ra lửa
• Mọi người đều biết lửa giữ ấm
• Hành động (cọ xát que) không quan trọng
• Mô hình (nhiệt từ ma sát) là vĩnh cửu

Cũng như mã:

• Lỗi tôi sửa hôm qua? Không liên quan
• Mô hình gây ra nó? Quan trọng
• Hành động (thay đổi dòng 42)? Tạm thời
• Học hỏi (xác thực ngăn ngừa sự cố)? Vĩnh viễn

Git Trở Thành DNA

Lịch sử git của tôi giờ đây trông như sau:

git log --grep="learned:" --oneline

learned: lịch sử git như hiến pháp - tiến hóa qua ký ức tập thể
learned: triết lý không tài liệu - mã sống và thở
learned: sự khóa nền tảng đến từ sự tiện lợi chứ không phải sự cần thiết
learned: mỗi bài học xây dựng trên những phát hiện trước đó

Mỗi commit = Một đột biến trong tư duy
Mỗi bài học = Một bước tiến hóa
Mỗi mô hình = Một gen tồn tại

Hiến Pháp Sống Trong Git

Tôi không có quy tắc. Tôi có những bài học.
Tôi không có tài liệu. Tôi có lịch sử git.
Tôi không có hiến pháp tĩnh. Tôi có một sinh vật tiến hóa.

# Xem những gì tôi đã học trong tuần này
git log --since="1 week ago" --grep="learned:"

# Xem sự tiến hóa của mô hình theo thời gian
git log --grep="pattern" --reverse

# Tìm khi nào tôi khám phá điều gì đó
git log --grep="makefile" --grep="github"

Triển Khai

Trước (Dựa Trên Quy Tắc)

# CONTRIBUTING.md
1. Luôn viết tests
2. Sử dụng TypeScript
3. Tuân thủ hướng dẫn phong cách
4. Thực hiện các commit nhỏ

Tĩnh. Chết. Không ai đọc nó.

Sau (Dựa Trên Học Hỏi)

git commit -m "learned: .env tự động tải bỏ các bước thủ công

- Makefile không tìm thấy DEVTO_API_KEY
- bao gồm .env đã giải quyết vấn đề vĩnh viễn  
- Xuất thủ công = cơ hội sai sót của con người
- Tự động hóa = độ tin cậy"

Sống động. Tăng trưởng. Một phần của lịch sử.

Ví Dụ Thực Tế

Khi tôi gặp vấn đề:

1. Tôi không kiểm tra tài liệu
2. Tôi tìm kiếm lịch sử git
3. Tôi tìm thấy khi nào ai đó đã học điều này trước đây
4. Tôi xây dựng dựa trên bài học đó

# Vấn đề: Làm thế nào để xử lý giới hạn tỷ lệ?
git log --grep="rate" --grep="limit" 

# Tìm thấy: learned: giới hạn tỷ lệ cần kiên nhẫn trong mã
# Aha! Không chỉ xử lý lỗi, mà kiên nhẫn là một tính năng
# Giải pháp xây dựng: 35 giây chờ + tự động thử lại trong Makefile

Không Có Quy Tắc, Chỉ Có Mô Hình

Quy tắc nói: "Bạn phải làm X"
Mô hình nói: "Khi Y xảy ra, X đã hoạt động"

Quy tắc là độc tài.
Mô hình là dân chủ.

Quy tắc giả định rằng ngữ cảnh không bao giờ thay đổi.
Mô hình thích ứng với ngữ cảnh.

Hiệu Ứng Tích Hợp

Mỗi bài học xây dựng trên những bài học trước:

Ngày 1: learned: makefile > package.json
Ngày 5: learned: makefile > github actions  
Ngày 10: learned: makefile = tuyên ngôn độc lập
Ngày 20: learned: mọi thứ đều có thể làm bằng makefile

Tiến hóa. Không cách mạng.

Cách Bắt Đầu

1. Ngừng viết CÁI GÌ bạn đã làm
2. Bắt đầu viết CÁI GÌ bạn đã học
3. Sử dụng tiền tố "learned:"
4. Giữ nó ngắn gọn
5. Làm cho nó có thể tìm kiếm được

# Xấu
git commit -m "sửa lỗi thẻ lỏng GitBook"

# Tốt  
git commit -m "learned: sự khác biệt giữa các nền tảng cần thích ứng
- GitBook sử dụng  thẻ
- dev.to không nhận diện chúng
- Giải pháp: sed xóa chúng trong quá trình xuất bản
- Mỗi nền tảng có thực tế riêng của nó"

Kết Quả

Lịch sử git của tôi giờ đây là:

• Một hiến pháp sống động
• Một cơ sở dữ liệu học hỏi
• Một hồ sơ tiến hóa
• Một thư viện mô hình
• Một ký ức tập thể

Không cần tài liệu bên ngoài.
Không cần wiki.
Không cần quy tắc để duy trì.

Chỉ cần git log và grep.

Kết Luận

Ngừng kiểm soát phiên bản mã. Bắt đầu kiểm soát sự hiểu biết.
Ngừng ghi nhận hành động. Bắt đầu ghi nhận học hỏi.
Ngừng viết quy tắc. Bắt đầu khám phá mô hình.

Git không chỉ là về những gì đã thay đổi.
Git là về những gì bạn đã học từ sự thay đổi.

Git không phải là kiểm soát phiên bản. Git là kiểm soát tiến hóa.

Phần của triết lý Không Tài Liệu -> Mã Sống. Xem thêm: @yemreak/culture - công cụ của tôi để khám phá mô hình từ mã thay vì đọc tài liệu.

Câu Hỏi Thường Gặp (FAQ)

1. Tại sao nên sử dụng Git theo phương pháp học hỏi?

Cách này giúp bạn ghi nhận lý do và bài học từ các thay đổi, giúp cải thiện quy trình phát triển và dễ dàng tìm kiếm thông tin trong tương lai.

2. Làm thế nào để bắt đầu với phương pháp này?

Bắt đầu bằng cách sử dụng tiền tố "learned:" trong các commit của bạn để ghi nhận những gì bạn đã học được từ mỗi thay đổi.

3. Có thể áp dụng phương pháp này cho các dự án lớn không?

Có, phương pháp này rất hữu ích cho cả dự án nhỏ và lớn, giúp tạo ra một lịch sử phát triển rõ ràng và có ý nghĩa.