Tại sao mỗi repo Github nghiêm túc tôi thực hiện các yêu cầu kéo vì muốn tôi nén các cam kết của mình thành một cam kết duy nhất?

Tôi nghĩ rằng nhật ký git đã ở đó để bạn có thể kiểm tra tất cả lịch sử của mình và xem chính xác những thay đổi đã xảy ra ở đâu, nhưng việc xóa nó sẽ kéo nó ra khỏi lịch sử và gộp tất cả vào một cam kết. Điểm là gì?

Điều này dường như cũng đi ngược lại với câu thần chú "cam kết sớm và thường xuyên cam kết".

Vì vậy, bạn có một lịch sử git rõ ràng và súc tích, rõ ràng và dễ dàng ghi lại các thay đổi được thực hiện và lý do tại sao.

Ví dụ: nhật ký git 'không được yêu cầu' điển hình đối với tôi có thể trông giống như sau:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Thật là một mớ hỗn độn!

Trong khi một bản ghi git được quản lý và hợp nhất cẩn thận hơn với một chút tập trung vào các thông báo cho điều này có thể trông giống như:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

Tôi nghĩ rằng bạn có thể thấy điểm chung của các cam kết và các nguyên tắc tương tự được áp dụng cho các yêu cầu kéo - Tính dễ đọc của Lịch sử. Bạn cũng có thể thêm vào nhật ký cam kết đã có hàng trăm hoặc thậm chí hàng ngàn cam kết và điều này sẽ giúp giữ cho lịch sử phát triển ngắn và súc tích.

Bạn muốn cam kết sớm và thường xuyên. Đó là một thực hành tốt nhất vì nhiều lý do. Tôi thấy rằng điều này dẫn đến tôi thường xuyên có các cam kết là "lau" (đang thực hiện) hoặc "phần A đã hoàn thành" hoặc "lỗi đánh máy, sửa lỗi nhỏ" trong đó tôi đang sử dụng git để giúp tôi làm việc và cho tôi các điểm làm việc Tôi có thể quay lại nếu đoạn mã sau không hoạt động khi tôi tiến hành để mọi thứ hoạt động. Tuy nhiên tôi không cần hoặc muốn lịch sử đó là một phần của lịch sử git cuối cùng vì vậy tôi có thể xóa sổ các cam kết của mình - nhưng hãy xem các ghi chú bên dưới để biết điều này có nghĩa là gì trên nhánh phát triển so với chủ.

Nếu có các mốc quan trọng đại diện cho các giai đoạn làm việc riêng biệt, vẫn có thể có nhiều hơn một cam kết cho mỗi tính năng / tác vụ / lỗi. Tuy nhiên, điều này thường có thể làm nổi bật thực tế là vé đang được phát triển là 'quá lớn' và cần được chia thành các phần nhỏ hơn có thể độc lập, ví dụ:

8754390gf87... Implement feature switches

có vẻ như "1 tác phẩm". Hoặc là họ tồn tại hoặc họ không! Dường như không có ý nghĩa để phá vỡ nó. Tuy nhiên kinh nghiệm đã cho tôi thấy rằng (tùy thuộc vào quy mô và mức độ phức tạp của tổ chức), một con đường chi tiết hơn có thể là:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

Các mảnh nhỏ có nghĩa là đánh giá mã dễ dàng hơn, thử nghiệm đơn vị dễ dàng hơn, cơ hội tốt hơn để qa, liên kết tốt hơn với Nguyên tắc Trách nhiệm Đơn lẻ, v.v.

Đối với thực tế khi nào thực sự làm những quả bí như vậy, về cơ bản có hai giai đoạn riêng biệt có quy trình làm việc riêng của chúng

• sự phát triển của bạn, ví dụ như yêu cầu kéo
• công việc của bạn được thêm vào nhánh chính, ví dụ: thạc sĩ

