이 형식의 branch명령 (시작점 포함)을 사용하는 경우 현재 위치 HEAD는 중요하지 않습니다 .
당신이하는 일 :
git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
먼저, 당신은 당신 HEAD의 지점 을 설정합니다 dev.
둘째, commit시 새 분기를 시작합니다 07aeec98. 이 커밋에는 bb.txt가 없습니다 (github repo에 따라).
방금 체크 아웃 한 위치에서 새 분기를 시작하려면 시작 지점없이 분기를 실행할 수 있습니다.
git branch test
또는 다른 사람들이 대답했듯이 한 번의 작업으로 분기 및 결제 :
git checkout -b test
07aeec98지점의 일부 라는 사실에 혼란 스러울 수 있다고 생각합니다 dev. 이 커밋이의 조상이라는 것은 사실이며 dev의 최신 커밋에 도달하려면 변경해야합니다 dev. 그러나 최신 버전에 도달하는 데 필요한 다른 커밋 dev이며 07aeec98.
8480e8ae(bb.txt를 추가 한 위치) 예를 들어 07aeec98. 에서 분기하는 경우에서 07aeec98도입 한 변경 사항을받지 못합니다 8480e8ae.
즉, 분기 A와 분기 B를 분기 C로 병합 한 다음 A의 커밋에 새 분기를 생성하면 B에 변경 사항이 도입되지 않습니다.
여기서도 마찬가지입니다. 두 개의 병렬 브랜치 master 및 dev가 있는데 dev에 병합했습니다. 마스터 커밋 (병합 이전)에서 분기하는 것은 dev의 변경 사항을 제공하지 않습니다.
마스터의 새로운 변경 사항을 기능 브랜치 에 영구적으로 통합하려면 병합 master하고 계속해야합니다. 그래도 기능 분기에 병합 커밋이 생성됩니다.
기능 브랜치를 게시하지 않은 경우 업데이트 된 마스터에서 리베이스 할 수도 있습니다 git rebase master featureA.. 가능한 갈등을 해결할 준비를하십시오.
병합 커밋없이 기능 브랜치에서 작업 할 수 있고 마스터의 최신 변경 사항과 통합 할 수있는 워크 플로를 원한다면 다음을 권장합니다.
- 모든 새로운 기능 브랜치를 마스터 커밋에 기반
dev마스터 커밋에 브랜치 생성- 기능 브랜치가 마스터의 새로운 변경 사항과 어떻게 통합되는지 확인해야하는 경우 마스터와 기능 브랜치를 모두
dev.
dev직접 커밋하지 말고 다른 분기를 병합하는 데만 사용하십시오.
예를 들어 기능 A와 B에 대해 작업하는 경우 :
a---b---c---d---e---f---g -master
\ \
\ \-x -featureB
\
\-j---k -featureA
분기를 분기에 병합 dev하여 새 마스터와 잘 작동하는지 확인합니다.
a---b---c---d---e---f---g -master
\ \ \
\ \ \--x'---k' -dev
\ \ / /
\ \-x---------- / -featureB
\ /
\-j---k--------------- -featureA
기능 브랜치에서 계속 작업하고 마스터 및 기능 브랜치 모두에서 새로운 변경 사항을 dev정기적으로 병합 할 수 있습니다 .
a---b---c---d---e---f---g---h---i----- -master
\ \ \ \
\ \ \--x'---k'---i'---l' -dev
\ \ / / /
\ \-x---------- / / -featureB
\ / /
\-j---k-----------------l------ -featureA
새로운 기능을 통합 할 때가되면 기능 분기 ( dev!가 아님)를 마스터로 병합하십시오 .
