일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- GIT
- 내 맘대로 정리한 안드로이드
- 코틀린
- Android
- 서브모듈 pull
- java
- submodule sourcetree
- 게임개발
- 개발
- 2d게임
- 앱
- 서브모듈 sourcetree
- 목서버
- Kotlin
- gitlab submodule
- Android Studio
- 앱개발
- 안드로이드
- firebase
- 안드로이이드 submodule
- 타이쿤
- github submodule
- 카페오냥
- 쿼터뷰
- DataBinding
- 유니티
- Unity
- 안드로이드개발
- github
- 티스토리
- Today
- Total
Uing? Uing!!
[Git 삽질기록] 'PR을 올리다'? Pull Request에 대해서 본문
서론
이전 글에서 언급했듯이 과제를 Fork하는 방법에 대해 고민하다가, 어찌어찌 Fork를 하고 작업을 시작했다.
BUT, git과의 전쟁은 여기서 끝이 아니었다. 나는 또 이런 말을 듣게 된다.
"작업한 내용은 PR 올려주시면 좋을 것 같아요."
?
그게 뭔데...
그거 어떻게 하는 건데...
PR... PT같은 건가? 발표? 아 뭐지? 뭘 어떻게 준비해야 되는 거지?
응 그거 아니야
PR이 무엇인지에 대해 물어보면 이 정도도 모른다고 안 좋게 보실까봐 잠깐 고민했으나,
git과 관련된 개념이라는 것조차 떠올리지 못했던 나는 구글에 검색할 키워드조차 알 수가 없었다.
결국 팀원분께 여쭈어 보아서 PR이 Pull Request라는 것을 알게 되었고,
이 Pull Request를 하는 구체적인 방법에 대해서는 구글링으로 또 해결했다.
본론
PR의 정의과 목적
다시, PR은 Pull Request의 약자이다.
git을 조금 사용해 본 사람이라면 Push와 Pull에 대한 개념은 어느 정도 알 것이라고 생각한다.
Push는 내가 작업한 것을 깃 서버에 올리는 것, Pull은 깃 서버에 업데이트되어 있는 내용을 받아오는 것.
따라서 Pull Request를 있는 그대로 풀어 말하면,
'서버에 업데이트되어 있는 내용을 받아와 주세요'라는 요청이다.
내 개인 서버에서 내 개인 로컬 컴퓨터로 받아오는 것이 목적이라면 누군가에게 요청할 필요 없이 그냥 pull을 하면 된다.
하지만, 원본 저장소의 내용을 Fork해서 내가 작업할 수 있는 장소로 가져온 뒤에 거기에서 작업을 하는 경우가 있다.
그리고 내가 작업한 내용을 원본 저장소에서 받아가서 적용해 주기를 원할 수가 있다.
이럴 때 쓰는 방법이 Pull Request이다.
정리해서 말하자면 PR이란 Pull Request의 약자이며,
남의 저장소의 내용을 내가 가져와서 업데이트한 뒤에
'이 부분 제가 이렇게 바꿨는데, 제가 작업한 부분도 적용해 주세요!'라는 요청을 보내는 것이다.
0. Pull Request를 하기 전에
우선 다른 저장소에서 내가 Fork를 무사히 해 온 상태라고 가정한다.
그리고 내가 내 저장소에서 뭔가 작업 내용을 업데이트했다고 가정한다.
그러면 이제 이 내용을 원본 저장소 관리자에게 Pull해 달라고 요청해야 한다.
어려울 것은 없다.
1. Fork해 둔 내 저장소에 들어간다.
뭔가를 수정해서 커밋&푸시한 후에 내 복사본 저장소에 들어가면 이런 문구가 뜬다.
'뭔가 작업한 내용이 있어 보이는데, 원본 저장소 쪽에 가져가라고 요청 보낼래?' 라는 거다.
2. Pull Request 버튼을 누르고, PR을 요청할 브랜치들을 선택한다.
1번에 첨부된 사진의 오른쪽에 보면 Pull Request라는 버튼이 있다.
이 버튼을 누르면 아래 같은 화면이 나타난다.
맨 위에 base repository <- head repository라고 되어 있는 부분은,
오른쪽에 있는 브랜치 -> 왼쪽에 있는 브랜치로 Pull 요청을 보낸다는 뜻이다.
지금은 둘 다 3.x 브랜치로 되어 있지만, 다른 브랜치로 요청을 보낼 수도 있다.
BUT, 전혀 다른 브랜치라면 적절한 PR이 아닐 확률이 높지 않을까 싶다.
그 밑에 Able to merge.라는 내용은 pull request가 받아들여질 때 크래시가 나지 않고 잘 적용될 것 같다는 뜻이다.
만약 여러 변화가 있었고 어떤 이유로든 깃이 그걸 무사히 merge하지 못할 정도라면 빨간색으로 cannot merge.라는 메시지가 뜬다.
하지만 cannot merge라고 하더라도, PR을 보내는 데에는 문제가 없다.
단지 request를 받아들인 쪽에서 크래시를 해결해야 한다는 정도의 불편함이 있겠다.
아래쪽 내용은 기존 원본 버전과 내가 수정한 버전에 어떤 차이들이 발생했고, 어떤 커밋들이 포함되었는가?를 보여 준다.
나 같은 경우에는 테스트를 위해서 아무 커밋이나 1개만 추가했다.
이 내용은 PR을 보냈을 때 전체적으로 공개된다.
3. Create Pull Request에서 필요한 코멘트를 작성한다.
초록색 버튼인 'Create Pull Request'를 눌러 준다. 그럼 이런 창이 뜬다.
내가 요청할 Pull Request에서 어떤 점이 변경되었는지,
왜 변경되었는지, 왜 이걸 받아들여야 좋은지 등등의 커멘트를 달 수 있다.
간략하게 다는 경우도 있고, 길게 다는 경우도 있는 것 같다.
4. Create Pull Request를 한 번 더 눌러 요청을 완료한다.
오른쪽 아래에 Create Pull Request 초록색 버튼이 또 있다.
내용을 다 작석했다면 이 버튼을 눌러 주면, 원본 저장소 관리자에게 요청이 보내진다.
5. 상대방의 답변 또는 merge를 기다린다.
내 PR를 상대방이 확인한 후에, 뭔가 궁금하거나 의아한 점이 있다면 커멘트를 달아 줄 것이다.
그리고 결과적으로 merge해도 괜찮겠다 싶으면 이 request를 받아들이고 본 브랜치로 merge하게 된다.
끝!
'Git' 카테고리의 다른 글
[Git] git submodule 한 번에 pull하기 (sourcetree에서 하는 방법 포함) (0) | 2024.11.07 |
---|---|
[Git] github actions로 README.md 자동생성하기 (0) | 2022.04.28 |
[Git 삽질기록] 'Fork 떠서 작업한다'는 게 뭐죠? (0) | 2020.10.01 |
[Git 삽질기록] Git push 이후에 작성자를 수정하고 싶을 때 (0) | 2020.09.10 |
[Git 삽질기록] 이미 Push한 커밋 메시지 수정하기 (0) | 2020.08.08 |