github.com - Pull request

===

https://opentutorials.org/module/5083

github.com - pull request

https://youtube.com/playlist?list=PLuHgQVnccGMBXv1OKe3Hn3Jq6F735-uWm 

Github.com - Pull request

 

===

pull request는 gitlab에서는 merge request라고도 불리는 기능입니다.

독립적으로 진행되던 브랜치의 작업을 다른 브랜치에 병합해달라고 요청하는 기능입니다.

 

대표적인 경우는 이렇습니다.

master 브랜치의 마지막 버전은 언제나 실행/배포 가능한 상태를 유지하기로 협의한 팀이 있습니다.

모든 작업은 별도의 브랜치를 만들어서 그곳에서 작업을 진행하기로 했습니다.

이런 브랜치를 토픽 브랜치, 기능(feature) 브랜치라고 합니다.

모든 작업이 끝나고 토픽 브랜치를 master로 병합할 때 다른 사람들의 검토를 받도록 하고 싶다면 어떻게 해야 할까요? 이때 사용할 수 있는 최고의 기능이 pull request입니다.

 

pull request를 이용하면 브랜치에서 만들어진 버전에 대해서 토론을 하면서 코드의 품질을 높이는 작업을 할 수 있습니다. 충분한 검토가 끝났을 때 github.com에서 병합 버튼을 누르면 자동으로 브랜치가 병합되게 됩니다.

다소 어려운 기능입니다만, 협업의 품질을 높이고 싶은 분들께 권해봅니다. 혼자 프로젝트를 진행하는 분에게는 필요하지 않은 기능입니다.

 

===

우리 수업의 목표는 코드 리뷰를 하는 핵심적인 도구인 pull request라는 github의 기능

merge request란 단어가 좀 더 와닿아

 

내가 일을 끝냈을 때 다른 사람들의 조언을 받고 싶어 이때 사용

 

===

왼쪽이 나.

E1, E2라는 버전을 EXP라는 브랜치하에서 만들었다, 원격저장소에 동기화가 돼 있다.

MASTER라는 브랜치에는 문제가 없는 코드만 병합한다는 원칙이 세워져 있다.

 

이떄 내가 pr버튼을 누르면, exp를 master로 병합하는걸 검토해주세요 라는 의미를 팀원들에게 표명하는 것

 

그럼 이제 사람들이 내가 작업한 버전들에 대해 토론을 하기 시작함

좋다 나쁘다 바꾸자..

 

이런 토론들을 거쳐서 문제가 없는 코드를 만들게 되면 merge 버튼을 누른다

이상태에서

새로운 버전이 만들어지면서

master로 EXP가 병합된다

 

그럼 이제 병합된 마스터가 다른 멤버들에게 배포

 

===

pr의 핵심 기능은 내가 작업한 코드를 다른 멤버들이 검토해서 코드의 품질을 높이고 master라고 하는 통합브랜치의 안전성을 높이는게 핵심

 

===

크게 두가지 형태의 pr이 존재

 

(1)원격저장소에 접근할 수 있는 직접적인 권한이 있는 경우의 pr

내가 작업한 브랜치를 다른 브랜치에 병합할 때 다른 사람들의 의견을 받고 싶을 때

 

(2)오픈소스방식에서 주로 사용하는 pr

왼쪽 위의 원격저장소에 대한 접근 권한이 없는것, 오픈소스라면 읽기는 가능하지만 쓰기는 불가능

->원격저장소를 복제(fork)

->그럼 이건 나한테 접근권한이 있다. 그 원격저장소에 push하고 브랜치를 만들고.. 개선시켜 나간다

->생각해보니 내가 수정한 내용이 왼쪽 위의 original에게도 유용한 것이다라고 생각이 되면 original저장소의 소유자나 권한이 있는 사람에게 내 원격 저장소의 내용을 가져가주세요(pull해주세요 요청)

 

===

2.실습환경

---

