중간에 dev를 병합했을 때 커밋을 어떻게 스쿼시합니까?

Question

며칠 동안 기능 지사에서 작업했으며 이제는 dev으로 병합 할 준비가되었습니다. 이 기능을 사용하면서 dev과 병합하여 패치를 받았습니다. 내 역사는 다음과 같습니다

* E (feature1) 
* D:merge with dev 
| \ 
* C * B:patch (dev) 
    \ | 
    * A 

내가 다음 dev 및 빨리 감기 dev와 병합 커밋 하나에 전체 분기를 납작하게하고 싶습니다. 문제는 E은 C으로 병합 할 수 없기 때문에 C으로 스쿼시 할 수 없다는 것입니다. 유일한 옵션은 E, B 및 C (새로 커밋을 F이라고 함) 스쿼시 인 것 같습니다.이 경우 스쿼시 된 커밋에는 관련없는 패치의 일부인 변경 사항도 포함됩니다. dev에 병합되면 F (패치 적용 및 기능 추가)과 B (패치 만 적용)이라는 두 가지 커밋이 적용됩니다. 게다가 F은 두 가지 무관 한 변화를 일으킬 것입니다.

내 기록을 멋지게 정리하는 방법이 있습니까? 내 워크 플로를 변경해야합니까?

Answer 1

자식은 커밋의 변경 내용을 추적하지 않습니다. 각 커밋에는 repo에있는 파일의 전체 복사본이 들어 있습니다. "변경"은 두 커밋을 서로 다르게하여 결정됩니다.

그래서, 짧은에, 절대적으로 F 커밋에 E, B 및 C을 부수 다음 dev에 지점에 그 병합에 문제가 없습니다. B 커밋은 dev 브랜치에 여전히 존재합니다. git이 F을 B과 비교하면 C과 E에 의해 도입 된 변경 사항 만 F으로 표시됩니다.

물론이 문제는 git rebase을 사용하여 해결할 수 있지만 그 자체의 두통이 있습니다. 예를 들어, git rebase은 분기 히스토리를 변경하기 때문에 (커밋을 dev에서 최신 커밋의 맨 위로 이동), 충돌이있는 경우 rebase 할 때마다 이러한 충돌을 다시 해결해야합니다. 문제가 해결되는 데 시간이 오래 걸리면 dev에 최신 상태를 유지하기 위해 몇 가지 리베이스가 필요합니다.

---

그냥이 모든 사실이 있음을 입증하고 당신이 걱정할 필요가 없다고, 내가 설정을 예를 들어 GitHub의의의 repo했습니다 : https://github.com/cyborgx37/sandbox

시작하기를, 우리는이있는의 dev branch이 B 커밋

B:patch 
| 
A 

은 그 때 나는 가지고 feature1 branch이 C, D 및 E 커밋 만들었습니다.

E 
| 
D:merge with dev 
|\ 
C \ 
| B 
A 

가 마지막으로 dev-with-feature1 branch있다 (D가 병합했고, 따라서이 부모님을 가지고 있기 때문에, 그 주, B 또한 커밋 역사에 표시).

F 
| 
B:patch 
| 
A 

나는 다음 dev에 떨어져이 분기를 생성, F는 하나의 커밋으로의 커밋 feature1을 모두 스쿼시

git merge --squash feature1 
git commit -m "F" 

을 사용했다.

diff for the F commit을 살펴보면 "패치 적용"이 표시되지 않습니다. B already contains those changes 이후로 F이 단지 이것을 반복하면 자식은 F과 연결되지 않습니다. 또 다른 관점에서

, here's the blame :

initial  hello! 
B:patch  patch! 
F   new feature!!! 

힘내 커밋의 변화를 추적하지 않습니다. 전체 프로젝트 상태를 저장합니다. "변경"은 커밋을 상위 (또는 전임자) 커밋과 비교하여 결정됩니다. B에 패치가 있기 때문에 git은 변경된 내용을 B과 연관시킵니다. 패치가 F에있을 것으로 예상됩니다. F에없는 유일한 방법은 패치를 삭제했는지 여부입니다.

Answer 2

정확하게 이해하면 B 위의 커밋 내용 전체를 E이 단일 커밋으로 적용하려고합니다. 이것은 당신이, 당신이 git checkout E .을 사용할 수 있습니다 무엇을 달성하고자하는 경우

(잊지 않는 ".") :

여기

# go to your `dev` branch : 
git checkout dev 

# get the *content* of E (here comes the ".") : 
git checkout E . 

# all the content of E should appear as modifications staged for commit : 
git status -sb 

# you can double check that the content is to your liking : 
git diff --cached # --cached means 'compare with the index' 
gitk --cached  # as opposed to 'compare with what is on the disk' 

# commit 
git commit 

Answer 3

내가 무슨 짓을했는지 : 나는 새에 E, B 및 C이 F를 저지 숙청 , F에 대한 메시지와 함께 feature1을 구현한다고 표시합니다 (지금까지는 패치도 추가합니다). 그런 다음 dev에 리베이스되었습니다. 이제 커밋 메시지와 기록은 정확합니다 : F에는 패치가 포함되어 있지만 추가하지 않았습니다. 이전 커밋에 의해 추가되었습니다.

마지막으로 dev (병합 완료를 강제하려면 --no-ff)과 병합되었습니다.

앞으로는 dev과 병합하지 말고 리베이스해야합니다.