Git đẩy bị từ chối sau khi rebase nhánh tính năng

OK, tôi nghĩ rằng đây là một kịch bản git đơn giản, tôi còn thiếu gì?

Tôi có một masterchi nhánh và một featurechi nhánh. Tôi làm một số công việc master, một số featurevà sau đó một số nữa master. Tôi kết thúc với một cái gì đó như thế này (thứ tự từ điển ngụ ý thứ tự cam kết):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Tôi không có vấn đề gì để git push origin mastergiữ cho mastercập nhật từ xa , cũng như với git push origin feature(khi bật feature) để duy trì một bản sao lưu từ xa cho featurecông việc của tôi . Cho đến bây giờ, chúng tôi tốt.

Nhưng bây giờ tôi muốn nổi featureloạn trên đỉnh của các F--Gcam kết trên chủ, vì vậy tôi git checkout featurevà git rebase master. Vẫn tốt. Bây giờ chúng tôi có:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Vấn đề: thời điểm tôi muốn sao lưu phần khởi động mới được featurephân nhánh git push origin feature, lực đẩy bị từ chối vì cây đã thay đổi do việc khởi động lại. Điều này chỉ có thể được giải quyết với git push --force origin feature.

Tôi ghét sử dụng --forcemà không chắc chắn tôi cần nó. Vì vậy, tôi cần nó? Liệu cuộc nổi loạn có nhất thiết ngụ ý rằng kế tiếp pushnên là ưu tiên --force?

Chi nhánh tính năng này không được chia sẻ với bất kỳ nhà phát triển khác, vì vậy tôi không có vấn đề de facto với việc đẩy mạnh vũ lực, tôi sẽ không để mất bất kỳ dữ liệu, câu hỏi là khái niệm hơn.

Vấn đề là git pushgiả định rằng chi nhánh từ xa có thể được chuyển nhanh đến chi nhánh địa phương của bạn, đó là tất cả sự khác biệt giữa các chi nhánh địa phương và từ xa là ở địa phương có một số cam kết mới như thế:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Khi bạn thực hiện các git rebasecam kết D và E được áp dụng cho cơ sở mới và các cam kết mới được tạo. Điều đó có nghĩa là sau khi rebase bạn có một cái gì đó như thế:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

Trong tình huống đó, chi nhánh từ xa không thể được chuyển nhanh đến địa phương. Mặc dù, về mặt lý thuyết, chi nhánh địa phương có thể được hợp nhất vào điều khiển từ xa (rõ ràng bạn không cần nó trong trường hợp đó), nhưng khi git pushthực hiện chỉ hợp nhất chuyển tiếp nhanh, nó sẽ ném và lỗi.

Và --forcetùy chọn nào chỉ là bỏ qua trạng thái của nhánh từ xa và đặt nó vào cam kết mà bạn đang đẩy vào nó. Vì vậy, git push --force origin feature-branchchỉ cần ghi đè origin/feature-branchvới địa phương feature-branch.

Theo tôi, việc khởi động lại các nhánh tính năng mastervà đẩy chúng trở lại kho lưu trữ từ xa là được miễn là bạn là người duy nhất làm việc trên nhánh đó.

Thay vì sử dụng -f hoặc - Force, các nhà phát triển nên sử dụng

--force-with-lease

Tại sao? Bởi vì nó kiểm tra chi nhánh từ xa để biết những thay đổi hoàn toàn là một ý tưởng tốt. Chúng ta hãy tưởng tượng rằng James và Lisa đang làm việc trên cùng một nhánh tính năng và Lisa đã đưa ra một cam kết. James bây giờ nổi loạn chi nhánh địa phương của mình và bị từ chối khi cố gắng đẩy. Tất nhiên James nghĩ rằng điều này là do rebase và sử dụng - Force và sẽ viết lại tất cả những thay đổi của Lisa. Nếu James đã sử dụng - cưỡng bức cho thuê, anh ta sẽ nhận được một cảnh báo rằng có những cam kết được thực hiện bởi người khác. Tôi không thấy lý do tại sao mọi người sẽ sử dụng - lực lượng thay vì - lực lượng cho thuê khi đẩy lùi sau một cuộc nổi loạn.

Tôi sẽ sử dụng thay vì "thanh toán -b" và nó dễ hiểu hơn.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

khi bạn xóa, bạn không thể đẩy vào một nhánh thoát có chứa ID SHA khác nhau. Tôi chỉ xóa chi nhánh từ xa trong trường hợp này.

Một giải pháp cho vấn đề này là thực hiện những gì mà kịch bản hợp nhất nổi loạn của msysGit thực hiện - sau khi rebase, hợp nhất trong phần đầu cũ featurevới -s ours. Bạn kết thúc với biểu đồ cam kết:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... và sự thúc đẩy của featurebạn sẽ là một bước tiến nhanh.

