개요
- 지난 앱 프로그래밍 팀 프로젝트에서 깃을 공부하지 않고, '한 사람 작업이 끝나면 압축 -> 메일 전송'과 같은 바보 같은 방식을 사용하여 이번 프로젝트를 진행할 때는 그러지 않기로 위 내용을 공부하여 정리한다.
Pull Request 사용 단계
- 원본 저장소에서 브랜치 생성
- 1단계에서 생성한 브랜치를 내 원격 저장소로 Fork
- 내 원격 저장소 Clone
- 원본 저장소 Remote 설정
- 내 원격 저장소 브랜치 생성
- 5단계에서 생성한 브랜치에 add, commit, push
- 원본 저장소에 대한 Pull Request 생성
- 원본 저장소 관리자에 의해 Merge Pull Request
- 원본 저장소의 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' 카테고리의 다른 글
[GitHub] 하나의 PR 메세지에 PR 링크를 올려 잘게 쪼개기 (2) | 2024.09.07 |
---|---|
[Git] Git의 원리 이해하기 - 내부 동작과 .git 파일 구조 분석 (0) | 2024.08.01 |
[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 |