Làm việc đồng bộ với SVN ngược dòng

Question

Tôi đang làm việc trên một dự án đang sử dụng mã từ dự án OpenSource. Một trong những yêu cầu là đẩy nhiều mã trở lại thượng nguồn càng tốt.

Dự án từ xa đang sử dụng Subversion (không tốt lắm).

thiết lập hiện tại của tôi trông như thế này:

[Remote SVN] (git svn fetch)-> [My public Git] <-(push/pull)-> [My dev. Git] 
            VV 
            (pull) 
            VV 
           [Testing grid] 

EDIT 11,7. - đã sửa đổi câu hỏi

Vấn đề của tôi là sự cùng tồn tại của repo công khai tại địa phương của tôi và ngược dòng svn.

tôi phải cung cấp 3 chi nhánh công cộng:

• bảo ổn định
• nghiệm ổn định
• phát triển

Những chi nhánh hiện nay tuyến tính (phát triển trở thành thực nghiệm ổn định và thử nghiệm trở nên bảo thủ) , nhưng mục tiêu là cách tiếp cận tiêu chuẩn 3 với việc hợp nhất. Do tính chất công khai của họ, tôi không thể rebase những nhánh này.

Bây giờ hoàn toàn trực giao với điều này tôi đang cố gắng bằng cách nào đó làm cho việc gửi bản vá đến thượng nguồn dễ dàng hơn. Đào chúng ra khỏi các nhánh của tôi chậm và dễ bị lỗi.

Công việc hiện tại điển hình của tôi là:

• thực hiện một số tính năng trên chi nhánh phát triển hàng đầu
• kiểm tra & tính năng sửa chữa
• kiểm tra & sửa chữa đặc điểm khác bị phá vỡ bởi tính năng mới này (thực sự xảy ra rất nhiều)
• xác định xem đây có phải là điều gì đó có thể được chấp nhận ở thượng nguồn hay không (30:60 có: không)
• làm điều gì đó về nó (chúng tôi ual chỉ viết một TODO mới)

Một vấn đề khác với thượng nguồn là chúng chấp nhận các bản vá lỗi vào các nhánh khác nhau (chi nhánh công của tôi dựa trên nhánh ổn định). Một khi các bản vá lỗi đạt đến nhánh ổn định, tôi có thể đơn giản quên rằng chúng tồn tại, nhưng cho đến khi điều đó xảy ra tôi vẫn cần giữ chúng cục bộ.

Answer 1

Các git svn documentation khuyến cáo các công việc sau khi giao dịch với chi nhánh Subversion:

# Clone a repo (like git clone): 
git svn clone http://svn.example.com/project -T trunk -b branches -t tags 

# Append svn:ignore settings to the default git exclude file: 
git svn show-ignore >> .git/info/exclude 

# View all branches and tags you have cloned: 
git branch -r 

# Create a new branch in SVN 
git svn branch waldo 

# Reset your master to waldo: 
git reset --hard remotes/waldo 

# local changes 
git add ... 
git commit ... 

# pull changes on current branch 
git svn rebase 

# send changes to Subversion 
git svn dcommit 

# check for new branches 
git svn fetch

Các công việc trên là cho một sự thay đổi liên tục trên một chi nhánh Subversion đơn mà bạn có sự sang trọng của một chút cam kết, nhưng tung hứng nhiều Subversion hoạt động và các nhánh git hơi phức tạp một chút.

Để theo dõi chi nhánh waldo kho Subversion của, bắt đầu với

git checkout -b waldo-svn remotes/waldo

Các hậu tố -svn là để tránh những cảnh báo của các hình thức

warning: refname 'waldo' is ambiguous.

và cũng để nhắc nhở bạn rằng git branch đây là để theo dõi nhánh Subversion. Luôn luôn giữ những thay đổi cho các chi nhánh tuyến tính!

Để cập nhật Waldo-svn, chạy

git svn rebase

này sẽ lấy các thay đổi từ Subversion và rebase bất kỳ thay đổi địa phương trên đầu trang của những người. Nó cũng đủ thông minh để nhận ra khi một trong những thay đổi cục bộ của bạn đã được chấp nhận nguyên văn ngược dòng: nó sẽ được thay thế bằng cam kết Subversion và có một dòng bắt đầu bằng git-svn-id: ... trong thông điệp cam kết của nó.

