Tạm thời xóa đối tượng địa lý khỏi chi nhánh Git

Question

Chúng tôi sử dụng git để quản lý kho lưu trữ mã của ứng dụng và có tình huống mà tôi chưa gặp phải, nhưng tôi cho là rất phổ biến.

Chúng tôi muốn tạm thời xóa một đối tượng địa lý, sau đó thêm lại vào một thời điểm nào đó trong tương lai. Tôi đang cố gắng tưởng tượng cấu trúc phân nhánh có thể hỗ trợ điều này, hoặc nếu chúng ta nên làm điều gì đó đơn giản như loại bỏ tính năng khỏi mã, và khi sẵn sàng thêm lại, hãy tạo lại nó từ lịch sử cam kết.

Có ai có thể chỉ cho tôi đúng hướng trong việc xử lý tình huống này không?

Answer 1

Một cách bạn có thể tạm thời xóa đối tượng địa lý của mình trước lịch sử repo Git của bạn là thực hiện cam kết xóa đối tượng địa lý. Sau đó, khi bạn muốn thêm lại tính năng này, chỉ cần revert the commit đã loại bỏ tính năng này. Điều này sẽ làm một bản vá đảo ngược, nghĩa là nó sẽ áp dụng những thay đổi theo hướng ngược lại, sẽ có hiệu quả lại thêm tính năng:

git revert <sha of commit that removed the feature> 

Nếu bạn muốn chắc chắn rằng bạn có thể dễ dàng thêm lại các tính năng sau bởi đồng bộ hóa với các thay đổi đối với mã trong thời gian chờ đợi, bạn có thể tạo chi nhánh riêng biệt ngay lập tức sau khi xóa nó và sau đó xử lý nhánh đó giống như bất kỳ chi nhánh tính năng nào khác và giữ nó đồng bộ bằng cách thường xuyên đổi lại mã này với master (hoặc chi nhánh develop, nếu đó là cách bạn muốn thực hiện), giải quyết xung đột khi bạn thực hiện. Vì vậy, về cơ bản, bạn sẽ muốn làm một cái gì đó như thế này (nó sẽ không quan trọng nhiều nếu bạn đang sử dụng một chiến lược phân nhánh GitHub Flow hoặc Git Flow, cả hai đều sử dụng khái niệm về các chi nhánh tính năng mà cuối cùng được sáp nhập vào một chính- . dòng phát triển Để đơn giản, tôi sẽ sử dụng GitHub dòng chảy trong ví dụ này):

# On master branch 
git commit -m "Remove feature X" # Creates commit 1234567... 

# Now make feature branch 
git checkout -b saved-feature 

# Immediately put the feature back in the feature branch 
git revert 1234567 

# When you want to sync branch with master, just use rebase. 
# Rebase allows you to sync frequently, since it doesn't 
# leave behind a bunch of merge commits. 
# 
# From the feature branch: 
git rebase master # Resolve any conflicts as needed. 

# N commits later, you decide it's time to merge the feature 
# back in. You can use fast-forward or non-fast-forward merge, 
# it's up to you. 
# 
# Using fast-forward merge with master checked out (assuming 
# feature branch was just rebased onto master): 
git merge saved-feature 

# Or forcing a merge commit, if that's what you want: 
git merge --no-ff saved-feature 

Giả sử bạn đã giữ saved-feature đồng bộ thường xuyên với master (hoặc develop, nếu đó là những gì bạn sử dụng), giải quyết xung đột như bạn đi, bạn sẽ không gặp vấn đề gì khi hợp nhất lại tính năng này.

Tài liệu tham khảo:

• Rebase
• Revert
• Merge

Answer 2

Đây là chiến lược nên hoạt động. Nghe có vẻ như công việc của bạn là khá nướng vào dự án của bạn, vì vậy đây là những gì tôi sẽ làm. Trước tiên, hãy chọn điểm xuất phát của bạn, đối với tôi thường là chi nhánh dev (giả sử cũng có một số master branch). Tắt nhánh mới sẽ bị xóa khỏi dự án của bạn

git checkout -b dev_feature_removed 

Cũng đồng thời quay vòng nhánh sẽ được duy trì trong dự án.

git checkout -b dev_feature_sustained 

