풀리퀘스트(22.07.11TIL)

센텀 코딩도장에서 혹독한 수련을 거쳐 자바 과제를 씹어먹겠다는 마음으로 메가테라 첫수업을 수강했다. 아니나 다를까 시련은 항상 예기치 못한 곳에서 닥쳐온다. 주말동안 빡세게 학습한 자바가 아닌 깃이 말썽을 일으켰다. 한달 전 사전과제에서 진행한 풀리퀘스트를 오늘 다시 사용하게 되었는데 낮선 사람앞에 선 것처럼 그대로 내 머리가 굳어버렸다. 깃도 특훈이 필요함을 느끼고 풀리퀘스트와 친해지기로 했다.

Master 브랜치

말그대로 마스터, 주인님이다. 주인님이니깐 좋은것만 가져야 겠지? 이름답게 마스터브랜치에는 완전한 코드들만 들이고 있다. 그럼 실험적인 작업은 어디에서 할까?

실험적인 내용들은 다른 브랜치를 만들어 실험해본 후 검증이 되면 마스터브랜치에 병합한다.

 

하지만 안타깝게도 협업할때는 말이 달라진다. 협업시에는 다른사람과 코드를 공유하기 때문에 더 까다로운 병합 절차가 필요하다!

풀리퀘스트?

진짜 전부터 나를 너무너무 괴롭히던 녀석이다. 사전과제 때부터 도대체 왜 이걸로 과제를 제출해야 하는지 계속 고민을 했었는데 Master브랜치를 공부하면서 깨달아버렸다. 

간단히 말하면 풀리퀘스트는 협업환경에서 병합을 위해 탄생한 검증절차다! 동료들에게 나 이거 Master브랜치에 병합하고 싶은데 허락해줄래?라고 물어보는 것이다.

그래서 그거 어떻게 하는건데?

말하자면 길지만 간단히 정리하면 아래 4단계로 이루어져 있다.

 

1. master에서 분기하는 브랜치 생성

병합을 검증받기위해 하니깐 병합을 할 실험용 브랜치가 있어야 겠지? 실험용 브랜치를 생성한다.

 

2. upstream브랜치 연결

그래서 실험용 브랜치를 리모트의 어떤 브랜치와 연결할건데? -> upstream브랜치에 연결해야지!

 

3. push

이제 원격저장소의 브랜치에 로컬 브랜치를 올리는 단계이다.

 

4. pull request 진행

실험용 브랜치를 가져와 봤는데 한번 괜찮은지 보실래요? 라고 물어보는 단계다. master브랜치에서 허락하면 병합될 수 있다 (PR될 수 있다.)

-> 과제 제출과정과 비교해보자.

1. master에서 분기하는 브랜치 생성

과제 리포지토리를 포크해서 fetch한뒤 git switch -c branchname 하는 게 분기하는 브랜치를 생성하는 내용이겠구나!

 

2. upstream 브랜치 연결

우리가 git switch -c branchname upstream/main 에서 main이 upstream브랜치 겠구나

 

3. push 

git push origin branchname(현재 작업중인 브랜치) : origin 리모트에 푸쉬를 진행한다.

근데 왜 branch는 upstream에 연결해놓고 origin에다가 push를 하는걸까? 이부분은 아직도 잘 모르겠다.

 

4. pull request 

이제 우리가 올린 과제물을 메가테라 과제물 칸에 제출하고 싶은데 한번 허락해주시겠어요? 단계이다. 깃허브 들어가서 풀 리퀘스트 진행하면 된다.

 

풀리퀘스트와 조금 친해졌지만 아직도 upstream remote는 정확히 어떤 역할을 하는지 잘 모르고, 왜 브랜치를 연결하는 remote와 푸쉬하는 remote가 다른지 잘 모르겠다. 다음 포스팅에서는 이 부분에 대해서 더 깊이 알아봐야겠다.