일련의 기능 브랜치를 생성하고, 완료되면 git merge --no-ff과 함께 마스터에 병합한다. 이렇게하면 이전 피쳐 브랜치의 시작점과 끝점을 식별하는 데 유용한 빈 병합 커밋이 만들어집니다.더 빨리`git rebase --preserve-merges`를 해보자.
여러 개의 동시 분기 또는 중첩 분기를 처리하기 위해 rebase를 사용합니다. 나는 결코 다시 병합하지 않는다. 나는 언제나 가장 최근의 커밋에 내 브랜치를 리베이스하고, 테스트를 마친 다음 마침내 과 병합한다. 중첩 된 브랜치를 사용하면 똑같은 작업을 수행합니다 : 여러 브랜치가 주 브랜치에 순차적으로 병합됩니다. 브랜치 자체는 결국 마스터로 병합됩니다.
중첩 된 분기와의 병합에 대한 정보를 유지하기 위해 종종 git rebase --preserve-merges을 사용합니다. 이것은 내가 원하는 바를 정확하게 수행하고 워크 플로에 아무런 문제가 없습니다.
내 주된 문제점은 git rebase --preserve-merges이 매우 느리다는 것입니다 (커밋 당 약 2 초 걸리기도 함). What exactly does git's "rebase --preserve-merges" do (and why?)을 읽은 후, git는 임의의 그래프에서 작업해야하기 때문에 병합을 유지하기 위해 git가 많은 작업을 수행해야한다는 것을 알고 있습니다.
내 워크 플로가 선형 기록과 비슷한 그래프를 생성하기 때문에 git rebase --preserve-merge을 더 빠른 방법으로 수행 할 수있는 방법이 있습니까? 역사의 "선형성"을 보장해야합니다. 빈 병합 만 커밋합니까? 최종 결과가 정확하다면 스크립트 나 이상한 명령을 사용해도 상관 없습니다.
A-B-C
/ \
(1)--------D-- master
\
\---F-----I-- feature
\/\ /
E G-H
A-B-C E G-H
/ \/\/ \
(2)--------D---F-----I-feature
master
tl; dr : 기본 이력이 선형이라는 것을 알고 (2)로 변환하는 방법 (git rebase --preserve-merges)은 많은 작업을하지 않아도되고 빠르게 처리 할 수 있습니까?
불행히도 나는 우분투에있어, 그래서 그것에 의존한다고 생각하지 않습니다. 내가이 문제를 가지고 있었던 repo는 지저분한 역사를 가진 많은 사람들에 의해 사용 되었기 때문에 명령의 느린 속도에 영향을 줄 수있었습니다. 그러나, 나는 특별한 경우에 어렵다는 점에 동의하지 않는다 : 단순한'git rebase'는 그것을 매우 빠르게 정확하게 수행한다; 내 유일한 차이점은 병합 커밋을 건너 뛰는 대신 커밋/커밋해야한다는 것입니다. 그렇게 힘들지 않아야지, 그렇지? – Svalorzen
큰 저장소에서'git merge' 자체가 30 분이 걸리는 것을 보았습니다. 아마 너의 것이 * this * 큰 것은 아니지만 병합을 반복하면 범인이 될 수있다. 대화 형 리베이스는 셸 스크립트로 변경 되었기 때문에'-x' 플래그를 설정하고 작동하는 것을 관찰하여 지연이 어디인지 확인할 수 있습니다. – torek