Branch

브랜치 생성 및 관리방법과 PR방법등에 대해 기술한 페이지

이쯤되면 형상관리에서 배웠던 Working Directory, StaingArea, Local Repository에 대해선 다 까먹었을 것이다. 잠시 가서 보고오도록하자. 형상관리(git)
당연히 나중 가면 또 까먹을 테니 별도의 탭에 형상관리파일을 띄워두면서 commit 명령어가 뭘 하는거고 push 명령어가 뭘 하는 녀석인지 중간 중간 체크하도록 하자.

GUI 방식 명령어들

git이라는 형상관리 도구는 본래 터미널에서 작동하기 때문에 CLI방식으로 명령어를 작성해줘야 한다.
단 그렇게 어렵다면 사람들이 잘 쓰지 않기 때문에 SourceTree는 이를 보기 쉽게 GUI방식으로 구현을 했고 위 버튼들을 통해 commit, pull, push, fetch, checkout, merge 등이 가능하다.
각 명령어들에 대한 설명과 branch에 대한 설명은 형상관리(git)을 통해 확인하자

main 브랜치의 내용을 가져왔으면 main브랜치에서 작업하는 것이 아니라 본인의 작업용 브랜치를 생성하고 생성된 브랜치 안에서 코드를 수정해야한다. 따라서 로컬 저장소내에 브랜치를 추가 하도록하자

새 브랜치에 작업용 브랜치명을 입력하고 새 브랜치 체크아웃 선택후 브랜치 생성을 누르면 main브랜치의 내용을 바탕으로 새 브랜치를 생성해 주면서 해당 브랜치로 이동 된다.
위 실행방식을 순수 CLI로 작성한다면 다음과 같다(궁금하다면 오른쪽 터미널 클릭후 터미널에 입력해보자) git checkout -b mkm
checkout은 현재 작업중인 branch를 변경하는 명령어이다.

push는 Local Repository의 변경사항을 Remote Repository로 반영하는 역할을 한다. 위에서 main은 체크해제 한후 mkm브랜치만 push하도록하자

push후 위와같은 팝업이 뜰건데 안뜨게 하는방법은 직접 검색해서 알아보고 일단 no helper로 Select 해주도록 한다.https://lwk24.tistory.com/753

그러면 다음으로 깃허브 아이디와 비밀번호를 입력해야 한다. 여기서 비밀번호는 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를 작성하기위한 창이 열린다.

커밋 완료시 push버튼에 변경사항이 있다고 알려준다. 좌측 브랜치를 보면 어떤 브랜치의 변경사항인지 알수 있다.

이제 수정사항을 반영할 준비를 마쳤다. push를 통해 수정사항을 원격 레파지토리에 반영을 시켜주자. (브랜치 push와 동일한 방법으로)

push 완료시 아래와 같이 mkm브랜치의 브랜치 그래프가 바뀐걸 확인해볼 수 있다.

원격 레파지토리에 접속후 mkm브랜치로 이동하면 다음과같이 수정사항이 반영되어 있다.

단 위 수정사항은 mkm브랜치에만 적용된 부분으로 main브랜치에는 현재 수정사항이 반영되지 않은 상태이다. mkm브랜치의 수정사항을 main에 합치기 위해서는compare & pull request버튼을 클릭하여 병합 요청을 넣어야 한다.

원격 레파지토리의 main 브랜치와, Soure Tree상의 main브랜치로 이동하여 수정사항이 반영되었나 체크해보면 반영이 안되어 있을 것이다.
로컬 레파지토리에 실제로 들어가보면 main 브랜치와 mkm 브랜치 각 각 더블클릭(checkout) 했을 때 디렉토리내부의 파일이 바뀌는걸 확인 할 수 있다. (로컬 레파지토리의 각 브랜치별로 변경사항을 따로 관리하기 때문)

브랜치 push시 PR버튼이 활성화된다. 클릭하자.

클릭후 이동하면 아래와 같은 화면이 나온다

요청을 넣으면 PR에 대한 리뷰를 하는 페이지로 이동한다.

프로젝트에 참여하는 인원들은 PR메세지, Commits내용, 바뀐 코드를 확인한 후 적절한 코멘트를 남긴다.

프로젝트 관리자(레파지토리 소유자)는 코멘트를 확인한후 Merge pull request를 통해 mkm브랜치의 수정사항을 main에 병합한다. 최종확인버튼 한번더 나오는데 문제없다면그대로 Merge 하면 된다.

병합 완료시 아래와 같이 main브랜치에 파일이 추가된다

위 실습에서는 mkm브랜치로 만들었지만, GitHub Flow와 같은 브랜치 전략에서는 만들어야하는 기능별로 branch를 생성해야 하는데, 작업 완료한 branch를 삭제하지 않고 놔두게 되면 수 백개의 브랜치가 생겨나게 된다.
따라서, 사용완료된 사용하지 않는 브랜치는 삭제시켜 주어야한다.
CLI방식이나 GUI방식으로 BRANCH를 각각 삭제할 수 있으며, 매번 브랜치를 삭제하는 작업이 번거롭다면 settings의 다음 옵션을 체크해두면 머지하는 즉시 feature브랜치가 삭제된다.

원격 저장소의 수정사항과 현재 머지하려는 작업파일의 내용이 겹치는 경우 충돌이 발생하는 경우가 존재할 수 있다.

해결방법은 Resolve confilicts를눌러서에러가 발생하는 소스코드를 직접 수정하는 간단한 방법이 있다

Last updated 7 days ago