Trong quá trình phát triển, bạn cam kết 'sớm và thường xuyên' và với các tin nhắn 'dùng một lần' nhanh chóng. Đôi khi bạn có thể muốn squash ở đây, ví dụ như squash trong wip và todo tin nhắn cam kết. Bạn có thể giữ lại nhiều cam kết đại diện cho các bước riêng biệt mà bạn đã thực hiện trong quá trình phát triển. Hầu hết các squash bạn chọn làm nên nằm trong các nhánh tính năng này, trong khi chúng đang được phát triển và trước khi hợp nhất thành chủ.
Khi thêm vào nhánh chính, bạn muốn các xác nhận được ngắn gọn và được định dạng chính xác theo lịch sử dòng chính hiện có. Điều này có thể bao gồm ID hệ thống Trình theo dõi vé, ví dụ JIRA như trong ví dụ. Squashing không thực sự áp dụng ở đây trừ khi bạn muốn 'cuộn lên' một số cam kết riêng biệt trên chủ. Thông thường bạn không.

Sử dụng --no-ffkhi hợp nhất thành chủ sẽ sử dụng một cam kết cho hợp nhất và cũng lưu giữ lịch sử (trong nhánh). Một số tổ chức coi đây là một thực tiễn tốt nhất. Xem thêm tại https://stackoverflow.com/q/9069061/631619 Bạn cũng sẽ thấy hiệu quả thực tế trong git logđó một --no-ffcam kết sẽ là cam kết mới nhất, ở trên cùng của ĐẦU (khi vừa hoàn thành), trong khi không có --no-ffnó hơn nữa trong lịch sử, tùy thuộc vào ngày và các cam kết khác.

Bởi vì thường thì người kéo PR quan tâm đến hiệu ứng ròng của các cam kết "tính năng đã thêm X", chứ không phải về "mẫu cơ sở, hàm sửa lỗi X, thêm chức năng Y, sửa lỗi chính tả trong các nhận xét, tham số tỷ lệ dữ liệu được điều chỉnh, hashmap thực hiện tốt hơn danh sách "... mức độ chi tiết

Nếu bạn nghĩ rằng 16 lần xác nhận của bạn được thể hiện tốt nhất bằng 2 lần xác nhận thay vì 1 "Tính năng X đã thêm, sử dụng lại Z để sử dụng X" thì có lẽ nên đề xuất một pr với 2 lần cam kết, nhưng tốt nhất nên đề xuất 2 pr pr riêng biệt trong trường hợp đó (nếu repo vẫn khăng khăng với pr cam kết duy nhất)

Điều này không đi ngược lại câu thần chú "cam kết sớm và thường xuyên cam kết", như trong repo của bạn, trong khi bạn đang phát triển, bạn vẫn có các chi tiết chi tiết, do đó bạn có cơ hội mất việc tối thiểu và những người khác có thể xem xét / kéo / đề xuất pr chống lại công việc của bạn trong khi pr mới đang được phát triển.

Lý do chính từ những gì tôi có thể thấy là như sau:

• Giao diện người dùng GitHub để hợp nhất các yêu cầu kéo hiện tại (tháng 10 năm 2015) không cho phép bạn chỉnh sửa dòng đầu tiên của thông báo cam kết, buộc nó phải là Merge pull request #123 from joebloggs/fix-snafoo
• Giao diện người dùng GitHub để duyệt lịch sử cam kết hiện không cho phép bạn xem lịch sử của chi nhánh theo --first-parentquan điểm
• Giao diện người dùng GitHub để xem lỗi tại một tệp hiện không cho phép bạn xem trách nhiệm của tệp với --first-parentquan điểm (lưu ý rằng điều này chỉ được sửa trong Git 2.6.2, vì vậy chúng tôi có thể tha thứ cho GitHub vì không có có sẵn)

Vì vậy, khi bạn kết hợp cả ba tình huống trên, bạn sẽ gặp tình huống các cam kết không được xử lý bị sáp nhập trông xấu xí từ Giao diện người dùng GitHub.

Lịch sử của bạn với các cam kết bị đè bẹp sẽ trông giống như

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

