2012-06-08 2 views
2

나는 워크 플로우를 다음과 같이 구성했다 :git : 자동으로 삭제/수정 충돌을 해결하는 방법?

마스터 브랜치는 개발을위한 것으로, 소스 코드와 일부 유틸리티 스크립트를 포함하고있다.

릴리스 분기가 배포되고 실행 파일과 일부 추가 파일이 포함되어 있습니다.

처음으로 릴리스 분기를 만들 때 모든 소스 코드를 제거하고 컴파일 된 실행 파일을 추가했습니다. 나는 다음 버전을 할 때, 나는

git merge --no-ff -Xours master

git checkout release 그리고 원인은 내가 -Xours 옵션을 사용하는 경우에도 충돌을 수정/삭제 변경 모든 소스 파일을 수행. 모든 충돌 파일을 수동으로 삭제 한 다음 커밋해야합니다. 이 충돌을 자동으로 해결하여 삭제 된 파일을 강제로 삭제하는 방법이 있습니까?

+0

이전에 소스를 제거 했습니까? 다시 제거 하시겠습니까? 당신의 다음 '릴리즈'커밋은 무엇을 포함 할 것입니까? 여러분의 릴리즈 커밋에서 히스토리를 유지하도록 하시겠습니까? 그래서 이번 릴리스를 가져 오면 모든 이전 릴리스가 생깁니 까? – jthill

답변

1

당신은 완전히 다른 방식으로 소스 제어 관리에 대해 힘내를 사용하고 있습니다. 나는 그 잘못을 말하고있는 것이 아니라, git repo로 달성하고자하는 것에 대해 재검토를 고려해야합니다.

일반적으로 release 분기에는 코드도 포함되어야합니다. 그리고 항상 브랜치 release에서 프로덕션 실행 파일을 빌드합니다. 그런 다음 다른 곳으로 이동하십시오.

그렇다면 실행 파일 버전을 유지하려는 경우에도 마찬가지입니다. 그들을 지키기 위해 또 다른 git repo를 생성하십시오. 이렇게하면 실행 파일을 쉽게 유지 관리 할 수 ​​있습니다.

maven/java를 사용하는 경우 빌드의 아티팩트를 관리하는 것이 목적 인 Maven Repo를 권장합니다.

+0

릴리스 브랜치를 사용하여 고객에게 업데이트를 배포합니다. 이 방법으로 repo를 구성하여 내 릴리스를 손쉽게 패치 할 수 있습니다. 셸 스크립트가 더 잘할 수 있지만, 나는 그것을 처리 할 수 ​​있기를 바랍니다. – peterdemin

+0

실행 파일에 새 git repo를 사용할 수 있습니까? – havexz

0

저장소에서 일부 파일을 삭제하고 변경 사항을 적용하려면 -a 옵션을 사용해야합니다. 광고 설명서의 내용 :

-a, --all 
    Tell the command to automatically stage files that have been 
    modified and deleted, but new files you have not told git about are 
    not affected. 

삭제 된 파일에서 내 모든 저장소를 정리합니다. 그리고 다른 지점에서 병합 할 때 갈등이 없습니다. 나는 이것이 당신을 도울 것입니다 shure 아니에요. 나는 희망한다.

1

코드에서 생성 된 아티팩트를 저장하는 데 동일한 저장소를 사용하지 마십시오. 당신은 당신의 역사를 팽창시킬 것이고, 정기적 인 발달을 위해 느리게 밀고 당길 것입니다. 결국 새로운 복제본이 너무 오래 걸릴 것이므로이 접근법을 포기해야합니다. 가공품의 지퍼에 대한 명명 규칙을 표준화하고 다른 것을 통해 배송하십시오. 그것은 또 다른 git repo 일 수도 있지만 코드에서 작업하는 것은 불가능합니다. 원할 경우 서브 모듈을 통해 2 repos 사이의 링크를 만들 수 있습니다.

+2

Y 문제 (릴리스 관리)에 대한 답변은 좋지만 X에 대한 답을 알고 계십니까? 삭제/수정 충돌 ("우리"와 같은 것)을 자동 해결하는 방법이 있습니까? – inger

관련 문제