Project Management/Git & Github (26) 썸네일형 리스트형 [Chapter 4] 복수의 repository로 협업(1) - fork 2 앞선 과정을 통해, 원본 저장소 gitstudy를 포크 작업을 진행하여 NEWBIE가 본인의 원격 저장소에 복제하였습니다. 이제 우리는 NEWBIE의 입장이 되어, 본인의 PC에 설치된 소스트리와 로컬 저장소로 해당 리소스를 불러와 보도록 하겠습니다. 우선은 포크 되어서 새롭게 만들어진 NEWBIE의 원격 저장소에서 [Clone or download] 버튼을 클릭하여 해당 원격 저장소의 주소를 복사하겠습니다. 이제 소스트리를 실행합니다. 우리가 지금 사용하고 있던 소스트리의 탭의 '+' 버튼을 클릭하고 [clone]을 클릭합니다. 그리고 우리가 복사해 온 NEWBIE의 원격 저장소 주소를 입력하고, 로컬 저장소의 폴더를 지정합니다. 저는 기존에 만들어 놓은 원본 저장소의 로컬 저장소 폴더에 NEWBIE라.. [Chapter 4] 복수의 repository로 협업(1) - fork 1 지금부터는 기존에 우리가 만들어 실습을 진행해 온 원격 저장소(repository)를 '원본 저장소'로 통칭해서 부르도록 하겠습니다. 이제는 다음과 같은 상황을 가정할 것이기 때문입니다 - 지금 우리가 원본 저장소를 통해 어떠한 프로젝트를 진행하고 있는데, 외부 인력이 해당 프로젝트에 참여할 예정입니다 - 이제 우리가 작업해 온 원본 저장소에 외부 인력이 직접 접근하여 브랜치를 생성하거나 마스터 브랜치에 커밋을 직접 진행하는 상황은 막아야 하겠죠? 일단 참고로 설명드리면, 기본적으로 원본 저장소(repository)에 접근해 커밋을 진행할 수 있는 권한은 소유자가 원본 저장소의 [Settings] 탭의 [Collaborators] 메뉴에서 해당 계정을 추가해야만 합니다. 여기서 설명하는 원본 저장소를 통.. [Chapter 3] repository 협업(8) - Release 지금까지 commit과 merge, branch에 대해서 기본적인 사용 방법들을 알아보았습니다. 그런데, 우리가 기본적으로 git과 github(+소스트리)를 사용하는 목적이 '버전' 관리라고 했었습니다. 그럼 결국 이 '버전'을 관리하는 개념에 대해서도 당연히 알아볼 필요가 있겠죠? 프로그램 / 제품이 업그레이드 되거나 업데이트, 패치가 진행될 때 우리는 버전이 명시되는 것을 확인할 수 있습니다. 이 버전 코드나 숫자를 통해 해당 제품의 맥락과 시점을 파악할 수 있게 됩니다. 흔히 [1.0.0] 같은 형태로 버전을 표시하는 것을 많이 보았을 것입니다. 그럼 이 넘버링을 결정하는 기준은 무엇일까요? 사실 버전 명기에 있어서 절대적인 기준이 있는 것은 아니지만 - 대부분 암묵적으로 통용되는 기준은 있습니다.. [Chapter 3] repository 협업(7) - Pull Request 지금까지 병합 과정에서, 우리는 몇 가지 원칙을 만들어 운영한다고 했습니다. 애초에 마스터 브랜치에 직접 커밋을 진행하지 않고, 피처 브랜치를 만들어 병합하는 것 자체도 일종의 사고 방지를 위한 대원칙입니다. 다만, git의 기능 레벨에서 이러한 절차를 보강할 필요가 있겠죠? 피처 브랜치에서 마스터 브랜치로 병합하는 과정에서도, 협력자가 사전에 검토할 수 있도록 사전에 확인 과정을 거치는 기능이 바로 풀 리퀘스트(Pull Request)입니다. 우선 기존 실습 환경에서, 새로운 피처 브랜치를 하나 생성하고 커밋하는 과정에서 풀 리퀘스트를 사용하며 배워보도록 하겠습니다. 우선 기존까지 진행된 작업물의 상태에서 새로운 피처 브랜치를 생성해 보겠습니다. [feature/memo] 브랜치를 생성해서 새로운 커밋.. [Chapter 3] repository 협업(6) - 브랜치 병합하기 : 충돌(conflict) 지금까지 [feature/detail-page] 브랜치를 [master] 브랜치에 병합을 시도했고, 빨리감기(fast-forward) 병합이 실행된 상태입니다. 이제 마지막으로 [feature/popup] 브랜치에서 작업한 결과물을 병합하면 됩니다. 그런데, 이번에는 이전의 사례처럼 빨리 감기 병합이 아닌 일반 병합이 이뤄지기 때문에, 주의를 기울여야 합니다. 특히, 이번 병합에서는 '충돌'이 예정되어 있기 때문에(?) 이에 대한 처리도 함께 진행할 예정입니다. 차근차근 실습을 진행해 보겠습니다. 일단 이번 병합 과정에 있어서 앞서 진행한 빨리감기 병합과 가장 큰 차이점은, [master] 브랜치에 바로 병합을 진행하지 않는다는 점입니다. 오히려, 먼저 [master] 브랜치의 커밋을 [feature/p.. [Chapter 3] repository 협업(5) - 브랜치 병합하기 : fast-forward 앞서 우리는 병합(merge)의 몇 가지 유형에 대해서 살펴보았습니다. 이제부터 앞선 아티클에서 도식화하여 살펴본 merge 사례를 직접 소스트리에서 수행해 보도록 하겠습니다. 이번에 할 작업은 위의 케이스입니다. [master] 브랜치는 '커밋5' 상태를 가리키고 있고 피처 브랜치인 [feature/detail-page]는 '커밋7'을 가리키고 있는 상태입니다. 여기서 [master] 브랜치에 [feature/detail-page] 브랜치를 병합하는 작업을 수행하겠습니다. 어떤 브랜치가 기준이 되는지가 항상 중요하므로 잘 체크해야 합니다. 현재 소스트리의 상태는 아래와 같습니다. 1. 우선, 병합의 기준이 되는 브랜치로 체크아웃을 진행합니다. 여기서는 [master]가 되겠죠? [master] 브랜치로.. [Chapter 3] repository 협업(4) - 브랜치 병합하기 개념 이번 아티클에서는 지난 번 예제에서 [master], [feature/detail-page], [feature/popup] 브랜치로 각각 작업한 결과물을 합쳐서 관리하는 방식을 살펴보겠습니다. 우선 병합(merge) 방식과 원리해 대해서 먼저 살펴보겠습니다. 병합에는 다음과 같이 세 가지 케이스가 존재합니다. 1. 병합 커밋(Merge Commit) 병합 커밋은 위와 같은 경우를 뜻합니다. [모자를 쓴 남자], 그리고 [안경을 쓴 남자]가 각각 있습니다. 이 두 그림을 겹쳐서 합친다고 생각해보면 어떻게 될까요? '모자와 안경을 쓴' 남자가 새롭게 생겨납니다. 이렇게 새로 탄생한 '모자와 안경을 쓴 남자'라는 새로운 병합 커밋이 생성됩니다. 2. 빨리 감기(Fast-Forward) '빨리 감기'라니, 뜬금.. [Chapter 3] repository 협업(3) - 새로운 branch 추가 생성하기 이전 아티클까지 우리는 [master] 브랜치에서 파일 작업을 하다가, [master] 브랜치의 특정 시점을 기점으로 [feature/detail-page] 라는 새로운 브랜치를 생성했고 이 새로운 브랜치에서 두 번의 커밋을 진행했습니다. [Chapter 3] repository 협업(2) - branch 생성, commit in Sourcetree 지금부터는 우리가 배운 브랜치 개념을 소스트리에서 직접 적용해 실습을 진행해 보도록 하겠습니다. 우리는 git의 사용법을 알아보면서 ME와 John 두 사람이 파일 작업을 하는 상황을 가정하고 nozeroslope.tistory.com 이제, 새로운 브랜치를 [master] 브랜치의 시점에서 별개로 떨어져 나와서 생성하는 과정을 실제로 실습해 보도록 하겠습니.. 이전 1 2 3 4 다음
