2017-07-15 14 views
11

Sản phẩm của tôi là một plugin cho IntelliJ. Tôi hỗ trợ một số phiên bản của nền tảng IntelliJ cơ bản và phát hành các bản dựng plugin của tôi cho mỗi phiên bản vì API của chúng thường thay đổi giữa các phiên bản. Nó chỉ là tôi làm việc trên nó, vì vậy tôi phát triển trong chủ và sau đó duy trì một chi nhánh cho mỗi phiên bản khác. Vì vậy, repo của tôi trông như thế này:Tìm các cam kết hợp nhất từ ​​thẻ trên các chi nhánh trong git

1.6.0 1.6.1-eap1 
.... a---b---c--- master 
     \  \ 
     d-------e--- idea-2017.1 
     \  \ 
     f-------g--- idea-2016.3 
      \  \ 
      ...  ... etc etc 

a là một phát hành ổn định, và được gắn thẻ với 1.6.0. c là bản phát hành EAP (beta) và đã được gắn thẻ với 1.6.1-eap1. Chương trình này hoạt động tốt cho hai trường hợp này.

Thỉnh thoảng tôi muốn tạo một công trình xây dựng không đi vào kênh phát hành nhưng người dùng có thể tải xuống theo cách thủ công và kiểm tra xem họ có thích hay không. Tôi muốn tạo một bản dựng dev cho mỗi nền tảng, vì người dùng dev có thể sử dụng bất kỳ phiên bản IntelliJ nào. Cách tốt nhất mà tôi có thể nghĩ đến là tạo một chi nhánh để xây dựng nhà phát triển từ, giả sử, gắn thẻ 1.6.0 (cam kết a) và sau đó tương ứng với các chi nhánh từ cam kết d, f và như vậy tôi có thể hợp nhất chi nhánh dev vào và tạo dev xây dựng từ.

Giả sử tôi muốn viết kịch bản để tạo và duy trì các chi nhánh này, làm cách nào tôi có thể tìm thấy các cam kết d, f và cứ như vậy từ thẻ 1.6.0 để tạo chi nhánh xây dựng nhà phát triển?

+0

Bạn không muốn sử dụng phiên bản mới nhất cho mỗi phiên bản IntelliJ làm cơ sở cho chi nhánh nhà phát triển của bạn? I E. sử dụng c, e và g thay vì a, d và f. Tôi sẽ nghĩ rằng những bản sửa lỗi này chứa các bản sửa lỗi mới nhất cho mỗi phiên bản và là cơ sở tốt hơn để thử nghiệm phát triển mới. – lucash

+0

Chắc chắn, điều đó là có thể, nhưng vấn đề là như nhau - với thẻ '1.6.1-eap1', làm cách nào để tìm các cam kết 'e',' g' vv Về cơ bản, tôi muốn có thể tạo ra các chi nhánh từ bất kỳ bản sửa đổi được gắn thẻ nào, được đảm bảo hợp nhất các cam kết sáp nhập vào mỗi phiên bản chi nhánh. – Colin

Trả lời

1

Đối với vấn đề "tìm ở giữa a ang g cam kết sớm nhất từ ​​idea-2016.3 mà không phải là trong idea-2017, và sớm nhất trong idea-2017 mà không phải là trong master" giải pháp sẽ được sử dụng lệnh:

git log --oneline --source --ancestry-path master idea-2017 idea-2016.3 --not 1.6.0 

đầu ra là , trong lịch sử giống với của bạn:

cf32d9f idea-2017 e 
88f264c idea-2016.3 g 
5bc9fa1 idea-2017 d 
3f460fe idea-2016.3 f 
224cac8 master c 
67620cd master b 

Sau đó, tìm dòng mới nhất được đánh dấu bằng idea-2016.3 và dòng mới nhất được đánh dấu bằng idea-2017, đó sẽ là cam kết của bạn.

Lưu ý rằng đầu ra có thể không được mong muốn nếu có một số vấn đề chặn do sự khác biệt phiên bản trong ví dụ f được sửa trong f' sau đó. Vì vậy, tôi vẫn sẽ xem xét gắn thẻ rõ ràng.

+0