Khi các nhà bảo trì thượng nguồn làm thay đổi nội dung và cấu trúc của các bản vá lỗi của bạn (ví dụ, sửa đổi mã, tách một miếng vá thành nhiều Subversion cam kết, hoặc kết hợp nhiều bản vá lỗi vào một cam kết duy nhất) là khi cuộc sống trở nên vui vẻ giải quyết xung đột và cố gắng gỡ rối mớ hỗn độn.

Để có toàn bộ tính tổng quát, hãy giữ các nhánh svn của bạn trong git sạch (không có thay đổi) và tạo nhánh phát hành ngoài nhánh svn. Để gửi một bản vá, sử dụng

git diff waldo-svn waldo-fix-frobnicator

Sau đó, khi bạn git svn rebase để bắt kịp với các repo Subversion, bạn sẽ cần phải xem xét các bản ghi và quyết định việc bố trí tương ứng của chi nhánh vấn đề của bạn, sắp xếp của một GTD cho git .

Answer 2

Tôi không thực sự chắc chắn tôi đã hiểu vấn đề của bạn, nhưng tôi nghĩ bạn có thể đang tìm kiếm git stash.

Answer 3

Tôi không chắc chắn các tính năng của bạn được kết hợp với mã thượng nguồn như thế nào, nhưng bạn có thể phân nhánh "lõi" của thượng nguồn mà bạn duy trì riêng biệt với các tính năng bổ sung của mình. Điều này chỉ thực sự hoạt động nếu bạn có thể phân vùng cơ sở mã.

Answer 4

Bạn thực sự chưa rõ bạn muốn làm gì. Trong tham chiếu đến tuyên bố của bạn rằng "(duy trì chi nhánh riêng biệt cho mỗi tính năng là do đó không tầm thường)", tôi chỉ có thể tự hỏi tại sao bạn nghĩ rằng nó sẽ là tầm thường. Hai bản vá phụ thuộc lẫn nhau vào nhau hoặc là một bản vá đơn lẻ, hoặc ít nhất là trên một nhánh đơn lẻ. Một bản vá B phụ thuộc vào A (nhưng không phải cách khác) nên ở trên nhánh với A hoặc trên nhánh với cha/mẹ cam kết trên nhánh A.

Bây giờ, nếu bạn muốn duy trì một "tổng quan rõ ràng" về nơi bản vá của bạn ở phía thượng nguồn, điều đó sẽ đi xuống để giữ bản sao cục bộ của tất cả các nhánh ngược dòng. Tôi không thấy vấn đề là ở đâu. Bạn thực sự cần phải chính xác nếu bạn muốn có câu trả lời chính xác hơn.

---

Ok, đây là cách dễ dàng để giải quyết ngay bây giờ.

Bạn có hai vấn đề.

(1) đang nhận các cam kết ngã ba không bao giờ đi ngược dòng nhánh phát triển chính của bạn và vào chi nhánh ngã ba khi bạn nhận ra mình không bao giờ gửi lại.

Tạo nhánh rẽ nhánh. Khi bạn nhận ra một tính năng sẽ không quay trở lại, hãy kéo từ nhánh giữ chức năng ngã ba. Sau đó, git revert tính năng ngã ba để áp dụng một bản vá hoàn tác tính năng từ địa phương- *. Lặp lại khi cần thiết.

(2) Có phải bạn đang lo lắng về những gì xảy ra với bản vá ngược dòng.

Bạn thực sự không cần phải theo dõi xem liệu họ đã áp dụng bản vá của bạn cho bản ổn định từ xa chưa (từ nay đến nay ổn định). Bạn sẽ không mất một bản vá trong L-ổn định nếu bạn kéo từ r-ổn định và họ đã không áp dụng các bản vá được nêu ra. Vấn đề duy nhất có thể là sẽ có xung đột hợp nhất trên mã từ bản vá, nhưng bạn sẽ không thể làm được điều đó. Một khi họ áp dụng các miếng vá, nó sẽ hoặc trông giống như cách bạn giải quyết xung đột hợp nhất (trong trường hợp này bạn sẽ không nhận được khác biệt từ đó khi bạn kéo bản vá từ R-ổn định), hoặc họ sẽ hợp nhất theo một cách khác , và bạn sẽ nhận được một cuộc xung đột hợp nhất và được trao một cơ hội để quyết định giữ đường hoặc theo cách của bạn. Chỉ cần nhớ rằng nếu bạn muốn giữ cho con đường của bạn, bạn sẽ được forking từ r-ổn định. Một lựa chọn là di chuyển "theo cách của bạn" lên ngã ba và tiếp tục theo cách của họ trên địa phương- *.