Hướng dẫn

Cách dùng Git với ứng dụng được AI xây dựng

Để dùng Git với ứng dụng do AI xây dựng, hãy kết nối dự án với một kho Git (repository), commit sau mỗi thay đổi chạy được, viết thông điệp một dòng nói rõ điều gì đã thay đổi, và giữ bí mật ngoài Git bằng .gitignore. Dùng nhánh (branch) cho mọi việc rủi ro, pull trước khi nhập lệnh mới nếu người khác đã thay đổi mã, và khi AI làm hỏng thứ gì, hãy quay lại commit tốt gần nhất thay vì tiếp tục lệnh chồng lên đống lộn xộn.

Git là hệ thống quản lý phiên bản: một lịch sử của mọi phiên bản mã nguồn đã lưu. GitHub là trang web lưu trữ các kho Git trực tuyến. Nếu bạn mới làm quen, hãy bắt đầu với GitHub là gì. Hướng dẫn này nói về những thói quen giúp Git hữu ích khi AI viết phần lớn mã.

Vì sao Git quan trọng hơn khi có AI

AI có thể thay đổi hai mươi file trong một lượt. Điều đó nhanh, nhưng cũng có nghĩa là một lệnh có thể âm thầm làm hỏng thứ bạn đã kiểm tra hôm qua. Git cho bạn:

  • Một cách quay lại. Mọi phiên bản đã commit đều có thể khôi phục.
  • Một bản ghi về những gì đã thay đổi. Bạn có thể thấy chính xác file và dòng nào bị một lệnh chạm tới.
  • Một bản sao bên ngoài công cụ xây dựng. Mã của bạn nằm ở nơi bạn kiểm soát.
  • Một cách bàn giao chuẩn. Mọi lập trình viên, dịch vụ hoặc công cụ đều có thể làm việc từ một kho Git.

Bước 1: Kết nối một kho mã

Tạo một kho (thường là riêng tư) trên GitHub hoặc dịch vụ tương tự, rồi kết nối dự án với kho đó. Hầu hết công cụ xây dựng app AI hỗ trợ Git đều làm việc này qua trang cài đặt có nút "Connect GitHub". Nếu công cụ của bạn không có, bạn có thể xuất mã và tự đẩy lên, hoặc nhờ lập trình viên thiết lập một lần.

Trước lần push đầu tiên, hãy chắc chắn kho bỏ qua những thứ không nên có trong đó:

Kiểm tra file .gitignore. Đảm bảo nó loại trừ file .env, node_modules, thư mục đầu ra build và mọi file chứa bí mật. Cho tôi biết bạn đã thêm gì.

Bước 2: Commit sau mỗi thay đổi chạy được

Commit là một ảnh chụp đã lưu kèm thông điệp. Thói quen quan trọng nhất: commit khi có thứ gì đó chạy được, trước khi yêu cầu thứ tiếp theo.

  1. Nhập lệnh cho một thay đổi.
  2. Kiểm tra trong bản xem trước.
  3. Nếu chạy được, commit (hoặc đồng bộ) kèm thông điệp.
  4. Rồi chuyển sang việc tiếp theo.

Commit nhỏ nghĩa là khi có gì hỏng, bạn biết thay đổi nào gây ra, và việc hoàn tác không làm mất các phần việc khác.

Bước 3: Viết thông điệp dễ đọc lại sau này

Một thông điệp tốt nói rõ điều gì đã thay đổi và vì sao, trong một dòng:

  • Tốt: Thêm xuất CSV cho trang đơn hàng
  • Tốt: Sửa lỗi form đặt lịch từ chối giờ sau 18h
  • Không hữu ích: update, changes, fix stuff

Bạn có thể nhờ AI viết chúng:

Tóm tắt các thay đổi kể từ commit trước trong một dòng, bắt đầu bằng một động từ, dưới 70 ký tự.

Bước 4: Dùng nhánh cho việc rủi ro

Nhánh (branch) là một dòng công việc riêng. Bạn có thể thử điều gì đó trên nhánh, và nếu không ổn, bỏ đi mà không chạm tới phiên bản chính.

Hãy dùng nhánh khi:

  • Thay đổi lớn (thiết kế lại, luồng thanh toán mới, thay đổi cơ sở dữ liệu).
  • Có người khác đang làm việc trên cùng ứng dụng.
  • Bạn muốn ai đó xem xét thay đổi trước khi đưa lên thật.

Khi công việc đã xong và được kiểm tra, nó sẽ được merge trở lại nhánh chính. Trên GitHub, việc này thường diễn ra qua pull request, một trang hiển thị các thay đổi để xem xét. Nếu công cụ xây dựng chỉ đồng bộ một nhánh, lập trình viên có thể quản lý các nhánh phía GitHub.

Bước 5: Hoàn tác an toàn

Khi một lệnh làm hỏng ứng dụng, đừng vội nhập thêm năm lệnh chồng lên nó. Hãy quay lại phiên bản tốt gần nhất và thử một lệnh rõ ràng hơn.

  • Trong công cụ xây dựng: dùng tính năng checkpoint hoặc khôi phục, nếu có.
  • Trong Git: git revert tạo một commit mới để hoàn tác một commit cũ, giữ nguyên lịch sử. Đây là lựa chọn an toàn cho mã mà người khác có thể đã pull về.
  • Tránh git push --force trên nhánh dùng chung trừ khi bạn hiểu rõ lý do. Nó viết lại lịch sử cho mọi người.

