본문 바로가기

Git

(24)
Git cherry-pick 충돌 저희가 Topic 2 버전을 cherry-pick 하기 위해서는 Topic 1 버전과 Topic 2 버전의 차이점을 찾아내야 합니다. 이 버전간의 차이점을 찾기 위해서는 3 way merge 방법을 쓰면 되는데요. 3 way merge를 이용하여 base를 Topic 2의 이전버전을 지정하면 t2라는 부분이 추가된 것을 알 수 있습니다. 이 두 버전의 어떤 변경점이 있었는지, Version 5가 만들어졌을때의 working copy를 비교해서 cherry-pick 한 결과인 Version 6을 만들 수 있는겁니다. 그렇다면 Version 6에서 무엇이 만들어질까요? 아마 첫줄은 Version 3( base ) 에는 변화가 없으므로 base 내용이 그대로 들어올 것 입니다. 다음 줄은 변화가 생긴 m1이 ..
Git rebase rebase을 배우기 위해서는 base라는 개념을 알고 있어야 하는데요. 쉽게 말하자면 base는 공통의 조상이라고 생각하면 되고 이 말이 이해가 안되신다면 전에 올려놓았던 게시글을 봐주시면 감사하겠습니다. m1 -> m2 rebase는 a -> b -> [c] t1 -> t2 topic으로 rebase를 한다는 것은 main 브렌치의 조상인 c base를 m1의 조상을 t2 버전으로 가르키는 것 입니다. 이렇게 선형적으로 로그를 볼 수 있게 말이죠! a -> b -> [c] -> t1 -> [t2] -> m1 -> m2 우선 디렉토리를 새로 만들어주었고 초기화, 파일 생성, 브렌치 생성을 해주었습니다. 현재 base는 init이 되는 것이고 main 브렌치에 2개의 버전을 추가해줬습니다. 이제 브렌치를..
Git cherry-pick 먼저 초기화를 해주고 두개의 branch을 만들겠습니다. 그리고 이 두개의 branch의 각각의 작업해주고 합칠겁니다. 이때 하나의 파일을 수정하게 되면 충돌과 같은 복잡한 이슈가 발생할 수 있기 때문에 버전을 만들때 마다 파일을 생성하겠습니다. 세미콜론을 써서 한번에 명령을 실행하겠습니다. touch init.txt; git add init.txt; git commit -m "init" 그다음 branch을 만들어주겠습니다. git branch topic 두개의 브렌치가 생성된 것을 확인하였습니다. 그리고 현재 있는 main 브렌치에서 새로운 파일을 만들고 add, commit 하겠습니다. 이번에도 똑같이 main 브렌치에서 새로운 파일을 만들고 add, commit 하겠습니다. 이번엔 브렌치를 옮겨 ..
Git cherry-pick & rebase Git을 사용하다 보면 여러가지 topic branch들이 생기고, topic 브렌치의 한 버전을 콕 찝어 merge 하고 싶은 경우가 생길 수 있습니다. 바로 그런것을 가능하게 해주는 것이 cherry-pick 인데요. 특정한 커밋 하나만 픽업해서 다른 커밋과 붙일 수 있는데요. 또 이런 문제가 생길 수 있습니다. 이렇게 병합을 진행하다 보면 작업의 흐름이 병렬적으로 흐르는데요. 이것이 수십개 수백개가 된다면 이 것을 이해하는데 정말 어렵겠죠? 그렇다면 마치 topic 작업을 끝낸후에 이어서 main 작업을 한 것처럼 나타낼 수 있다면 얼마나 좋을까요? 이렇게 말이죠. 이렇게 되면 일렬로 이어지는 작업을 볼 수 있어 이 작업이 어떻게 진행되어있는지 직관적이게 파악할 수 있겠죠? 이런 기능을 해주는 것이..
Git CLI 협업3 (fetch) 보통 저희가 작업을 할때는 git pull -> commit -> push 이런 순으로 진행을 할 것입니다. 이번시간에는 fetch을 통해서 push을 할 수 있고, git fetch -> git merge FETCH_HEAD -> commit -> push fetch을 통해서 어떤한 장점이 있는지 살펴보겠습니다. 로그를 보시면 초록색 main 이라고 보이시는 것이 저희의 지역저장소의 main 브렌치이고, 빨간색의 origin/main 이라는 것은 저희의 원격저장소 중에 origin이라는 이름의 저장소의 main 브렌치를 가르킵니다. 그리고 이 앞의 노란색 커밋 ID는 마지막으로 메인 브렌치의 어떤 버전을 가져왔는지 의미합니다. 그럼 a 디렉토리를 수정해보겠습니다. 그리고 커밋도 마치겠습니다. 그다음 로..
Git CLI 협업2 지난 시간에 두개의 컴퓨터로 가정하고 a,b 라는 디렉토리를 만들었습니다. bash창을 두개를 켜서 각각의 컴퓨터라고 가정을 하고 실습해보겠습니다. a라는 디렉토리에 2a 라는 내용을 추가해주었고요. 커밋까지 완료 해주었습니다. push 까지 해주겠습니다. 그리고 원래라면 b라는 디렉토리에서 원격저장소에 pull로 당겨온 후에 작업을 해야하는데 깜박해서 그냥 b에서도 똑같이 작업을 했다고 가정해보겠습니다. 그리고 커밋을 해주겠습니다. 그렇다면 a에서 최신버전으로 작업을 했는데 b에서 pull을 안하고 작업을 해서 최신버전이 갱신되었죠? 둘이 동시에 작업하는 경우일 수도 있겠고요. 그럼 작업을 끝냈으니 push을 하게 되면 어떤 상황이 벌어지는지 보겠습니다. git에서 reject [거절] 하였습니다. 그..
Git CLI 협업 이제부터 협업을 위한 git을 공부해볼 것입니다. 먼저 시작전에 폴더 하나를 만들어주고 시작하겠습니다. (똑같이 만드셔도 되고 다른 이름으로 만들어주셔도 됩니다.) Git Bash를 켜 해당 디렉토리로 이동해줍시다. 이렇게 준비는 끝이 났습니다. 첫번째로 명령어를 사용하여 디렉토리를 만들어주고 초기화 하였고요. A라는 사람이 디렉토리 안에서 혼자 작업한다고 가정하겠습니다. 버전을 하나 만들기 위해서 nano 에디터 사용해 work.txt 만들어 주었고요! (이제는.. 코드 없이 직접해봐야겠죠?) 이후 올리고 버전으로 만들었습니다! 이제 백업을 하기 위해 깃허브로 이동하여 레파지토리를 만들어주겠습니다! HTTPS 주소를 복사를 해놓겠습니다. 지역저장소와 원격저장소를 연결해주었습니다. 자, 이제 git pu..
Git CLI merge & conflict 병합 여러분들이 커밋을 하면 순차적으로 버전이 만들어지겠죠? (기본적으로 master or main 브렌치) 이 상태에서 여러분이 apple branch를 만들고 checkout해서 새로운 버전을 만든다면 이 버전은 apple branch 소속이 되겠죠? 그리고 여러분이 master 브렌치에 있는 상태에서 version 3 master 버전으로 가 다시 google 브렌치를 만들고 버전을 만들게 되면 master 브렌치를 기반으로하는 google branch 소속이 될 것 입니다. 여기서 다시 master로 checkout 하여 version을 만들게 되면 version 4가 되는 것이고요. 만약 apple branch에서 작업하던 내용이 master branch에도 유용할 것 같다면 어떨 것 같습니까? me..
Git CLI branch 저희 이제 실습을 하기전에 준비를 먼저해야겠죠? 저는 git폴더에 manual 이라는 새 디렉토리를 만들어주었습니다. git mkdir manual 다음은 지역지장소 선언해주시고요. git init 저희는 work.txt를 수정해가면서 작업을 할 것이고요. nano work.txt 이게 왜 안될까요?? 예전에 설명했었지만 처음 파일을 만들고 Area로 올리기 위해선 add먼저 해주었어야 했죠.. git commit -am "work 1" git add work.txt git commit -m "work 1" 자 이제 commit 을 똑같은 부분을 2번 더 할 것인데요. 완성본은 이렇게 되었습니다. git log 앗 저처럼.. 커밋 메세지를 잘못쓰셨다고요? 마지막 커밋 메세지 고쳐봅시다.. git comm..
Git CLI branch & conflict Branch는 대체 무엇일까요? 여러분이 제품 사용설명서를 만드는 사람이라고 상상해봅시다. 현재 이것을 깃 버전관리를 하고 있었는데요. 그렇다면 여러분들의 작업은 순차적으로 버전이 만들어질 것입니다. 그런데 제품이 출시하면서 문제가 생겼습니다. 계약하자는 고객사가 많아졌는데 고객사마다 요구사항이 다 달랐죠. 그렇다면 고객사마다 사용설명서도 달라지겠죠? 지금까지 우리가 작업했던 저장소는 마스터 브렌치 라고 가정하겠습니다. git branch -M master 우선 각각의 고객사마다 제품설명서 마스터 저장소 디렉토리(A,B,C)를 복사해서 고객사 이름을 붙였죠 (master,애플,구글) 그리고 애플은 애플마다 위한 구글은 구글마다 새로운 버전을 만들었는데.. 뭔가 좀 비효율적? 이라고 생각했습니다. 고객사가..