분기의 모든 커밋을 하나씩 차례로 푸시

Question

기능 분기의 모든 커밋 (예 : master)을 하나씩 차례로 개별적으로 푸시하여 각 커밋이 푸시 후크를 트리거하도록하는 쉬운 방법이 있습니까? 원격 측면? 이것은 실패한 테스트를 먼저 구현하고 수정 한 후 "테스트 우선"시나리오에 유용합니다.

나는 git push sha:remote-ref-name을 할 수 있지만 수동으로하는 것은 지루한 일임을 알고 있습니다. 이 테스트 우선 시나리오에 대한 좋은 이유를 을 무엇을 의미하는지 빌드를 트리거로 한 번에 커밋하지 않는 한

Answer 1

이 스크립트는 작동합니다 : cforbish @

#!/bin/bash 

if [ ! -d .git ]; then 
    echo "$(basename $0): not a git directory." 1>&2 
    exit 1 
fi 

# lbranch - name of local branch 
# remote - name of remote 
# rbranch - name of remote branch 
lbranch=$(git rev-parse --abbrev-ref HEAD) 
remote=$(git config branch.${lbranch}.remote) 
rbranch=$(git config branch.${lbranch}.merge) 
rbranch=${rbranch/refs\/heads\//} 

for rev in $(git rev-list --reverse ${lbranch} --not --remotes); 
do 
    git push ${remote} ${rev}:${rbranch} 
done 

Answer 2

나는 확실하지 않다, 당신은 실제로 빌드가 다음 성공 실패 볼 수 있습니다.

말하자면, 더 좋은 훅 스크립트 서버 쪽을 사용하면 원하는 것을 얻을 수 있습니다. 뿐만 아니라 병합에서 가져온 커밋 개인을 포함

$ git rev-list OLD_SHA1..NEW_SHA1 

: 당신이 사이 버전의 목록을 계산할 수 있도록 post-receive 후크 스크립트는 기존의 SHA1과 새로운 SHA1 모두를받습니다. 일 수도 있고 이미 워크 플로에 대해 으로 테스트되었으므로 개별적으로 테스트하지 않을 수도 있습니다. 메인 라인은 만 커밋에 당신이 그것을 제한 할 수 있도록 :

$ git rev-list --first-parent OLD_SHA1..NEW_SHA1 

몇 가장자리 경우하지만 있습니다 지점은으로 업데이트 할 수

• . 이전 버전의 브랜치에 있던 새로운 rebased 커밋 을 다시 테스트 하시겠습니까?

• 브랜치가 새로운 것일 수 있습니다. 당신은 의 전체 역사를 재검토하고 싶지는 않습니다. 이미 테스트 한 것을 판별하기 위해 어떤 지점을 사용합니까? master?

• 가지를 제거 할 수 있습니다. 이 사건은 쉽습니다 ... 당신은 아마 아무 것도하지 않습니다. 여기

은 post-receive 후크에 업데이트 된 심판 떨어져 읽기의 예 :

당신이 심판의 이름이 $refname 업데이트 (그리고 그것은의 전체 이름입니다되고있다

#!/bin/bash 

# The current working directory will be in the bare repo being updated. 

while read oldrev newrev refname 
do 
    # Skip deleted branches. 
    if [ "$newrev" != "0000000000000000000000000000000000000000"] 
    then 
     if [ "$oldrev" == "0000000000000000000000000000000000000000"] 
     then 
      # New branch. Test all commits in the branch by using master 
      # as a base. If this was master being created, then nothing will 
      # get triggered. 
      oldrev=$(git merge-base master $newrev) 
     fi 

     for sha1 in $(git rev-list ${oldrev}..${newrev}) 
     do 
      # Tip off build server for each commit between oldrev and newrev 
      tip-off-build-server $sha1 
     done 
    fi 
done 

주 ref, 단축 버전이 아님). 어쨌든 빌드 서버에 대해 을 구현해야 할 수도 있습니다.

이 모든 것은 설정에 따라 다릅니다. 빌드 서버가 단순히 이 저장소의 분기를 폴링하는 경우 한 번에 하나 이상의 을 테스트하는 것을 피할 수 없습니다. 푸시 버튼으로 팁을받는다면 더 똑똑해지기까지 더 이상 이 아닙니다. 여기에 논리가 더 필요할 수도 있습니다. 은 밀어 넣기에 x 개 이상의 커밋이있을 때이 접근 방식을 사용하지 않을 수 있습니다. 다른 프로젝트의 기록을 가져 오는 것을 상상해보십시오. 수천 개의 커밋 일 수 있으므로이 경우 개별적으로 테스트하지 않을 수도 있습니다.거기에 브랜치가 분기되고 계산이 필요한 리비전을 계산할 때 어떤 문제가있을 수 있습니다. 이 동작을 조금 더 철저히 테스트하여 으로 지정하여 원하는 동작이 나타나는지 확인하십시오.

참고 : githooks은 을 스크립트에 전달할 때 유용합니다.

클라이언트 측에서도 개인 푸시가 가능하지만 일부 스크립트는 이 아닙니다. 위와 비슷한 git rev-list을 사용할 수 있습니다. 여기서 $newrev은 로컬 지점의 현재 팁이됩니다. $oldrev은 이전에 분기를 푸시 한 경우 master (또는 develop) 또는 @{upstream}이 걸릴 수 있습니다. 요점은 을 사용하여 푸시에 커밋 목록을 도울 수 있으며 각각을 개별적으로 푸시 할 수 있다는 것입니다. 나는이 방법을 권장하지 않지만 할 수 있습니다.

Answer 3

의 내가 아스 커 생각 (내가) 무슨 필요하지 않았다 목록을 커밋 : 목록을 얻을 순서대로 형성 커밋, 최신에 오래된 그 아직 밀려 나지 않았다. 이것은 (I 하드 배선에 의해 여기 생략하고있어 그의 스크립트의 일반성 몇 가지 감상) 나를 위해 속임수를 썼는지 : 불행하게도

#!/bin/bash 

for rev in $(git rev-list --reverse origin/master..HEAD); 
do 
    git push -f origin ${rev}:master 
done