Nếu chưa chắc, hãy hỏi:

Thay đổi cuối cùng làm hỏng trang đăng nhập. Hãy cho tôi biết file nào đã bị thay đổi so với commit trước, và giải thích từng thay đổi làm gì. Chưa sửa gì cả.

Bước 6: Pull trước khi nhập lệnh

Nếu lập trình viên hoặc công cụ khác thay đổi mã trên GitHub, công cụ xây dựng AI sẽ không biết cho đến khi bạn pull các thay đổi đó về. Nhập lệnh trên mã cũ sẽ gây xung đột và mất công việc.

  • Pull ở đầu mỗi phiên làm việc.
  • Thống nhất ai sửa file nào, và tránh hai bên cùng sửa một file cùng lúc.
  • Nếu gặp merge conflict (hai thay đổi trên cùng dòng), hãy nhờ lập trình viên hoặc AI giải quyết và giải thích lựa chọn.

Ví dụ lệnh

Trước khi bắt đầu: kể từ phiên làm việc trước, kho đã thay đổi gì? Tóm tắt các commit.

Thực hiện thay đổi tiếp theo một mình: thêm nút "Nhân bản" vào mỗi hóa đơn. Đừng thay đổi gì khác, để tôi commit riêng.

Kiểm tra xem không có khóa API, mật khẩu hay file .env nào đang được Git theo dõi, kể cả trong các commit cũ. Chỉ báo tên file, không báo giá trị.

Những lỗi thường gặp

  • Commit bí mật. Khi khóa đã nằm trong lịch sử Git, nó bị lộ ngay cả khi bạn xóa file. Hãy thay mới khóa.
  • Một commit khổng lồ mỗi tuần. Bạn không thể hoàn tác một thay đổi mà không hoàn tác tất cả.
  • Thông điệp kiểu "update". Lịch sử trở nên vô dụng khi cần tìm thứ đã làm hỏng.
  • Nhập lệnh trên mã cũ. Hãy pull trước khi người khác đang sửa.
  • Force-push để sửa lỗi. Điều này có thể xóa công việc của người khác. Hãy revert.
  • Commit node_modules. Nó rất lớn và dù sao cũng được tạo lại từ file lock.

Danh sách kiểm tra

  • Dự án được kết nối với một kho riêng tư.
  • .gitignore loại trừ .env, node_modules, thư mục build và bí mật.
  • Tôi commit sau mỗi thay đổi chạy được.
  • Thông điệp commit nói rõ điều đã thay đổi trong một dòng.
  • Thay đổi lớn hoặc rủi ro được đưa vào nhánh và được xem xét.
  • Tôi pull trước khi nhập lệnh khi có người khác cùng sửa mã.
  • Tôi hoàn tác bằng checkpoint hoặc git revert, không force-push.
  • Mọi khóa từng bị commit đã được thay mới.

Git trên Mythex

Mythex lưu một git checkpoint sau mỗi lượt agent thành công, và Quay lại thời điểm này đưa dự án về đúng điểm đó, tức là cách hoàn tác phía công cụ xây dựng đã mô tả ở bước 5. Xem Lặp lại mà không cần xây lại.

Trên gói Pro, đồng bộ GitHub kết nối một kho từ cài đặt dự án để bạn push và pull với kho đó, còn xuất tải dự án xuống với bí mật và node_modules được loại trừ. Xem GitHub, xuất và nhập. Kết nối GitHub trước khi giao dự án cho lập trình viên sẽ làm việc bàn giao dễ dàng hơn nhiều. Xem cách làm việc với lập trình viên trên ứng dụng do AI xây dựng và cách xuất và tự lưu trữ ứng dụng do AI xây dựng.

Câu hỏi thường gặp

Tôi có cần Git nếu công cụ xây dựng app AI đã có checkpoint không?

Checkpoint giúp hoàn tác trong lúc bạn xây dựng. Git tạo thêm một bản sao mã nguồn bên ngoài công cụ xây dựng, một lịch sử mà người khác có thể đọc, và cách chuẩn để lập trình viên hoặc công cụ khác làm việc trên cùng mã nguồn. Nếu ứng dụng quan trọng, hãy dùng cả hai.

Tôi nên commit bao lâu một lần khi xây dựng bằng AI?

Sau mỗi thay đổi chạy được, thường là sau mỗi lệnh thành công hoặc một nhóm lệnh nhỏ. Commit nhỏ giúp bạn dễ tìm và hoàn tác đúng thay đổi làm hỏng thứ gì đó.

Những gì không bao giờ được commit lên Git?

Khóa API, mật khẩu, file .env chứa giá trị thật, và các thư mục phụ thuộc đã cài đặt như node_modules. Hãy thêm chúng vào .gitignore trước commit đầu tiên, và thay mới mọi khóa từng bị commit.

Tôi có thể sửa mã trên GitHub rồi tiếp tục xây dựng bằng AI không?

Có, nếu công cụ xây dựng của bạn có thể kéo thay đổi từ GitHub. Hãy pull trước khi nhập lệnh tiếp theo, để AI làm việc trên mã mới nhất, và tránh việc hai bên cùng sửa một file cùng lúc.

Mythex · Pricing · Xây dựng mọi thứ với AI · Mẫu website và ứng dụng · So sánh Mythex · Thuật ngữ xây dựng ứng dụng bằng AI · Công cụ miễn phí để xây dựng ứng dụng bằng AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو 简体中文 繁體中文(香港) 繁體中文(台灣)