git-flow는 개발 된 것보다 마스터에서 더 압축 된 히스토리를 볼 수 있습니까?

Question

여기 내 무지를 실례합니다.하지만 "git-flow" 모델을 연습에 넣으려고합니다 (수동으로 git-flow 도구 모음없이).

재미있는 한 가지 개념은 모든 커밋이 선의의 실행 가능한 릴리스 인 마스터 브랜치가있을 것이라는 아이디어였습니다. 따라서 v1.0.0 커밋을 마스터 태그로 설정 한 다음 v1.1.0 태그를 사용하면 master를 볼 때 2-commit-long 로그가 좋습니다. 그러나 v1.2.0을 출시 할 준비가되었고 develop 지점에는 1000 개의 중간 커밋이 있지만 이제는 로그 오프하고 "예, 출시시기"라고 말하기 버튼을 누르십시오..

제 목표는 마스터 타임 라인에 세 번째 커밋을 추가하는 것입니다. --squash 옵션을 사용하면 하나의 커밋을 마스터에 추가 할 수 있으므로 마스터 로그를보고 v1.0.0, v1.1.0 및 v1.2.0의 세 커밋을 볼 수 있습니다. 개발 지사가 길고 길다면, 스쿼시는 각 버전이 공식 릴리스 인 마스터에 대한 깔끔한 역사로 여러분을 끌어들입니다. 중간 개발을 포기할 기회는 없습니다!

나에게 문제가되는 것은 네트워크 그래프를 보면 "단절된"커밋을 생성한다는 것입니다. Git이이 세 번째 커밋을 개발 지사에 추가 한 수천 개에 달하는 것을 이해한다는 명백한 관계는 없습니다. 손으로 그린 ​​그림과는 달리 항상 물건을 가리키는 것과는 달리 혼자서 뜨는 것 같습니다. 제 (여러 부모 일명) "화살표를 병합"얻을 병합에 대한

다른 옵션은 중간 커밋에 대한 연결을 설정하는 부작용을 갖고있는 것 같다. 그래서 갑자기 주인님은이 축복받은 3 가지 커밋뿐만 아니라 ... 개발 된 1000 가지 커밋의 전체 역사를 포함하도록 확장되었습니다. 마스터의 포인트가 릴리스 가능한 버전 만 포함하는 지점 인 경우 종류가 목적을 무력화시키는 것 같습니다.하지만 갑자기 모든 중간 상태가 마스터에 커밋을합니다. 3 개의 마스터 커밋 대신 1003

눈금 표시는 가지에서 중복되는 것을 비웃는 점에서 조금 불길한 점입니다. 그래서 자식 - 흐름에 그려진 다이어그램은 그림이며 git log 등의 터미널 출력물이 아닙니다. 마스터는 릴리스 가능 버전으로 만 구성된다는 것을 말하는 것과 같은 성명에서 기대할 수있는 것이 확실하지 않습니다.

짧은 설명 : 전체 커밋 기록을 보유하지 않는 한 릴리스 시점에서 개발과 마스터 사이에 "화살처럼 보이는"관계를 유지하는 옵션을 찾을 수 없습니다. 화살표를 많이 가지고있는 git-flow 다이어그램을 보면이 점이 걱정 스럽습니까? 앞서 설명한 시나리오에서 마스터 기록을보고 병합 된 모든 중간 개발 버전과 1003 커밋 히스토리 또는 3 커밋 히스토리를 확인해야합니까?

Answer 1

git-flow는 개발 된 것보다 마스터에서 더 압축 된 기록을 볼 수 있습니까?

아니요. 기본적으로 (핫픽스 및 릴리스 후보 분기 무시) : master = 개발 + 병합 커밋.

내가 설명한 시나리오에서 병합 된 모든 중간 개발 버전과 1003 커밋 내역 또는 3 커밋 내역을 확인해야합니까?

귀하가 요청한 마스터 기록의 특정보기에 약간의 차이가 있습니다.하지만 일반적으로 1003 커밋의 기록을보아야합니다. 자식 흐름에

역사

더 일반적으로, 당신의 묵시적 가정의 일부에 따기 : 이 역사를 저지 연결 및 을 보존에 대한 자식 흐름을 사용하여. 따라서 --squash과 병합하는 것은 절대적입니다. 이미 살펴본대로 이 아니고은 릴리스 상태가되는 개발 라인에 마스터를 연결합니다. 그 반대의 경우, 마스터에 대한 모든 커밋이 항상 병합 커밋 - 완전히 --squash과 반대입니다. 그래서 은 항상과 을 git-flow로 병합합니다. (망할 놈의 현대 버전에서는 false에 merge.ff 옵션을 설정하고 --no-ff을 잊고 걱정 중지 할 수 있습니다.)

는 또한 빈센트 Driessen의 original git-flow article않습니다이 질문을 검토 있습니다.

편평의 것이 얼마나 위험한지은

는 평면 (선형) 뷰 선형 모양으로 전체 그래프를 단순화하기 위해 평탄화 전략을 사용해야합니다 것을 알고 있어야합니다. 이 병합은 혼란 스러울 수 있습니다.

예를 들어, 예제 그래프에서 두 번째 시안 노드와 다섯 번째 노란색 노드를 생각해보십시오. 이제 두 번째 청록색 커밋은 다섯 번째 노란색 커밋 이후 하루가 지난 것으로 가정합니다.

---1-----------------7----------10~~ master 
    \   /  /
    2---3---4---5--6-----8---9~~~~~ develop 

(나는.이 자식 흐름의 맥락에서 다소 인위적인 예입니다 알고 릴리스 후보 가지 않고, 그것을 해제 "두 번째 새로운"마스터로 병합하여 개발에서 커밋 매우 이례적인 일이다 .)

이 기록을 master 관점에서 평평하게하면 어떻게 표현할 수 있습니까? 당신이 주로 따라서 당신에게주는 연대 기적 순서를 사용해야합니다

이

10 9 8 7 6 5 4 3 2 1 

을 (.이 연대 기적 순서는 "커밋"무엇을 기본 git log와 Github에서의이다보기 당신을 줄 것이다) 또는 당신은에 의해 통합 된 커밋을 원하는 것 병합 커밋은 모두 서로 옆에 나타 납니까?

10 9 8 6 7 5 4 3 2 1 

을 아니면 하나 개의 조상 라인에 따른 커밋 싶어 (이 "위상"순서는 git log --topo-order가.을 보여줍니다 예를 들어, 무엇인가)?

10 7 1 

가 (이 가장 밀접하게 당신이보고 기대의 일부가 보인다 "마스터 만 직접 커밋 보여줘"요청에 해당합니다. 자식 흐름 설정에서 마스터 git log --first-parent 당신에게 보여줄 것이다 이보기.)