기타/git

[git] 깃허브 협업 시 Pull Request 활용 방법 총정리

kyxxn 2023. 11. 18. 17:17
728x90

개요

  • 지난 앱 프로그래밍 팀 프로젝트에서 깃을 공부하지 않고, '한 사람 작업이 끝나면 압축 -> 메일 전송'과 같은 바보 같은 방식을 사용하여 이번 프로젝트를 진행할 때는 그러지 않기로 위 내용을 공부하여 정리한다.

Pull Request 사용 단계

  1. 원본 저장소에서 브랜치 생성
  2. 1단계에서 생성한 브랜치를 내 원격 저장소로 Fork
  3. 내 원격 저장소 Clone
  4. 원본 저장소 Remote 설정
  5. 내 원격 저장소 브랜치 생성
  6. 5단계에서 생성한 브랜치에 add, commit, push
  7. 원본 저장소에 대한 Pull Request 생성
  8. 원본 저장소 관리자에 의해 Merge Pull Request
  9. 원본 저장소의 Merge 동작을 마치면 내 원격 저장소의 main과 동기화 후 branch 삭제

원본 저장소에서 브랜치 생성 후 내 원격 저장소로 Fork


원본 저장소에 dev라는 브랜치를 먼저 생성하였다.
이후, Fork를 눌러 내 원본 저장소로 가져왔다.

 

| Fork : 다른 사람의 원격 저장소를 내 원격 저장소로 복사
| Clone : 원격 저장소를 로컬 저장소로 복사

내 원격 저장소 Clone

KyxxnMacAir:강김2 kyxxn$ git clone https://github.com/Kyxxn/Front_webservice.git

내 원격 저장소의 링크를 복사하여 CLI 환경에서 Clone 하였다.

원본 저장소 Remote 설정


클론을 하면 자동으로 remote가 내 원격 저장소로 설정이 되어 있다.
내 원격저장소 뿐만 아니라 포크 해온 원본 저장소도 remote를 추가시켜주어 원본 저장소의 내용과 동기화할 때 사용한다.


원본 저장소의 링크를 가져와 remote를 추가해주었다.

내 원격 저장소 브랜치 생성


클론해온 내 원격 저장소에는 main 브랜치가 있다.


내 원격 저장소 또한, 다른 사람과 협업하여 쓸 수 있기에 개발 브랜치를 분기하여 분기한 브랜치에 반영하고, main에 업데이트 해주는 식으로 한다.
개발 브랜치에서 문제가 발생해도 main의 브랜치를 가져오면 다시 작업할 수 있기 때문이다.

$ git branch // 브랜치 리스트
$ git branch <브랜치 이름> // 브랜치 생성
$ git checkout <브랜치 이름> // 브랜치 이동

$ git checkout -b <브랜치 이름> // 브랜치 생성 + 이동

개발 후 Add, Commit, Push

$ git add *
$ git commit -m "First init"
$ git push origin develop

push 명령어를 보면 origin은 Remote 설정에서 보았던 내 원격 저장소이고,
develop은 내 원격 저장소의 개발용 브랜치이다.

원본 저장소에 대한 Pull Request 생성


포크한 내 원격 저장소의 내용을 Push 하면 "Compare & pull request" 메세지가 뜬다.

만약 위 이미지가 안 뜨면 내 원격 저장소에서 다음과 같이 진행한다.

 


위와 같이 변경 기록을 보여주고, Create pull request 버튼이 활성화 된다.

Open a pull request 창에서 브랜치에서 어떤 기능을 어떻게 수정했는지 자세히 작성하여 Create pull request를 누른다.


그럼 위 사진과 같이 PR에 대한 결과가 뜨고, 정상적으로 Open 되어 있음을 알려준다.
원본 저장소 깃허브 관리자는 PR 내용을 보고 Merge할 지 말지 정한다.

원본 저장소 관리자에 의해 Merge Pull Request (관리자 기준)

현재 나는 Pull Request를 Merge할 수 있게 되어있다. 엄밀히 말하면, 이 글을 작성하는 도중 권한을 얻었다.
권한이 있는 관리자는 원본 저장소에서 Pull Request를 확인하여 Merge할 지 말 지 정할 수 있다.


내 원격 저장소에서 add, commit, push하고 Pull Request를 보낸 내역이다.
관리자는 위 빨간 네모를 클릭하여 Pull Request 내역을 상세히 볼 수 있다.


위 단계에서 했던 화면과 유사하다.
아래에 Merge pull request 버튼이 활성화 됨


Merge pull request 버튼을 누르면, 위와 같이 바뀌고 Confirm merge를 누르면 최종적으로 Pull Request를 반영한다.
추가로 관리자는 아래의 Add a Comment를 통해 Pull Request에 대한 코멘트를 작성할 수 있다.


최종적으로 반영이 된 모습

원본 저장소의 Merge 동작을 마치면 동기화 후 branch 삭제

원본 저장소에 Merge가 위 동작들을 통해 최종적으로 완료되었다.
이제 내 로컬 저장소 코드와 원본 저장소의 코드를 동기화 하고, 사용하지 않는 개발용 브랜치는 삭제한다.

$ git pull father // 원본 저장소 내용과 동기화
$ git branch -d develop // 개발용 브랜치 삭제

 

정리

내 원격 저장소 Remote가 origin
원본 저장소 Remote가 father이라 할 때,

1. 내가 develop 브랜치에서 개발
2. git push origin develop
3. 안정적이라면 git checkout main -> git merge develop -> git push origin main
4. 원본 저장소의 각자 브랜치에 PR 요청

 

 

글을 다 적고나서 느낀 내용이지만, 깃허브에 push와 Pull Request를 한다는 건 매우 관리를 잘해야 한다는 생각이 들었다.

그래서 느낀점으로는 포크해온 내 원격 저장소에 개발용 브랜치를 만드는 것까지는 맞으나,
개발용 브랜치 내용을 내 원격 저장소 main 브랜치에 반영하고,
검토해서 문제 없으면 원본 저장소의 dev 브랜치로 Pull Request를 보내는 게 맞겠다는 생각이 들었다.

'기타 > git' 카테고리의 다른 글

[git] Git Pull과 Clone, 여러 저장소 다루기  (1) 2023.11.18
[git] Git branch와 Merge 합병 충돌  (1) 2023.11.18
[git] Git add, commit, diff, difftool  (0) 2023.11.18