아시다시피 우리 SW세계에서 브랜치가 개발에, 동시작업의 중추역할을 한다

브랜치에 대한 전략, 정책들을 정리해놓는데

많은 조직들이 master브랜치는 언제나 실행가능해야하고, 언제 배포해도 문제가 없는 상태를 유지하는 요건을 충족시키는 목표를 갖는다. master브랜치에서 직접 작업하는것은 지양한다.

 

어떤 기능을 만들기 시작했거나 실험 작업을 할 때는 새로운 브랜치를 만들어서 브랜치에서 작업을 진행한다는것

->장점 : 버리기 쉽고, 그 기능과 관련된 작업들만을 모아서 보기가 쉽다 = 토픽 브랜치, 피쳐 브랜치

우리는 마스터브랜치와 별개의 새로운 기능을 추가하기 위해서 피쳐브랜치를 하나 만들겁니다

---

저장소를 만들고

저장소에 동료를 초대해, Write권한 줘

 

이 저장소를 내 지역저장소로 만들어(clone)

코드작성, 커밋

브랜치를 만들고, 그 브랜치로 체크아웃하고

수정 커밋

수정 커밋

수정 커밋

푸시

깃허브의 경우 푸시하면

이렇게 pr할 수 있는 주소를 보여줌

 

github가서 한번 봐보자

브랜치에 푸시했다면

깃허브에서는

브랜치를 만든사람한테 여러분이 만든 브랜치가 언젠가는 통합을 필요로할것이라는걸 알고 쉽게 pr실행시킬 수 있도록 

버튼을 자동으로 만들어줌

 

그냥 pr탭에서 해도 됨

 

===

3. pr만들기

내가 짠 코드에 문제가 없는지 검토해줘 + 병합할 권한이 있는 사람에게 병합해달라 요청

pr버튼 누르면

base로 compare라는 브랜치 병합을 요청합니다

 

어떤작업을 했고

어떤데 주안점을 두고 코드를 봤으면 좋겠는지 쓰고

 

Reviewers 이 코드에 대해 의견을 줬으면 하는 사람들을 등록할 수가 있다

Assignees 이 작업에 참여해서 일을할 사람을 지정

*draft : 임시

작업은 안끝났지만 코드리뷰 요청하는게 draft pr, 이거 쓰면 병합 안됨

그냥 pr은 작업끝났어요 확인하고 병합해주세요

 

하면 Reviewers, Assignees 권한이 있는 사람들에게 메일이 쫙 갑니다

Conversation : pr과 관련해서 일어난 여러 사건을 시간순으로 보여줌

Commits : 이 브랜치에서 일어난 Commit이 3개다

Files changed : 최종 워킹 디렉토리의 상태. 이 작업을 통해 브랜치에서 변경된 내용의 파일들만 보여줌.

->이런 정보들을 바탕으로 코드를 다른사람들과 토론, 검토하고

 

문제가 없다고 결론을 내리면 

이 버튼을 누르면

커밋메시지를 쓰고 저거 누르면 merge됨

이렇게 끝나면

pull전엔

git pull해서 보면(명령어는 그냥 git pull만)

기존에 master는 init

내가 지역 저장소에서 one two three 작업함

원격저장소(github)가서 pr로 merge했더니 master에서 master와 number-to-alphabet이라는 두개의 브랜치가 병합됐다

 

number-to-alphabet에서 pull한게 이거

master로 가면

아직 안 바뀌어 있어 다른브랜치에서 pull한건 그것만 pull되는가봐

 

pull하면?? 내용 바뀜

지역저장소도 병합된 상태가 되는 것

 

===

4.소통하기

방금 전 과정 중에서 Conversation부분

 

브랜치 새로 파고

수정 커밋

수정 커밋

push

 

pr탭가서 new

마스터로 뭐 병합할건지 선택하고

create버튼 누르면 됨

생성

 

다른 사람의 계정, 저장소에 권한이 있는, 으로 이 화면을 들어와볼게요