Trong khi đó, nếu không bị đè bẹp thì lịch sử sẽ trông giống như

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Khi bạn có nhiều cam kết trong một lần truy tìm PR nơi có sự thay đổi có thể trở thành một cơn ác mộng nếu bạn hạn chế sử dụng Giao diện người dùng GitHub .

Ví dụ: bạn tìm thấy một con trỏ null đang được tham chiếu ở đâu đó trong một tệp ... vì vậy bạn nói "ai đã làm điều này và khi nào? Phiên bản phát hành nào bị ảnh hưởng?". Sau đó, bạn đi lang thang đến chế độ xem đổ lỗi trong Giao diện người dùng GitHub và bạn thấy rằng dòng đã được thay đổi trong789fdfffdf... "oh nhưng đợi một chút, dòng đó chỉ thay đổi thụt lề để phù hợp với phần còn lại của mã", vì vậy bây giờ bạn cần điều hướng đến trạng thái cây cho tệp đó trong cam kết cha mẹ và truy cập lại trang đổ lỗi ... cuối cùng bạn tìm thấy cam kết ... đó là một cam kết từ 6 tháng trước ... "oh **** điều này có thể ảnh hưởng đến người dùng trong 6 tháng" bạn nói ... à, nhưng chờ đã, đó là cam kết thực ra là trong Yêu cầu kéo và chỉ được sáp nhập vào ngày hôm qua và chưa có ai cắt bản phát hành ... "Chết tiệt, mọi người vì đã hợp nhất lịch sử mà không bị đè bẹp" là tiếng kêu thường có thể nghe thấy sau khoảng 2 hoặc 3 cuộc thám hiểm khảo cổ mã thông qua Giao diện người dùng GitHub

Bây giờ chúng ta hãy xem xét cách thức hoạt động của nó nếu bạn sử dụng dòng lệnh Git (và bản 2.6.2 siêu tuyệt vời có bản sửa lỗi git blame --first-parent)

• Nếu bạn đang sử dụng dòng lệnh Git, bạn sẽ có thể kiểm soát hoàn toàn thông điệp cam kết hợp nhất và do đó, cam kết hợp nhất có thể có một dòng tóm tắt hay.

Vì vậy, lịch sử cam kết của chúng tôi sẽ như thế nào

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Nhưng chúng ta cũng có thể làm

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(Nói cách khác: Git CLI cho phép bạn có bánh và ăn nó)

Bây giờ khi chúng ta gặp phải vấn đề con trỏ null ... chúng ta chỉ cần sử dụng git blame --first-parent -w dodgy-file.cvà ngay lập tức chúng ta được cung cấp cam kết chính xác trong đó tham chiếu khử con trỏ null được đưa vào nhánh chính bỏ qua các thay đổi khoảng trắng đơn giản.

Tất nhiên, nếu bạn đang thực hiện hợp nhất bằng Giao diện người dùng GitHub thì git log --first-parentthực sự rất nhảm nhí nhờ GitHub buộc dòng đầu tiên của thông báo cam kết hợp nhất:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

Vì vậy, để cắt ngắn một câu chuyện dài:

Giao diện người dùng GitHub (tháng 10 năm 2015) có một số thiếu sót với cách nó hợp nhất các yêu cầu kéo, cách trình bày lịch sử cam kết và cách nó quy kết thông tin đổ lỗi. Cách tốt nhất hiện tại để hack xung quanh các lỗi này trong Giao diện người dùng GitHub là yêu cầu mọi người xóa sạch các cam kết của họ trước khi hợp nhất.

Git CLI không có những vấn đề này và bạn có thể dễ dàng chọn chế độ xem bạn muốn xem để vừa có thể khám phá lý do tại sao một thay đổi cụ thể được thực hiện theo cách đó (bằng cách xem lịch sử của các cam kết chưa được xử lý) cũng như xem các cam kết hiệu quả đè bẹp.

Tập lệnh

