Project Management/Git & Github (26) 썸네일형 리스트형 [Chapter 5] Case Study(3) - cherry pick 이번 시간에는 실제로 자주 이용되는 '체리픽' 기능에 대해서 살펴보도록 하겠습니다. 우선, 이 과정을 실습하기 위해서는 다음과 같이 해당 프로젝트의 브랜치 운영 원칙이 정의되어 있어야 합니다. 다음과 같은 브랜치 운영 전략을 예시로 들겠습니다. · 기본적으로 [master] 브랜치를 운용한다. · 기능 추가 등이 필요할 때, [master]에서 [feat/xxx] 피처 브랜치를 따서 개발을 진행한다. ▷ 기능 추가가 완료되면 [master]로 병합한다. ▷ [master]로 병합된 내용은 dev._____.com에 반영되어 확인이 가능하다. · 일정 단위로 개발이 완료가 되면, [master]에서 latest 브랜치에 병합한다. ▷ [latest]에 병합된 내용은 실제 라이브 서비스에 반영된다. 위의 내.. [Chapter 5] Case Study(2) - amend : 커밋 수정하기 우선, 아까 만든 원격 저장소에서 새로운 기능을 개발하여 커밋을 진행했다고 생각해 봅시다. 그런데, 커밋을 생성한 직후에 사소한 변경 사항이 추가로 발생했습니다. 이 경우, 반드시 또 하나의 커밋을 새로 생성해야 할까요? 새로운 커밋을 하나 더 추가로 생성하지 않고도 수정이 가능할지, amend 기능을 살펴보겠습니다. ○ 푸시가 되지 않은 커밋 변경사항 수정하기 우선 새로 만든 로컬 저장소(git_casestudy)에서 새로운 파일[amend.md]를 하나 생성하고, 첫 줄에 "어멘드 생성"이라는 라인을 하나 남겨보겠습니다. 그리고 이 파일을 스테이지에 올린 다음 [어멘드 파일 생성]이라는 커밋을 만들어 보겠습니다. 단, 아직 푸시까지는 진행하지 않습니다. 커밋까지만 진행하고, 원격 저장소로 푸시를 진행.. [Chapter 5] Case Study(1) - 신규 repository 생성 이제 지금부터는 좀 더 복잡한 상황을 상정하고, 기존 챕터에서 배우지 않았던 여러 가지 기능들과 저장소 관리와 관련된 개념들을 하나씩 살펴보겠습니다. 우선, 이번 챕터부터는 기존의 [git study] 저장소와 별개로 새로운 저장소를 생성하여 처음부터 다시 실습을 진행하려고 합니다. 근본적으로 다시 살펴봅시다. Git(hub)에서 관리하는 프로젝트를 생성하는 절차는 어떻게 진행이 되었을까요? 기존에 1~4 챕터에서 우리가 프로젝트를 생성한 절차는 다음과 같습니다. PC에 로컬 저장소 생성 → Github에 repository(원격 저장소) 생성 → 로컬 저장소에 원격 저장소 주소를 remote add 일단 위의 방식은 'PC에 로컬 저장소 생성'을 가장 먼저 수행하였습니다. 그리고 github에 repo.. [Chapter 4] 복수의 repository로 협업(2) - rebase 4 이제 앞서 설명한 rebase 기능을 실제 우리의 실습 repository에서 적용해 보도록 하겠습니다. 우선 이번 실습 역시 NEWBIE의 입장에서 진행된다는 것을 생각해 주세요. 아래의 히스토리 그래프를 보면, NEWBIE의 [선물하기 기능 추가]라는 커밋의 베이스 커밋은 [즐겨찾기 기능 추가] 커밋임을 알 수 있습니다. 우리의 목적은 NEWBIE의 [선물하기 기능 추가] 커밋을 떼어내서 이 커밋의 베이스 커밋을 [개발자 NEWBIE 추가] 커밋으로 바꿔치기하는 것입니다. 우선, 현재 상태에서 우리가 베이스로 고치려고 하는 대상의 커밋 - 즉 [개발자 NEWBIE 추가] 커밋을 우클릭하고 "재배치(rebase)"를 클릭합니다. 자신의 현재 커밋인 [선물하기 기능 추가]를 rebase 하겠냐는 질문입니.. [Chapter 4] 복수의 repository로 협업(2) - rebase 3 꽤 어려운 과정을 진행하고 있습니다. 앞의 내용이 기억이 나지 않는다면, 앞의 rebase 과정을 다시 한번 살펴보고 오시기를 추천합니다. 이제 충돌 해결 과정을 통해서 rebase 기능에 대해서 살펴보도록 하겠습니다. [Chapter 4] 복수의 repository로 협업(2) - rebase 1 앞선 과정을 통해, NEWBIE가 본인의 포크 된 원격 저장소를 통해 "favorite.md"를 새롭게 추가한 내용까지 원본 저장소에 병합을 진행하였습니다. 이제 다음 상황을 가정해 보겠습니다. NEWBIE가 추가로 nozeroslope.tistory.com [Chapter 4] 복수의 repository로 협업(2) - rebase 2 이전 아티클에서 세팅한 ME와 NEWBIE의 원본 / 원격 저장소의 상태.. [Chapter 4] 복수의 repository로 협업(2) - rebase 2 이전 아티클에서 세팅한 ME와 NEWBIE의 원본 / 원격 저장소의 상태를 다시 한번 되짚어 보도록 하겠습니다. 이제 현재까지 ME의 원본 저장소와 NEWBIE의 원격 저장소 상태를 정리해 봅시다. 일단 두 저장소 모두 '즐겨찾기 기능 추가' 커밋까지는 동일합니다. 하지만, NEWBIE는 이다음 단계에 'favorite.md' 2번 라인에 "선물하기 기능 추가"가 추가되었습니다. ME는 원격 저장소에서 'favorite.md' 2번 라인에 "포인트 지급 기능 추가"가 추가되었습니다. 그리고 여기에 더해 'readme.txt'파일에 NEWBIE 텍스트도 하나 더 추가해 둔 상태입니다. 이제 이 저장소에서 풀 리퀘스트가 일어난다면, 충돌이 발생하겠죠? (favorite.md 2번 라인 때문에) 아래의 각 저.. [Chapter 4] 복수의 repository로 협업(2) - rebase 1 앞선 과정을 통해, NEWBIE가 본인의 포크 된 원격 저장소를 통해 "favorite.md"를 새롭게 추가한 내용까지 원본 저장소에 병합을 진행하였습니다. 이제 다음 상황을 가정해 보겠습니다. NEWBIE가 추가로 favorite.md에 선물하기 기능(라인)을 추가하고 다시 풀 리퀘스트를 보냈는데 - ME가 작성한 코드와 충돌이 났습니다. 그럼 이 충돌을 해결하기 위해 우리가 앞서 배웠던 것처럼 원본의 브랜치를 내 브랜치로 병합한 다음 충돌을 해결하고 다시 풀 리퀘스트를 보내게 됩니다. 하지만, 이렇게 작업을 진행한 후 풀 리퀘스트를 보낸다면 선물하기 기능 뿐만 아니라 충돌 해결 과정까지 모두 포함된 병합 커밋이 생기게 됩니다. 이 상황에서 불필요한 커밋은 제외하고 '선물하기 기능 추가' 커밋만 보내야.. [Chapter 4] 복수의 repository로 협업(1) - fork 3 : pull request 앞선 포크 실습과정을 통해서 ME의 원본 저장소를 통째로 복사하고, NEWBIE가 새로운 커밋(즐겨찾기 기능 추가)을 생성해 푸시까지 진행하는 절차를 거쳤습니다. 이 과정을 완료했지만, 아직 원본 저장소에는 해당 커밋이 반영되지는 않은 상태입니다. 이제, 이 NEWBIE의 원격 저장소에 반영된 커밋을 원본 저장소에도 반영하도록 하겠습니다. 일단 우리가 배웠던 풀 리퀘스트(pull request)를 진행해야 합니다. 사실 우리가 하려는 작업의 본질은 'NEWBIE'의 브랜치와 'ME'의 브랜치를 합치는 과정과 같다고 생각해도 됩니다. 우선 NEWBIE의 github 페이지로 로그인해서 들어가 보겠습니다. 상단에 보면 "This branch is 1 commit ahead of ME:master"라는 메시지.. 이전 1 2 3 4 다음
