Codesigner

저번 포스팅에서 rebase 가 무엇이고, 어떻게 활용하는지 알아보았다. 간단하게 정리해보자면, 브랜치를 병합하는 merge와는 또 다른 방법으로 각 커밋들의 변경 사항들을 차례대로 basebranch에 반영하여 결과적으로 선형적인 커밋 히스토리를 만들어 내는 기능이었다. 이번 포스팅에서는 이러한 작업을 대화형(interactive) 인터페이스를 제공함으로써 좀 더 정교한 작업을 가능하게 해주는 -i 옵션에 대해 알아보도록 하자 git rebase -i git-scm에서는 -i 옵션에 대해 다음과 같이 설명하고 있다 Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. Thi..

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

Git에서는 tag(태그)를 지원한다. 이는 보통 릴리즈 할 때 사용되는데(v.1.0, 등), 이번 포스팅에서는 태그를 생성하고 조회하는 법 그리고 서명하고 검증하는 법과 공유하는 법, 태그의 두 종류를 알아보도록 하자 git tag - 태그 조회하기 Git 프로젝트에서 이미 만들어진 태그가 있는지 확인하는 명령은 다음과 같다 git tag 위 명령은 태그들을 알파벳 순서로 나열한다. 검색 패턴을 사용하여 태그를 검색할 수도 있는데, 예를 들어 여러 가지 버전 중 1.1.3 버전의 태그들만 검색하고 싶다면 다음과 같이 명령할 수 있다 git tag -l 'v1.1.3.*' 위 명령은 v1.1.3.1, v.1.1.3.2 등 1.1.3 버전들을 나열한다 태그의 두 종류 - Annotated & Lightwe..

저번 포스팅에서는 science-quizzes라는 remote 레포지토리를 만들고, 이를 클론 하여 my-quizzes라는 로컬 레포지토리를 생성하였다. 그리고 science-quizzes에서 변경한 내용을 my-quizzes에 적용시키는 것 까지 실습하였다. 이번 포스팅에서는 Git을 활용한 teamworking의 workflow를 알아보고 my-quizzes에서 만든 변경사항을 science-quizzes에 적용해보며 저번 포스팅에서 배웠던 내용들과 함께 teamworking 방법을 정리해보는 시간을 가져보자 Git workflow 현재 우리는 origin/master에 있는 내용을 master 브랜치에 merge 하였다. 즉, remote 의 변경사항을 내 로컬 레포지토리에 적용시킨 것으로 내 로컬..

지금까지 우리는 한 사용자가 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 이전 포스팅을 잘 ..