Bây giờ làm mã hóa và thử nghiệm bạn cần phải chắc chắn rằng tính năng này một cách chính xác và hoàn toàn loại bỏ trong dev_feature_removed và một khi bạn chắc chắn rằng đây là trường hợp sáp nhập chi nhánh đó trở lại vào sản xuất. Trong trường hợp của tôi để dev cho thử nghiệm thêm và sau đó thành chủ để đi sống.

Trong khi đó, bạn có thể giữ cho chi nhánh khác dev_feature_sustained cũng có trong repo của bạn. Bạn có thể hợp nhất dev vào nhánh này để giữ cho nó được đồng bộ hóa và cũng thêm vào tính năng đã xóa của bạn (sửa lỗi hoặc chuông mới và còi) cho ngày khi nó được trả lại bằng cách kết hợp nó trở lại dev (trong trường hợp của tôi có thể là chủ trong).

Sự trở lại của đối tượng địa lý này có thể gây xung đột hợp nhất tùy thuộc vào mức độ kết hợp chặt chẽ của đối tượng địa lý của bạn. Kể từ khi bạn có trước repo nó có vẻ như bạn sẽ tạo ra xung đột không có vấn đề gì bởi vì các chiến lược hợp nhất chỉ có thể làm rất nhiều. Tuy nhiên, vì bạn sẽ có hai cây cam kết đầy đủ, một với tính năng và một không có, bạn sẽ biết về sự tồn tại của mỗi điểm mà đối tượng địa lý của bạn kết nối lại với dự án của bạn. Vì vậy, bạn sẽ có mọi thứ bạn cần để đặt nó trở lại trong dự án của bạn. Đây là những gì tôi sẽ dự thảo trong trường hợp của tôi. Chúc may mắn, anh bạn.

Answer 3

Tôi sẽ giải quyết vấn đề này trong chính mã. Thêm một bản đồ tính năng (về cơ bản là các cờ boolean cho mỗi tính năng) và sau đó chỉ cần bật/tắt các tính năng nếu cần mà không phải thực sự trích xuất mã/logic từ kho lưu trữ của bạn.

Something trong một file cấu hình đơn giản như:

<?php 
$features = array(
    'news' => true, 
    'events' => true, 
    'shop' => false 
); 

Và sau đó trong bộ điều khiển tương ứng của bạn:

<?php 
class ShopController extends AbstractController { 

    public function __construct() { 
     // $features array would be passed in somehow; 
     // maybe via a dependency injection container 
     if (!$features['shop']) { 
      // feature is disabled, so just send 404 page for now 
      throw new ResourceNotFoundException(); 
     } 
    } 
} 

Lưu ý: Trên đây là đang bán giả.

Answer 4

Dưới đây là một ví dụ cụ thể cho thấy chiến lược trong John Galt's answer:

$ git log --graph --decorate --oneline 
* d1d201b (HEAD, restore-b) Merge branch 'prod' into restore-b 
|\ 
| * 18d759f (prod) add feature e in prod 
* | 191037e Merge branch 'prod' into restore-b 
|\ \ 
| |/ 
| * e0de1be add feature d in production 
* | a122936 Revert "remove feature b in production" 
|/ 
* d3e2c42 remove feature b in production 
* 5369ecf existing three features 

Về cơ bản, restore-b luôn chứa tất cả mọi thứ trong prod cộng khôi phục lại tính năng (cam kết a122936).Khi bạn thực hiện các cam kết mới trên prod, chúng được hợp nhất thành restore-b, để bất cứ khi nào bạn sẵn sàng khôi phục đối tượng địa lý, đó là sự hợp nhất nhanh giữa các phần mềm.

Cách tiếp cận đơn giản hơn là tránh tạo cam kết a112936 và chi nhánh restore-b cho đến thời điểm bạn sẵn sàng khôi phục đối tượng địa lý. Ưu điểm của việc tạo và giữ cho đến nay chi nhánh restore-b là bất kỳ xung đột nào với các thay đổi khác đều được giải quyết một cách kịp thời (hy vọng bởi người đã viết mã mâu thuẫn, ngay sau khi ông viết nó). Điều này giữ cho tính năng "mới" và "trên boong", sẵn sàng để được đưa vào bản phát hành sản phẩm mà không có thêm công việc phát triển nào.