- Mục tiêu là tạo ra công cụ cộng tác git đơn giản nhất
- Giúp việc chạy máy chủ git tự host trở nên đơn giản như chạy một máy chủ SSH, mà không phải đánh đổi thời gian và công sức của cộng tác viên bên ngoài
- Kết hợp workflow mailing list và pull request
- Muốn tạo ra một công cụ cộng tác vừa đơn giản như tạo patch, vừa có tính tiện dụng của pull request
- Không nhằm tạo thêm một kho mã khác, mà muốn xây dựng một giải pháp git tự host cực kỳ đơn giản để cộng tác với người đóng góp bên ngoài
Những gì cần có
- Những gì chủ sở hữu mã nguồn cần để chạy máy chủ git:
- Một binary golang duy nhất
- Những gì cộng tác viên bên ngoài cần:
- Một cặp khóa SSH
- Trình khách SSH
Vấn đề hiện tại
- Email là một hệ thống phân tán tuyệt vời để gửi và nhận các thay đổi đối với kho git (các bộ patch), nhưng việc onboarding người dùng mới vào mailing list, cấu hình đúng ứng dụng email rồi mới gửi được đóng góp mã nguồn khiến nhiều lập trình viên bỏ cuộc
- Vì cộng tác dựa trên giao thức email nên bộ tính năng bị giới hạn. Ví dụ, không thể chỉnh sửa email, mỗi người dùng một ứng dụng khác nhau, và các ứng dụng đó đều có những giới hạn khác nhau liên quan đến email văn bản thuần và việc tải patch
- Pull request trên Github dễ sử dụng, chỉnh sửa và quản lý, nhưng có nhược điểm là người dùng phải ở trong website Github để thực hiện code review
- Nó phù hợp với các thay đổi nhanh, nhưng khi bắt đầu đọc mã trong trình duyệt web thì xuất hiện khá nhiều bất lợi. Đến một lúc nào đó, việc review mã trong môi trường phát triển cục bộ hoặc IDE sẽ hợp lý hơn
- Có các công cụ và plugin cho phép review PR ngay trong IDE, nhưng để dùng được thì cần rất nhiều công sức
- Ngoài ra, các giải pháp tự host mô phỏng pull request cũng đòi hỏi rất nhiều hạ tầng để quản lý. Cơ sở dữ liệu, website gắn với git, quản trị viên, dịch vụ, v.v.
- Một điểm ma sát lớn khác là người dùng bên ngoài phải tạo tài khoản và đăng nhập trước khi có thể gửi thay đổi mã. Điều này làm tăng đáng kể ma sát không chỉ với cộng tác viên bên ngoài mà còn với chủ sở hữu mã, những người phải cấp phát hạ tầng
- Trước khi gửi PR, nhiều khi còn phải fork kho mã. Sau đó không bao giờ đóng góp lại nhưng vẫn giữ nguyên kho fork mãi mãi. Điều này thật ngớ ngẩn
Giới thiệu Patch Request (PR)
- Muốn tạo một "máy chủ" git tự host có thể gửi và nhận patch mà không gặp sự phiền toái khi cấu hình email hay các giới hạn do giao thức email áp đặt
- Đồng thời cũng muốn workflow chính xoay quanh môi trường phát triển cục bộ. Github đang đưa IDE vào trình duyệt để hỗ trợ workflow, còn ở đây chúng tôi muốn đảo ngược ý tưởng đó bằng cách biến code review trong môi trường phát triển cục bộ thành trải nghiệm hạng nhất
- Có thể xem đây là điểm nằm giữa workflow pull request của Github và việc gửi/nhận patch qua email
- Ý tưởng cốt lõi là tận dụng ứng dụng SSH để xử lý phần lớn tương tác giữa người đóng góp và chủ dự án. Có thể làm mọi thứ ngay trong terminal một cách tiện dụng và đầy đủ chức năng
- Thông báo được thực hiện bằng RSS và mọi thay đổi trạng thái đều dẫn tới việc tạo ra tài nguyên web tĩnh, vì vậy có thể host toàn bộ bằng một máy chủ web tệp đơn giản
Workflow format-patch
- Ở đây công cụ cộng tác cơ bản là format-patch
- Dù là gửi thay đổi mã hay review thay đổi mã thì mọi thứ đều diễn ra từ trong mã
- Cả người đóng góp lẫn chủ sở hữu đều tạo commit mới và tạo patch chồng lên nhau
- Nhờ vậy không cần một trình xem web nơi reviewer có thể "bình luận" vào một dòng của khối mã. Không cần thiết. Chỉ cần áp dụng patch của người đóng góp, viết bình luận hoặc thay đổi mã, tạo patch mới rồi gửi patch đó lên máy chủ git như một "review"
- Luồng này cũng hoạt động hoàn toàn tương tự nếu hai người dùng cùng cộng tác trên một chuỗi thay đổi
- Nó cũng giải quyết vấn đề gửi nhiều bộ patch cho cùng một thay đổi mã. Sẽ có một Patch Request trung tâm duy nhất nơi mọi thay đổi và cộng tác diễn ra
- Có thể tìm cách tận dụng git note để phục vụ review/bình luận, nhưng thành thật mà nói giải pháp đó khá tàn bạo và có vẻ vượt quá mức độ thoải mái của phần lớn người dùng git
- Chỉ cần gửi review bằng mã và viết chú thích vào mã bằng chính ngôn ngữ lập trình đang dùng
- Việc "xử lý" các chú thích này và loại bỏ chúng trong patch tiếp theo là trách nhiệm của người đóng góp
- Tính năng cưỡng chế để xử lý mọi chú thích: nếu trong mã còn chú thích chưa được xử lý thì patch sẽ không được merge. Không thể bỏ qua, nếu không nó sẽ bị đẩy upstream sai cách
Cách Patch Request hoạt động
- Patch Request (PR) là cách đơn giản nhất để gửi, review và chấp nhận thay đổi cho một kho git. Cách hoạt động như sau:
- Người đóng góp bên ngoài clone kho lưu trữ (
git-clone)
- Người đóng góp bên ngoài thay đổi mã (
git-add & git-commit)
- Người đóng góp bên ngoài tạo patch (
git-format-patch)
- Người đóng góp bên ngoài gửi PR lên máy chủ SSH
- Chủ sở hữu nhận thông báo RSS về PR mới
- Chủ sở hữu áp dụng patch từ máy chủ SSH về cục bộ (
git-am)
- Chủ sở hữu viết đề xuất vào mã (
git-add & git-commit)
- Chủ sở hữu pipe patch tới máy chủ SSH để gửi review (
git-format-patch)
- Người đóng góp bên ngoài nhận thông báo RSS về review PR
- Người đóng góp bên ngoài áp dụng lại patch (
git-am)
- Người đóng góp bên ngoài xem lại và xóa các chú thích trong mã
- Người đóng góp bên ngoài gửi thêm một patch khác (
git-format-patch)
- Chủ sở hữu áp dụng patch cục bộ (
git-am)
- Chủ sở hữu đánh dấu PR là đã được chấp thuận và push mã lên
main (git-push)
1 bình luận
Có vẻ đây là một mục mới được thêm vào Pico.sh - bộ sưu tập mã nguồn mở quản lý dịch vụ web qua SSH cho mọi thứ.
Trước đây đã bao gồm những thứ như sau.