Lý do cuối cùng thường được trích dẫn cho các cam kết squash là để làm cho việc nhập backport dễ dàng hơn ... nếu bạn chỉ có một cam kết để quay lại cổng (tức là cam kết bị đè bẹp) thì rất dễ để chọn cherry ...

Vâng, nếu bạn đang xem lịch sử git với git log --first-parentthì bạn chỉ có thể chọn anh đào hợp nhất. Hầu hết mọi người đều nhầm lẫn khi chọn cam kết hợp nhất vì bạn phải chỉ định -m Ntùy chọn nhưng nếu bạn có cam kết từ git log --first-parentđó thì bạn biết rằng đó là cha mẹ đầu tiên mà bạn muốn theo dõi nên sẽ làgit cherry-pick -m 1 ...

Tôi đồng ý với các tình cảm được thể hiện trong các câu trả lời khác trong chủ đề này về việc hiển thị một lịch sử rõ ràng và súc tích của các tính năng được thêm vào và các lỗi đã được sửa. Tuy nhiên, tôi đã muốn giải quyết một khía cạnh khác mà câu hỏi của bạn đã lảng tránh nhưng không nêu rõ. Một phần của việc treo máy bạn có thể có về một số phương pháp làm việc của git là git cho phép bạn viết lại lịch sử có vẻ lạ khi được giới thiệu với git sau khi sử dụng các hình thức kiểm soát nguồn khác trong đó không thể thực hiện được các hành động đó. Hơn nữa, điều này cũng đi ngược lại với nguyên tắc kiểm soát nguồn được chấp nhận chung rằng một khi có gì đó được cam kết / đăng ký thành kiểm soát nguồn, bạn sẽ có thể trở lại trạng thái đó bất kể bạn có thay đổi gì sau khi thực hiện cam kết đó. Như bạn ngụ ý trong câu hỏi của bạn, đây là một trong những tình huống đó. Tôi nghĩ git là một hệ thống kiểm soát phiên bản tuyệt vời; tuy nhiên, để hiểu nó, bạn phải hiểu một số chi tiết thực hiện và các quyết định thiết kế đằng sau nó, và kết quả là nó có một đường cong học tập dốc hơn. Hãy nhớ rằng git được dự định là một hệ thống kiểm soát phiên bản phân tán và điều đó sẽ giúp giải thích lý do tại sao các nhà thiết kế cho phép lịch sử git được viết lại với squash cam kết là một ví dụ về điều này.

Bởi vì viễn cảnh ... Cách thực hành tốt nhất là có một cam kết duy nhất cho mỗi <<issue-management-system>>vấn đề nếu có thể.

Bạn có thể có nhiều cam kết như bạn muốn trong nhánh / repo tính năng của riêng bạn, nhưng đó là lịch sử của bạn phù hợp với những gì bạn đang làm bây giờ cho quan điểm CỦA BẠN ... không phải là LỊCH SỬ cho toàn bộ TEAM / DỰ ÁN hoặc ứng dụng từ họ viễn cảnh sẽ được giữ trong vài tháng kể từ bây giờ ...

Vì vậy, bất cứ khi nào bạn muốn cam kết sửa lỗi hoặc tính năng cho một repo chung (ví dụ này là với nhánh phát triển), bạn có thể làm gì như sau:

Làm thế nào để khởi động lại nhánh tính năng của bạn để phát triển nhanh chóng

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

Tôi sẽ xem liệu mã sẽ được công khai hay không.

Khi các dự án ở chế độ riêng tư:

Tôi khuyên bạn không nên bí và xem việc làm xúc xích. Nếu bạn sử dụng các cam kết tốt và nhỏ, các công cụ như git bisect rất tiện dụng và mọi người có thể nhanh chóng xác định các cam kết hồi quy và xem lý do tại sao bạn làm điều đó (vì thông báo cam kết).

Khi các dự án được công khai:

Bóp mọi thứ vì một số cam kết có thể chứa rò rỉ bảo mật. Ví dụ, một mật khẩu đã được cam kết và xóa lại.