Conversation에서 어떤 pr이 들어왔는지 확인

Files changed로 어떤 작업을 했는지 보고

여기에 대해 의견을 다는 것

이렇게 두줄을 드래그 하고 놓으면

여기에 대한 코멘트를 달 수 있다

Add single comment : 바로 댓글 달림

Start a review : 리뷰를 할 때 의견을 군데군데 줘야 하는 경우가 있다, 그 커멘트들을 하나로 그루핑해서 한번에 의견 주는 것, 누르면 리뷰가 시작된다. 이때

저 버튼을 클릭하면 

이런 포맷이 생성됨. 8은 저 수정할 8과 같은것

이렇게 eight이라고 바꾸면 무슨뜻이냐? 기존에 8로 된걸 eight이라고 바꿔주세요 하고 코드를 추천한것. 입력하면

이렇게 뜸. 코드레벨에서 요청을 하게되는것

Start a review를 끝낼 땐

오른쪽 위에 Finish your review를 누르면 저런게 뜨는데, 내가 작성한 리뷰들의 취지에 대해 달면 된다

Comment : 의견

Approve : 동의

Request changes : 내용들을 수정해주세요 라고 좀 더 강조

셋다 강제력은 없다

 

이걸 등록하고

pr을 요청한 계정으로 가보면 방금 그 리뷰에 대한게 뜬다 거기에 대고 또 댓글을 달 수 있고

이렇게 개진을 해나간다 댓글을 달고 Resolve conversation을 누르면

이 이슈는 해결했다는 것. 화면에서 없어짐

그리고 아까 코드 추천한게 있는데

보면 Commit suggestion이 있다 누르고 Commit changes하면 커밋이 자동으로 된다!

이때 지역에서 pull 하면

반영(▽브랜치에 커밋이 늘어난거야)

 

그 다음 merge pull request -> (커밋메시지쓰고)Confirm merge 하면 병합이 시행됨

 

그 다음 지역에서 master로 간 후 pull하면 병합된 결과를 받게 된다

 

===

5.1. 충돌해결하기 - github 내의 편집기 이용하기

 

pr할 때 병합하려고 하는 브랜치간에 같은 코드를 수정했으면 conflict가 나게된다 어떻게 처리하는가

 

일부러 충돌만들기