Cảm ơn, tôi thích điều này tốt hơn so với phiên bản ban đầu của tôi. Tôi đang sử dụng awk để có được cam kết cuối cùng: 'awk '$ 2 ==" idea-2017.1 "{commit = 1} END {print $ commit}'' – Colin

0

Có lẽ cách dễ nhất là chỉ duy trì danh sách các phiên bản/tên chi nhánh được hỗ trợ trong tập lệnh shell?

Lý do tôi nghĩ đây là nếu bạn thêm một sự thay đổi:

1.6.0  eap1 eap2 
.... a---b---c---h--- master 
     \  \ \ 
     d-------e---i--- idea-2017.1 
     \  \ \ 
     f-------g---j--- idea-2016.3 
      \  \ \ 
      ...  ... etc etc 

Bạn muốn rằng sự thay đổi (h) sáp nhập vào người đứng đầu chi nhánh thể hiện trong sơ đồ của bạn, tức là h được sáp nhập vào eg. Chi nhánh 2017.1 sẽ trỏ đến số e là cam kết hợp nhất.

Bạn có thể làm điều gì đó với việc đi bộ trở lại để tìm một tổ tiên chung hoặc một cái gì đó nhưng tôi nghĩ điều đó không cần thiết phức tạp và không thực sự mua cho bạn bất cứ thứ gì.

Ngoài ra nếu bạn chỉ giữ danh sách các chi nhánh, bạn có thể ngừng hỗ trợ các phiên bản cũ tương đối dễ dàng.

+0

Vì vậy, các tập lệnh bảo trì chi nhánh của tôi đã có tên chi nhánh được mã hóa cứng và khi tôi hỗ trợ phiên bản mới, tôi cập nhật chúng. Càng xa càng tốt. Vấn đề là tôi không phải lúc nào cũng muốn tạo các bản dựng dev này cho chức năng mới - một trường hợp sử dụng thường xuyên là người dùng có vấn đề mà tôi không thể tái tạo. Dựa trên dấu vết ngăn xếp hoặc bất cứ điều gì mà họ gửi cho tôi, tôi làm việc lên một sửa chữa nhưng tôi không thể thực sự kiểm tra nó. Trong trường hợp đó, tôi muốn tạo một bản dựng dev với bản sửa lỗi mà họ có thể kiểm tra và tôi cần căn cứ vào phiên bản mà họ đang chạy. – Colin

3

Đây là những gì tôi đã kết thúc thực hiện:

#!/bin/sh 

set -e # Automatically abort if any simple command fails 

die() { 
    echo >&2 "[email protected]" 
    exit 1 
} 

[ "$#" -eq 2 ] || die "Usage: $0 <branch name> <tag>" 

tag_commit=$(git rev-list --abbrev-commit -n 1 $2) 
[ "${tag_commit}" = "" ] && die "No commit found for $2" 

child_commit() { 
    git log --graph --pretty=format:"%h %p" --decorate -20 --first-parent $1 | grep $2 | cut -c 3-10 
} 

branch_2017_1=$(child_commit idea-2017.1 $tag_commit) 
[ "${branch_2017_1}" = "" ] && die "No commit found for idea-2017.1" 

branch_2016_3=$(child_commit idea-2016.3 $branch_2017_1) 
[ "${branch_2016_3}" = "" ] && die "No commit found for idea-2016.3" 

branch_2016_2=$(child_commit idea-2016.2 $branch_2016_3) 
[ "${branch_2016_2}" = "" ] && die "No commit found for idea-2016.2" 

branch_2016_1=$(child_commit idea-2016.1 $branch_2016_2) 
[ "${branch_2016_1}" = "" ] && die "No commit found for idea-2016.1" 

git branch "$1" $tag_commit 
git branch "$1-2017.1" $branch_2017_1 
git branch "$1-2016.3" $branch_2016_3 
git branch "$1-2016.2" $branch_2016_2 
git branch "$1-2016.1" $branch_2016_1 

Bây giờ tôi chỉ sẽ cập nhật kết hợp của tôi và giải phóng các kịch bản chuẩn bị để tùy chấp nhận một tên hàng loạt chi nhánh, và tôi nghĩ rằng tôi sẽ được tốt.

Nước sốt bí mật nằm trong chức năng child_commit, được nôi từ here.

Các vấn đề liên quan