Codesigner

Git에서 브랜치를 병합하는 방법은 두 가지가 있다. 첫 번째는 Merge이고 다른 하나는 Rebase이다. 이번 포스팅에서는 Rebase가 무엇인지, 어떻게 사용하는지, 좋은 점은 무엇인지, 어떤 상황에서 사용하고 어떤 상황에서 사용하지 말아야 하는지 알아보도록 하자 Rebase 기초 다음과 같은 브랜치의 모습을 가정하자 위 두 브랜치를 합치는 가장 쉬운 방법은 이전에 배웠던 merge 명령을 사용하는 것이다. 두 브랜치의 마지막 커밋(C3, C4)과 공통 조상(C2)을 사용하는 3-way merge로 다음과 같은 새로운 커밋을 만들어낸다 비슷한 결과를 만드는 다른 방식으로, C3에서 변경된 사항을 패치(Patch)로 만들고 이를 다시 C4에 적용시키는 방법이 있다. Git 에서는 이러한 방식을 Reb..

지금까지 우리는 한 사용자가 Git을 다루는 방법들에 대해서 배웠다. 사실, Git은 다른 사람들과 함께 작업할 수 있는 유용한 협업 툴을 제공해준다. 이를 활용하는 방법을 배우기에 앞서, 당신이 초등학교 선생님이라고 가정하자. 당신은 동료 선생님인 Alice를 포함하는 여러 선생님들과 함께 과학 시험 문제를 만들어야 한다고 하자. 다른 선생님들과 협업하기 위해선 당신과 Alice는 다음과 같은 요구조건을 필요로 한다: 당신의 컴퓨터에는 과학 시험 문제의 완전한 복사본이 존재해야 한다 당신을 포함한 다른 선생님들의 문제 출제 작업을 추적하고 살펴볼 수 있어야 한다 특정한 버전의 시험 문제에 접근할 수 있어야 한다(문제를 잘못 출제할 우려가 있으므로) 우리는 remotes 라는 공유된 Git 레포지토리를 ..

이전 포스팅에서 master와 samsung 브랜치가 깔끔하게 merge 되었다. samsung 브랜치에서 커밋 한 이후 master에서 merge 하기 전에 아무런 작업을 하지 않았기 때문이다. 그래서 Git 은 간단히 master를 업데이트시킬 수 있었고, 이를 'Fast-forward'라고 한다고 배웠다. 그런데, 만약 master 에서 merge 하기 전에 커밋을 생성한다면 어떻게 될까? 더 나아가, master 에서도 samsung 브랜치에서 작업한 것과 동일한 작업을 한다면? 이러한 상황에서 merge 하게 되면, Git은 당신이 어떤 변경사항을 받아들이고자 하는지 몰라서 conflict를 발생시킨다. 이를 merge conflict라고 한다. merge conflict I 이전 포스팅을 잘 ..

이전까지의 포스팅에서는 master(마스터)라고 불리는 단 하나의 브랜치 상에서만 작업하였다. Git에서는 실험적으로 테스트하기 위함이나 기능별로 프로젝트를 분리할 수 있는 branch(브랜치)들을 만들 수 있게 해 준다. 우리가 소설을 쓰면서 해피엔딩과 배드 엔딩 두 가지를 고려하고 있다고 생각해보자. 우리는 'happy'라는 새로운 브랜치를 만들어서 해피 엔딩으로 소설을 써내려 갈 수 있고, 같은 맥락으로 'bad'라는 브랜치를 만들어서 배드 엔딩 스토리를 써내려 갈 수 도 있다. 이 'happy' 브랜치와 'bad'브랜치에서 작업한 내용들은 당신이 master 브랜치에 merge(병합) 하기 전까지는 서로 독립적으로 존재한다. 즉, 아무 영향을 끼치지 않는다. 이번 포스팅에서는 Git의 branch..