Nói cách khác, bạn có thể làm:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Không được thử nghiệm, nhưng tôi nghĩ điều đó đúng ...)

Có thể có hoặc không có trường hợp chỉ có một nhà phát triển trên nhánh này, đó là bây giờ (sau khi rebase) không phù hợp với nguồn gốc / tính năng.

Vì vậy, tôi sẽ đề nghị sử dụng trình tự sau:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Vâng, chi nhánh mới, điều này sẽ giải quyết vấn đề này mà không cần một lực lượng, mà tôi nghĩ nói chung là một nhược điểm lớn của git.

Cách của tôi để tránh lực đẩy là tạo ra một nhánh mới và tiếp tục làm việc trên nhánh mới đó và sau khi ổn định, loại bỏ nhánh cũ đã bị loại bỏ:

• Rebasing chi nhánh đã kiểm tra tại địa phương
• Chi nhánh từ chi nhánh nổi loạn sang chi nhánh mới
• Đẩy nhánh đó như một nhánh mới vào điều khiển từ xa. và xóa chi nhánh cũ trên remote

Những người khác đã trả lời câu hỏi của bạn. Nếu bạn rebase một nhánh, bạn sẽ cần phải đẩy nhánh đó.

Rebase và một kho lưu trữ được chia sẻ thường không hợp nhau. Đây là viết lại lịch sử. Nếu những người khác đang sử dụng nhánh đó hoặc đã phân nhánh từ nhánh đó thì rebase sẽ khá khó chịu.

Nói chung, rebase hoạt động tốt cho quản lý chi nhánh địa phương. Quản lý chi nhánh từ xa hoạt động tốt nhất với sự hợp nhất rõ ràng (--no-ff).

Chúng tôi cũng tránh sáp nhập chủ vào một nhánh tính năng. Thay vào đó, chúng tôi rebase thành chủ nhưng với một tên nhánh mới (ví dụ: thêm hậu tố phiên bản). Điều này tránh được vấn đề nổi loạn trong kho lưu trữ được chia sẻ.

Điều gì là sai với một git merge mastertrên featurechi nhánh? Điều này sẽ bảo tồn công việc bạn đã có, trong khi giữ nó tách biệt với nhánh chính.

A--B--C------F--G
       \         \
        D--E------H

Chỉnh sửa: Ah xin lỗi đã không đọc tuyên bố vấn đề của bạn. Bạn sẽ cần lực khi bạn thực hiện a rebase. Tất cả các lệnh sửa đổi lịch sử sẽ cần --forceđối số. Đây là một sự không an toàn để ngăn bạn mất việc (cũ DvàE sẽ bị mất).

Vì vậy, bạn đã thực hiện một git rebasecái làm cho cây trông giống như (mặc dù bị ẩn một phần Dvà Ekhông còn trong một nhánh có tên):

A--B--C------F--G
       \         \
        D--E      D'--E'

Vì vậy, khi cố gắng đẩy featurechi nhánh mới của bạn (có D'và E'trong đó), bạn sẽ thua Dvà E.

Đối với tôi sau đây các bước dễ dàng làm việc:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Sau khi thực hiện tất cả các thao tác trên, chúng ta cũng có thể xóa nhánh myFeature bằng lệnh sau:

git push origin --delete myFeature

Các công việc sau đây cho tôi:

git push -f origin branch_name

và nó không loại bỏ bất kỳ mã nào của tôi.

Nhưng, nếu bạn muốn tránh điều này thì bạn có thể làm như sau:

git checkout master
git pull --rebase
git checkout -b new_branch_name

sau đó bạn có thể chọn tất cả các cam kết của mình cho chi nhánh mới. git cherry-pick COMMIT ID và sau đó đẩy chi nhánh mới của bạn.

Vì OP hiểu vấn đề, chỉ cần tìm giải pháp đẹp hơn ...

Làm thế nào về điều này như là một thực hành?

• Có trên nhánh phát triển tính năng thực tế (nơi bạn không bao giờ nổi loạn và ép buộc, vì vậy các nhà phát triển tính năng đồng nghiệp của bạn không ghét bạn). Ở đây, thường xuyên lấy những thay đổi từ chính với một sự hợp nhất. Lịch sử lộn xộn , vâng, nhưng cuộc sống rất dễ dàng và không ai bị gián đoạn trong công việc của mình.

• Có một nhánh phát triển tính năng thứ hai, trong đó một thành viên trong nhóm tính năng đẩy tất cả các tính năng cam kết, thực sự bị phản đối, thực sự bị ép buộc. Vì vậy, gần như sạch sẽ dựa trên một cam kết chủ gần đây. Khi tính năng hoàn tất, đẩy nhánh đó lên trên đỉnh của chủ.

Có thể có một tên mẫu cho phương thức này.