Squashing Git cam kết

Tôi sử dụng Git mỗi ngày và tôi đã viếtHướng dẫn Gitvà mộtGit Cheat Sheettrong quá khứ.

Tôi coi mình là một người hâm mộ Git, nhưng… tôi không phải là một chuyên gia về Git.

Cam kết, tìm nguồn gốc, kéo nguồn gốc, đẩy về nguồn gốc .. đó là hàng ngày tôi sử dụng Git.

Và tôi làmmột sốGit:

Những thứ tiên tiến mà Git có thể làm đã thổi bay tâm trí tôi. Nó có thể rất phức tạp, và tôi có xu hướng tránh tất cả sự phức tạp đó. Tôi hầu như không bao giờ sử dụng Git trong dòng lệnh và sử dụngGitHub Máy tính để bànlà ứng dụng khách Git đơn giản nhất và đẹp nhất từ trước đến nay.

Tuy nhiên, hai điều tôi thỉnh thoảng vẫn sử dụng làhái anh đàocam kết bí mật.

Hãy nói về điều đó.

Trong các dự án mà tôi là nhà phát triển duy nhất, có nghĩa là tất cả các dự án cá nhân của tôi, tôi có xu hướng làm việc thành thạo khi tôi có thể. Ví dụ: nếu tôi đang thực hiện một thay đổi đơn giản hoặc thêm một bài đăng mới vào blog. Công cụ nhanh chóng và không bị hỏng.

Tuy nhiên, trong một số trường hợp, tôi không sử dụng phương pháp này mà thay vào đó, tôi tạo một nhánh cho một tính năng lớn.

Đây cũng là mặc định khi làm việc trên một dự án nguồn mở hoặc dựa trên nhóm.

Bạn tạo một nhánh và cam kết thường xuyên. Cam kết sớm và thường xuyên là một lợi thế lớn vì bạn có thể làm việc trên mã của mình với sự tự tin rằng bạn luôn có thể quay trở lại trạng thái hoạt động hoặc ít nhất là về trạng thái mà bạn biết rằng điều gì đó đã hoạt động.

Bạn có thể thực hiện một loạt các cam kết nhanh trong đó thông báo là “ok”, “thử cái này” hoặc “sửa lỗi ngớ ngẩn”.

Nhưng tại một số thời điểm, bạn cần phải hội tụ về trạng thái ổn định và cam kết các thay đổi trở lại chế độ chính hoặc bất kỳ nhánh nào bạn muốn.

Bạn muốn làm một điều trước đó: xóa bỏ cam kết của bạn.

GitHubcó thể tự động làm điều đó cho bạn khi bạn đang hợp nhất Yêu cầu kéo và đó là quy trình làm việc mà tôi đã sử dụng rất nhiều trên các kho lưu trữ Nguồn mở công khai trong quá khứ.

Thay vì thấy tất cả các cam kết riêng lẻ có trong Yêu cầu kéo, bạn chỉ thấy một cam kết và trong quá trình hợp nhất PR, bạn có thể viết một thông điệp và mô tả cam kết chi tiết và chuyên dụng.

Điều này sẽ loại bỏ tất cả các cam kết Git trước đó khác nhau từ người đứng đầu chi nhánh mà bạn đang hợp nhất và cũng xóa tất cả các cam kết đó mà có thể bạn đã hoàn nguyên các thay đổi, v.v.

Đây là vấn đề nhức nhối trong quy trình PR của GitHub. Bạn cũng có thể xóa các cam kết của mình bên ngoài GitHub.

Khi công việc của bạn trên một nhánh hoàn thành, bạn hợp nhất cái chính (hoặc bất kỳ nhánh nào khác mà bạn muốn hợp nhất) vào nó:

git merge master

để bạn có thể xử lý bất kỳ xung đột cập nhật nào ở đó.

Sau đó, bạn kiểm tra tổng thể và từ đó bạn chạy:

git merge --squash <your-feature-branch>

và sau đó

git commit

Đây chỉ là một trong những quy trình công việc khả thi mà bạn có thể sử dụng, và thực hiện tất cả bằng GitHub rất đơn giản và là tùy chọn có thể giúp bạn ít đau đầu nhất.


Thêm hướng dẫn git: