Branch
브랜치 생성 및 관리방법과 PR방법등에 대해 기술한 페이지
Last updated
브랜치 생성 및 관리방법과 PR방법등에 대해 기술한 페이지
Last updated
이쯤되면 형상관리에서 배웠던 Working Directory, StaingArea, Local Repository에 대해선 다 까먹었을 것이다. 잠시 가서 보고오도록하자.
당연히 나중 가면 또 까먹을 테니 별도의 탭에 형상관리파일을 띄워두면서 commit 명령어가 뭘 하는거고 push 명령어가 뭘 하는 녀석인지 중간 중간 체크하도록 하자.
git이라는 형상관리 도구는 본래 터미널에서 작동하기 때문에 CLI방식으로 명령어를 작성해줘야 한다.
단 그렇게 어렵다면 사람들이 잘 쓰지 않기 때문에 SourceTree는 이를 보기 쉽게 GUI방식으로 구현을 했고 위 버튼들을 통해 commit, pull, push, fetch, checkout, merge 등이 가능하다.
main 브랜치의 내용을 가져왔으면 main브랜치에서 작업하는 것이 아니라 본인의 작업용 브랜치를 생성하고 생성된 브랜치 안에서 코드를 수정해야한다. 따라서 로컬 저장소내에 브랜치를 추가 하도록하자
새 브랜치에 작업용 브랜치명을 입력하고 새 브랜치 체크아웃 선택후 브랜치 생성을 누르면 main브랜치의 내용을 바탕으로 새 브랜치를 생성해 주면서 해당 브랜치로 이동 된다.
위 실행방식을 순수 CLI로 작성한다면 다음과 같다(궁금하다면 오른쪽 터미널 클릭후 터미널에 입력해보자) git checkout -b mkm
checkout은 현재 작업중인 branch를 변경하는 명령어이다.
브랜치 이동된 모습 좌측 브랜치를 더블클릭하여 브랜치 이동(check out)도 가능하다.
현재 생성된 브랜치는 원격 저장소에는 존재하지 않는 branch이다. 해당 브랜치를 원격 레파지토리에 그대로 추가하여 사용하도록 하자.
push는 Local Repository의 변경사항을 Remote Repository로 반영하는 역할을 한다. 위에서 main은 체크해제 한후 mkm브랜치만 push하도록하자
그러면 다음으로 깃허브 아이디와 비밀번호를 입력해야 한다. 여기서 비밀번호는 github 비밀번호가 아니라 PAT(Personal Access Token)를 입력해야한다.
만약 일반 비밀번호를 입력했다면 C:\Users\user1\AppData\Local\Atlassian\SourceTree
경로로 이동하여 passwd 파일을 삭제한 후 다시 진행하자
PAT을 잘 입력했다면 위에 귀찮게 하는 녀석이 또 나올 건데 가뿐히 무시해주자.
push 성공 후 github로 넘어가서 브랜치가 잘 push되었는지 체크해보자.
이제 mkm 로컬 레파지토리에서 작업을 한 후 mkm 원격 레파지토리로 수정내용을 push하면서 형상관리 할 수 있다.
mkm 브랜치에 간단한 파일을 하나 생성해보자.
추가된 파일을 Staging Area에 올리고자 한다면 +버튼을 누른다.
Staging Area에 commit 하고자 하는 변경사항들을 모아 둔후 커밋(+)버튼을 클릭한다
버튼 클릭시 하단에 commit message를 작성하기위한 창이 열린다.
간단하고 명확하게 커밋의 목적을 작성한다. ex) 회원서비스 버그 수정, 회원서비스 댓글기능 추가, 리팩토링 등등..
커밋 완료시 push버튼에 변경사항이 있다고 알려준다. 좌측 브랜치를 보면 어떤 브랜치의 변경사항인지 알수 있다.
이제 수정사항을 반영할 준비를 마쳤다. push를 통해 수정사항을 원격 레파지토리에 반영을 시켜주자. (브랜치 push와 동일한 방법으로)
push 완료시 아래와 같이 mkm브랜치의 브랜치 그래프가 바뀐걸 확인해볼 수 있다.
mkm -> origin/mkm : 로컬 mkm브랜치의 내용을 원격레파지토리들중 origin의 mkm 브랜치에 반영했다는 의미
원격 레파지토리에 접속후 mkm브랜치로 이동하면 다음과같이 수정사항이 반영되어 있다.
단 위 수정사항은 mkm브랜치에만 적용된 부분으로 main브랜치에는 현재 수정사항이 반영되지 않은 상태이다. mkm브랜치의 수정사항을 main에 합치기 위해서는compare & pull request버튼을 클릭하여 병합 요청을 넣어야 한다.
원격 레파지토리의 main 브랜치와, Soure Tree상의 main브랜치로 이동하여 수정사항이 반영되었나 체크해보면 반영이 안되어 있을 것이다.
로컬 레파지토리에 실제로 들어가보면 main 브랜치와 mkm 브랜치 각 각 더블클릭(checkout) 했을 때 디렉토리내부의 파일이 바뀌는걸 확인 할 수 있다. (로컬 레파지토리의 각 브랜치별로 변경사항을 따로 관리하기 때문)
브랜치 push시 PR버튼이 활성화된다. 클릭하자.
클릭후 이동하면 아래와 같은 화면이 나온다
main <- mkm : mkm브랜치의 내용을 main브랜치에 병합 요청하겠다는 의미. PR전에 잘 체크해보도록 하자.
병합요청시 변경사항에 대한 제목과 내용을 간단하게 추가한후 Create pull request 버튼 클릭
요청을 넣으면 PR에 대한 리뷰를 하는 페이지로 이동한다.
프로젝트에 참여하는 인원들은 PR메세지, Commits내용, 바뀐 코드를 확인한 후 적절한 코멘트를 남긴다.
프로젝트 관리자(레파지토리 소유자)는 코멘트를 확인한후 Merge pull request를 통해 mkm브랜치의 수정사항을 main에 병합한다. 최종확인버튼 한번더 나오는데 문제없다면그대로 Merge 하면 된다.
병합 완료시 아래와 같이 main브랜치에 파일이 추가된다
원격 저장소의 수정사항과 현재 머지하려는 작업파일의 내용이 겹치는 경우 충돌이 발생하는데 해결방법은 원격 저장소의 내용을 pull로 내려받은 후 충돌이 발생한 소스코드를 하나하나 수정하여 다시 한번 push를 진행하면 된다. 순서를 기술해보자면 아래와 같다.
현재 StaingArea에 존재하는 모든 작업내용을 commit한다.
원격저장소에서 pull작업을 통해 변경사항을 내려받는다.
충돌 발생지점을 찾아 소스코드를 하나하나 수정한다.
작업 완료후 commit과 재 push를 진행한다.
각 명령어들에 대한 설명과 branch에 대한 설명은 을 통해 확인하자
push후 위와같은 팝업이 뜰건데 안뜨게 하는방법은 직접 검색해서 알아보고 일단 no helper로 Select 해주도록 한다.