브랜치 새로 파고 첫째줄 수정(git checkout -b number-to-alphabet-3

-> 커밋

-> 푸시(git push -u origin number-to-alphabet-3)

-> pr

처음에

이 화면이 떴다가 사라짐. 이게 우리의 브랜치가 마스터와 충돌이 나는가를 체크해보는 기능이다.

base가 master임

 

이때 마스터브랜치로 가서 첫째줄 쟤랑 다르게 수정(git checkout master)

-> 커밋

-> 푸시 git push

 

이때 방금 그 pr화면 아무것도 안드려도 또 체킹한다

그리고 위에 저걸 감지하고

충돌이 발생한다는걸 알려준다. 이땐 머지 못한다

이때 web editor를 쓸 수 있거나 / 직접 내가 병합(command line)할 수 있다

1.alphabetr-3는 1

2.master는 일

3.공통적인 부모에서는 다른 정보가 있었다.★

내가 이렇게 고치고 Mark as resolved 누르면

해결했다고 뜸. 파일이 여러개면 여러개에 대해 해야해

그리고 나서 저 Commit merge버튼 누르면 병합된 내용이 커밋이 된다.

 

그러면 새로운 버전이 생긴다

저 버전의 새로운 내용을 알고 싶어!

내 로컬에서 git checkout number-to-alphabet-3 하고 git pull 땡겨와볼 수 있다

 

그럼 이게 어떤 상황이야?? 우리의 현재 브랜치로 마스터의 변경사항을 병합한것. 과정에서 충돌이 생기는것을 처리해서 병합한 것

 

우리가 만든 토픽 브랜치에서 작업을 할 때, 계속해서 마스터 브랜치와 충돌이 나는지 체크해주는데 만약에 충돌이 나면 우리는 충돌 상태를 빨리 인지할 수 있기 때문에 마스터 브랜치의 내용을 토픽 브랜치로 계속해서 동기화해 나가면서 개발을 진행해 나갈 수가 있다. 아주 중요한 기능

 

===

▽

1.내가 토픽브랜치에서 작업을 계속 하고 있어
2.딴 애가 마스터에 pr확인받고 병합해
3.그럼 내가 마스터와 내 브랜치를 계속 동기화해가면서 작업하고싶어
->이때 내꺼 pr로 일단 올려보고 저 방법으로 해결해 라는 설명

내꺼 pr로 올리고 마스터랑 병합한 커밋 하나 새로 생성해서 그걸 내 로컬로 pull받고 작업 진행해나가라고

 

근데 이건 그냥 
내 마스터에 pull받고 
내 마스터를 내 브랜치로 병합하는거잖아

 

뭐가 다른거지

 

===

그렇게 해서 내가 충돌을 다 해결한 다음엔

병합을 할 수 있는 상태가 되는 것

아까의 충돌로 커밋을 만든건 마스터를 토픽 브랜치로 가져온것이었다. 그렇게 해결하면서 토픽브랜치를 개선시킨것.

그 개선이 모두 끝나면 그걸 마스터로 병합하는걸 마지막에 한것

 

============

5.2. 충돌해결하기 - git으로 충돌 해결하기

이전 건 깃허브가 갖고 있는 에디터였다. 이건 좀 제약이 많다

 

내 컴퓨터에서 깃을 이용해서, 충돌났을 때 머지를 도와주는 도구들을 이용해서 여러분들이 충돌을 해결하면 좋겠죠

 

방금처럼 충돌을 일부러 발생해보기

master에서 원격master랑 다르게 작성 후 커밋

->이 마스터를 기반으로 브랜치를 파고, 첫 줄 수정 후 커밋 후 푸시

->원격저장소로가서 pr신청

->master로 가서 브랜치와 같은부분 다르게 수정 후 커밋 -> 푸시

 

아까랑 똑같아 마스터에서 브랜치를 파고 둘다 같은곳 수정한 후 둘다 푸시한것

그럼 pr에서 충돌발생

command line : 직접 충돌 해결

누르면 설명나옴

충돌이 발생하면 바로 해결해야한다. 바로 해결 안하면 나중에 충돌이 점점 많아지고 해결하기 대단히 까다로워진다

 

그렇기 때문에 깃에서는 mater쪽에서 충돌난걸 브랜치쪽으로 병합을 시도해서 충돌을 해결하면서 개발계속해나가주십쇼 라는 의미에서

이 방법을 알려준것.

 

*get fetch origin : 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%B8%8C%EB%9E%9C%EC%B9%98

 : 로컬과 서버의 커밋 히스토리는 독립적임 리모트 서버로부터 저장소 정보를 동기화하려면 git fetch origin 명령을 사용한다. 명령을 실행하면 우선 “origin” 서버의 주소 정보(이 예에서는 git.ourcompany.com)를 찾아서, 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.

 

깔끔한 저장소에서 origin데이터를 가져오고

브랜치를 만들고

그 브랜치로 마스터의 변경사항을 가져와서 충돌나는 부분을 해결해서 사용하세요

▽누가 브랜치가 다르면 merge해야된다는게 이건가보네

라는 세줄. 결국 충돌난 마스터를 number-to-alphabet으로 가져오는것

 

결국 충돌을 해결하라는 말임

그 다음

master로 체크아웃

브랜치를 마스터로 merge해라 -> 병합을 끝내게되면 우리가 오픈한 pr은 자동으로 닫히게 된다

결국 코드가 문제가 없다는 것을 확인하고, number-to-alphabet-4를 master로 병합하는것 그리고 pr를 닫는다

 

===

더 많은 충돌이 생겨나기 전에 브랜치로 마스터를 병합하는 것

 

위의 명령어랑 다른 이유는 이미 fetch 안해도 되는게 내 저장소랑 원격이랑 동기화가 된 상태이고 어쩌고..

이렇게 뜬다.

내 헤드는 number-to-alphabet-4 : one

master에서는 : 일

해결하고 add하고 commit

병합했다는 커밋메시지 생성

그리고 이걸 푸시하면??

이게 돌아가면서

해결이 남

 

여기서 merge버튼 클릭해도 되지만

이렇게 병합하는 것도 방법이다.

이상태에서 병합을 누르면 마스터는 number-to-alphabet-4이후로 특별히 작업한게 없으므로 마스터가 저기로 이동을 하면 되기 때문에 새로운 머지 커밋을 만들 필요가 없다 = 이런걸 fast forward라고 한다

아까 깃허브가 알려줬던 것중에 --no-ff 라는 옵션을 달았는데

그럼 ff든 ff가 아니든 간에 무조건 머지커밋을 새로 만들게 된다. 그걸 권장하는 것 같아요 깊은 뜻은 제가 잘 모르겠어요

머지하면 커밋이 자동으로 생성되는데

이러면 아까는 마스터가 '일' 이었는데

아래 두개를 조상으로하는 머지커밋이 만들어진것

 

그리고 이것을 git push 를 master로 하게되면

 

깃허브가 master로 number-to-alphabet-4가 병합됐다는 사실을 자동으로 체크해서 우리의 pr을 자동으로 닫아주게 된다

이게 자동으로

이렇게 된다

 

pr은 복잡하지만

코드리뷰라는게 워낙에 중요한 경우엔 이런 복잡성을 충분히 끌어안을 가치가 있기 때문에!

 

===

병합을 할 때 다른 방법도 있다

Merge는 E2와 M2를 비교해서 새로운 머지커밋을 만든다

마스터가 걔를 가리키면 병합이 끝난다

 

===

Merge는 진실이다. 이런식으로 일이 일어난다는 팩트를 보여준다

 

Squash and merge와 Rebase and merge는(사실은 둘다 rebase라고 저는 생각하는데)

조작한다. 목적은 보기 편하라고

E1과 E2에서 작업한 변경사항들을 합쳐서 하나의 버전으로 만든다

그리고 그렇게 만들어진 버전과 master에서 만든 버전을 병합해서 새로운 버전을 만들어낸다

그리고 master가 걔를 가리킨다

EXP에서 커밋을 수백개 수천개 해도 과정은 필요없을 수 있기 때문에 하나로 퉁쳐서 병합

 

===

E1, E2가 master와는 별도로 작업이 됐는데, 브랜치가 많아지면 병렬작업이 너무 많아져서 우리 프로젝트의 히스토리를 읽기가 너무 힘들어 사람은 한줄로 돼 있는 역사가 편하다 동시에 여러가지 일들이 진행된건 해석하기가 어려워

 

그래서 E1과 M2의 변경사항을 병합한다

그 다음 E2와 ME1의 내용을 비교해서 또 새로운 버전을 만든다

마치 M1, M2가 끝난다음에 ME1, ME2작업이 끝난 것 같은 히스토리를 보여준다

역사를 일직선으로 만들었다

 

===

둘다 조작인데

스쿼시는 하나로 퉁치고

리베이스는 각각의 버전들을 살려두는 것, 일직선으로 만든다

 

나중에 프로젝트 읽기 편하게 하는 것

프로젝트에 따라 이런 방식을 강제하거나 요구할 수 있다

 

===

또, 두가지 형태의 pr타입이 있는데,

첫번째는 private repository타입 : 그냥 내가 권한이 있는 방식, 우리수업

두번째는 public repository타입 : 오픈소스 방식, 다른 사람의 프로젝트를 fork해서 개선사항을 original에게 주고 싶을 때 pr을 쓰기 때문에 살펴보시면 좋겠습니다