수업소개
이 수업에서는 지금까지 배운 git으로 수련을 하실 수 있도록 공식 홈페이지의 내용을 소개해드립니다. 실행은 직접 해보시길 바랄께요. 그리고 fast forward와 merge commit의 차이점도 소개해드립니다.
Ruby Coin
Rails 와 프론트 엔드 기술을 이용해 흥미 위주의 빠른 웹 개발 방법론
댓글
-
recursive 안되고 conflict 나서 왜지 했는데 알려주셔서 감사합니다^_^ -
감사합니다. -
감사합니다!!!
-
커밋c0-c1-c2가 만들어진 상태에서,
브랜치 하나 만들고($git branch iss53), 그 브랜치로 들어가야겠다($ git checkout iss53)!
아웅 귀찮아, 한번에 하자.
그거슨 ==> $git checkout -b iss53
(현재상태)
master : c0-c1-c2
iss53 : c0-c1-c2-c3
여기서, master에게 긴급하게 만들어야할 (아마 단기적인) 브랜치가 생겼다! master로 체크아웃한 상태에서
$git checkout -b hotfix
이제 hotfix에서 작업(c4만듬) 다 하고나서, hotfix를 master에 merge할때, master로 체크아웃한 상태에서
$git merge hotfix 하면, Fast-forward(빨리감기)가 나옴.
[Fast-forward merge] (commit을 새로 생성안하고 merge한다)
master브런치 c2에 있는상태다. 근데 hotfix가 c4를 만들고 독립했다.
master브런치가 가르키는 commit을 hotfix가 가르키는 commit으로 빨리감기를 하면, 병합이 된다.
이걸 fast-forward라고 한다.
그 결과, master가 hotfix를 가르키게 되며, 이 merge작업을 하면 별도의 commit 생성없이 바로 c4를 가르키게 되는것이다.(wow)
hotfix는 이제 할 일(긴급하게 일시적인일) 다 끝났으니,
$git branch -d hotfix 로 없애줌.
(현재상태)
master : c0-c1-c2-c4 (c2에서 hotfix브런치 만들어서 hotfix에게 c4란 일시키고, hotfix가 c4를 만들면 hotfix있는곳으로가서(hotfix를 merge하면됨) hotfix를 죽여버림(!!), 그리하여 소리소문없이(별도의 commit없이) c4자리에 master가 위치함)
iss53 : c0-c1-c2-c3
심심하니 iss53에 c5하나 만들어서 연결시키셈(~-c3-c5)
이제 iss53을 master로 merge하면 'recursive' mergy를 함.
[fast-forward가 아닌 merge] (commit생성하고 merge하는 흔해빠진 merge)
fast-forward는 안됌.
(master가 c2에서 c4로 변화가 생겨서그럼)
master와 iss53의 공통의 조상(c2)를 찾고, 3-way merge라 하는 내부적인 방법으로 c4와 c5를 합치고,
이 둘을 합침을 알리는 commit을 새로 만듬(c6)
(현재상태)
master : c0-c1-c2-c4- (merge)c6
iss53 : c0-c1-c2-c3-c5 / -
* branch를 merge하는 방법 두 가지
1) Fast-forward
2) recursive strategy -
설명력이 좋으셔서 egoing님께서 넘기셔도 된다하셨지만 안넘기셔도 됩니다. 강의에서 충돌에대한 의문이 생길 것이고 그 다음강의에서 그 의문이 풀립니다.
-
감사합니다.
-
해당 문서 하단에 제 경우의 내용이 나와있네요. ㅎㅎ
다음 강좌에서 나올 것 같은데 일단 문서 내용은
충돌의 기초
가끔씩 3-way Merge가 실패할 때도 있다. Merge하는 두 브랜치에서 같은 파일의 한 부분을 동시에 수정하고 Merge하면 Git은 해당 부분을 Merge하지 못한다. 예를 들어, 53번 이슈와 hotfix가 같은 부분을 수정했다면 Git은 Merge하지 못하고 다음과 같은 충돌(Conflict) 메시지를 출력한다:
이네요. -
똑같이 따라해 봤는데
마지막 merge 에서 충돌 나네요. ㅜㅜ;
f2.txt. 파일하나만들어서 계속 수정하면서
commit 하고 로그 찍어서 진행 상태가 맞는지 확인했는데요
마지막 merge 실행시키면 다음처럼 뜨네요.
$ git merge iss53
Auto-merging f2.txt
CONFLICT (content): Merge conflict in f2.txt
Automatic merge failed; fix conflicts and then commit the result.
그런데 제 경험상 한 파일을 두명 이상이 따로 수정해서 작업하면
나중에 merge 할 때 충돌 발생하는 것이 정상적인거 같은데
Merge made by the 'recursive' strategy.
이 부분이 어떻게 가능한 것인지 궁금하네요.
다른 분들은 잘 되시는지? -
요약 버전 감사합니다.!
-
감사합니다.
-
https://git-scm.com < git의 공식홈페이지
공식메뉴얼이 있음 > Documentation > Book > 각각의 언어별로 있음
브랜치와 Merge 의 기초 > 패스포워드라는 방식과 아닌 방식으로 머지하는 방법이 나옴
그 것을 비교하는 내용임. 이 문서를 보고 수련을 했으면 좋겠음.
설명이 이해하기 어려운 것이 있음. 그래서 말로 설명해 드리겠음. 각자 수련해 보시기 바람.
기능의 추가/버그의 수정(<---어떤 일들이 생김)
깃에서는 바로 브랜치를 만듬(이슈 하나를 해결하기 위해서)
어떤 명령을 사용할까?
git checkout -b iss53
이것은 git branch "iss53" + git checkout iss53을 의미함(한줄로 적은 것임) (3:10)
내용을 수정하고 커밋을 하게되면 그림이 어떻게 바뀔까?
$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
이렇게 바뀌겠죠? 분기
그런데 급하게 처리해야 할 일이 생긴 것임. 그 일을 해결하기 위해 master브렌치에서 브랜치를 새로 생성할 것임.
$ git checkout master
$ git checkout -b hotfix <--hotfix 라는 브렌치를 새로 만듬
그리고 파일을 처리하고 커밋을 하면
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
그림의 모양이 바뀔 것임
hotfix의 일을 끝내고 master브렌치로 병합을
$ git checkout master
$ git merge hotfix
그 때 어떤 메시지가 뜨냐하면 Fast-forward
이것이 여러분이 머지를 했을 때 경험하는 첫번째 상황임
영어로 빨리 감기라는 뜻임
빨리 감기라는 것이 무엇일까?
hotfix브렌치 변경후 병합까지 master브렌치는 어떤 변화도 없었음
이상태에서 master브렌치로 hotfix브렌치를 병합한다는 것은
master브렌치를 hotfix브렌치로 빨리 감기를 하면 병합작업이 끝난다 > 이런 형식의 브렌치를 Fast-forward라고 부름
그리고 그 결과의 그림은 이렇게 됨(위에 올라탄 그림-master브렌치는 hotfix브렌치를 가리키게 됨)
그렇기 때문에 별도의 commit을 생성하지 않음.(별도의 커밋을 생성하는 것이 기본이지만)
마스터가 가리키는 커밋이 누구인지를 바꾸기만 함 > 그래서 이것을 Fast-forward라고 부름
그리고 hotfix가 끝났고 브렌치가 많으면 지저분 하므로 지움($ git branch -d hotfix)
그리고 다시 이슈를 처리함
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+)
커밋까지 함
그러면 그림이 이렇게 됨
일이 끝났으므로 > 마스터로 머지함.
이때 메시지가
$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
README | 1 +
1 file changed, 1 insertion(+)
제귀적인 전략 > 이슈53이 변하고 + 마스터도 변했음
이런 경우 패스트 포워드를 할 수 없음
그러면 깃은 내부적으로 어떻게 동작하냐 하면
1. 마스터와 이슈53의 공통의 조상을 찾음.
2. 3way merge라고 하는 내부적 방법을 이용하여 머지를 함.
3. 두개를 합쳤다라고 알려주고 두개를 합쳤다라고 하는 별도의 커밋을 만듬(자동으로)
그래서 차이점은? > 커밋을 생성(Fast-forward)하지 않고 생성하고 임('recursive' strategy)
이 아티클은 그런 이야기를 담고 있음. -
문서만 보고 하려 했으면 한참 걸릴 수도 있었는데 설명을 듣고서는 쉽게 진행할 수 있었습니다. 감사합니다.
