앞의 포스트에서 github의 코드를 Clone 명령으로 내려받고 vscode에서 편집하는 단계까지의 과정을 설명했다. (보러가기)
이제 VSCode와 같은 git을 지원하는 개발도구에서 코드를 수정한 다음 로컬PC의 Git 리포지토리에 Commit 하고 로컬PC에서 테스트한 다음 Clone한 Github에 Push 하는 과정을 설명한다. 이해를 돕기 위해 PC에 설치된 Git과 Github의 리포지토리, 브랜치의 관계를 구성도로 그려 설명한다.
Git과 Github의 리포지토리, 브랜치 구성 및 관계도
Git과 Github, 리포지토리와 브랜치 그리고 관련 작업 용어는 그림으로 이해하는 것이 빠르다.
위의 그림에는 PC에 설치된 git과 github가 왼쪽과 오른족에 표시되어 있다. 그리고 github에 tistory-wp 라는 소스코드 저장소인 Repository(리포지토리)가 있다. Github의 소스코드가 저장된 리포지토리를 Git이 설치된 PC의 특정 폴더에 내려받으면(Clone) 폴더명으로 리포지토리가 만들어진다. 위 그림에서는 동일한 이름인 tistory-wp라는 이름으로 내려받은 경우를 표현하고 있다. PC에 설치된 Git의 입장에서 Github의 tistory-wp 리포지토리는 Remote 리포지토리다.
Repository와 Branch
리포지토리에는 소스코드가 저장된 최소 1개의 브랜치가 존재하는데 일반적으로 Github에서는 리포지토리를 생성하면 main 이라는 브랜치를 기본적으로 생성한다. 그리고 이 main 브랜치는 최종적으로 운영시스템에 배포되는 테스트를 모두 마친 완성된 코드가 저장되는 브랜치로 사용하는 것이 일반적이다.
만약 개발자가 코드를 수정하려면 main 브랜치에서 직접 수정하는 것은 권장되지 않는다. 앞의 포스트에서 설명한 과정에 따라 Github의 tistory-wp 리포지토리를 로컬PC의 Git 리포지토리로 Clone 하여 로컬에 내려받은 다음 수정하거나 Github의 main 브랜치를 복사하여 새로운 이름의 브랜치를 생성한 다음 해당 브랜치의 코드를 수정하고 테스트하는 것을 권장한다. 물론 이런 작업은 PC에 설치한 Git에서도 모두 수행할 수 있다.
로컬 Git의 리포지토리로 내려받으면(Clone) 폴더명이 리포지토리명 이름이 되고 기본 브랜치는 master 라고 만들어진다. 이름이 헷갈릴 수 있으므로 tistory-wp-dev 라고 변경해준다. 다음 화면이 바로 그 화면이다.
위 화면에서 Current Branch에 표시된 이름이 브랜치 이름이다. 물론 로컬 Git의 리포지토리에서 브랜치를 기반으로 새로운 브랜치를 만들 수도 있다. 새로 생성한 브랜치에는 기본 브랜치의 모든 소스코드가 포함되어 있으며 소스코드를 수정한 다음 Commit할 때 위에 표시된 현재 브랜치에 저장하게 된다.
vscode와 같은 개발도구에서 git을 연동해 작업하다 Commit 하기 위한 화면으로 전환하면 현재 브랜치를 아래화면과 같이 보여준다.
현재 수정하는 코드는 tistory-wp 리포지토리의 tistory-wp-dev 브랜치임을 알 수 있다.
Push와 Pull
이제 코드를 수정한 다음 Github의 tistory-wp 리포지토리에 반영해야 하는데 곧바로 tistory-wp 리포지토리의 기본 브랜치에 적용하는 것은 권장되지 않는다. 앞의 포스트에서 Github의 tistory-wp 리포지토리를 GitGui에서 복제하여 내려받고 로컬의 tistory-wp 리포지토리 내부의 기본 브랜치 이름을 tistory-wp-dev로 변경했다.
이 브랜치에서 코드를 수정하거나 로컬 Git에도 새로운 브랜치를 만들어 새로 만든 브랜치에서 코드를 수정하고 테스트한 다음 기본 브랜치에 머지(Merge)하고 로컬 Git의 기본 브랜치를 Github에 Push할 수도 있다. 이렇게 로컬 Git의 리포지토리에서 리모트 Git(여기서는 github)의 리포지토리에 업로드하는 것을 Push라고 한다. 이런 리포지토리와 브랜치의 운영 전략은 개발조직에서 명확하게 명문화하여 운영하는 것이 바람직하다.
Push할 때는 리모트(여기서는 github)에 있는 어느 리포지토리의 어느 브랜치에 Push할지 지정할 수 있는데 Push는 단순히 로컬 브랜치를 그대로 리모트에 수정(단순 Update) 하는 것이기 때문에 누군가가 먼저 리모트의 브랜치에 Commit하여 내가 내려받을 때와 내용이 달라져 있다면 리모트에 Commit한 내용이 사라지는 등의 충돌이 발생해 문제가 될 수 있으므로 내가 Clone한 이후 반영된 리모트 브랜치의 Commit된 내용을 내 로컬에 Pull하여 적용한 다음 Push해야 한다. (위 그림 동그라미 2와 동그라미 3)
만약 리모트에 내가 Push하고자 하는 동일한 이름의 브랜치가 없다면 내 브랜치 이름으로 새로운 브랜치가 생성된다. 이후에 내가 Push하여 리모트에 생성된 브랜치와 리모트의 main 브랜치를 머지(Merge : 병합)해야 한다.
로컬PC에서 코드를 수정한 다음 로컬 리포지토리의 브랜치에 다음과 같이 Commit 한다.
왼쪽의 소스콘트롤 메뉴에 가면 변경된 내용을 자동으로 인식하여 코멘트를 달아 Commit 할 수 있게 보여준다. Commit을 하면 자동으로 다음과 같이 “Sync Change 숫자”라는 버튼이 표시되는 화면을 볼 수 있다.
이 때 Sync Change는 이미 연결되어 있는 Remote의 tistory-wp-dev 브랜치에 Pull과 Push를 차례대로 수행하는 것을 의미한다. 즉 Push할 리모트의 브랜치에 다른 개발자가 변경한 것이 있는지를 확인하고 충돌이 발생하는지 검토할 수 있게 해준다. 만약 충돌이 없는 것이 자동으로 확인되거나 변경사항이 없다면 Push를 수행해 로컬에서의 변경사항을 리모트에 업데이트 한다.
만약 Remote(리모트)가 등록되어 있지 않다면 GitGui 또는 VSCode의 다음 화면에서 Github의 리포지토리 주소를 리모트 리포지토리로 등록해주어야 한다.
만약 Github의 리포지토리가 Private Repository라면 인증정보를 등록해야 할 수 있다. 인증정보를 등록하는 것은 앞의 포스트에서 확인할 수 있다. 이후에는 Sync Change 버튼을 누르면 Pull과 Push가 차례대로 실행되면서 로컬PC의 리포지토리에서 수정한 브랜치를 Github의 리포지토리에 반영할 수 있다.
Merge
Merge는 브랜치와 브랜치를 병합하는 것을 의미한다. 일반적으로 최신의 코드가 담겨져 있는 main 브랜치를 Clone하거나 새로운 브랜치를 만들어 코드를 수정하고 테스트한 다음 운영시스템에 배포하기 전에 main 브랜치에 병합하는 것을 의미한다. 위의 그림에서 Merge(머지)는 동그라미 4다.
로컬PC의 리포지토리에서 수정한 브랜치를 Github의 리포지토리에 Push하면 다음과 같이 Pull Request를 생성할 수 있음을 알려준다. Pull Request는 리포지토리의 관리자에게 main 브랜치에 다른 브랜치의 수정 사항을 병합(Merge)해 달라는 요청이라고 보면 된다. 즉 Pull 해달라는 Request다.
화면에 Compare & pull request 라고 써있는 초록색 버튼이 활성화 된다. main 브랜치에 Merge할 수 있는 Pull Request를 생성할 수 있음을 알 수 있다. 이 버튼을 누르면 설명을 추가해 pull request를 생성할 수 있는 화면이 표시된다.
Create pull request 버튼을 누르면 pull request의 요청 내용을 볼 수 있고 아래쪽에 Merge pull request 버튼이 보인다. 이 버튼을 누르면 tistory-wp-dev 브랜치의 수정 내용을 main 브랜치에 병합(Merge)할 수 있다.
Merge pull request를 누르면 드디어 Confirm Merge 버튼이 보인다.
Confirm Merge 버튼을 누르면 main 브랜치에 병합이 완료된다.
#pull #push #pull_request #merge #github
답글 남기기