짧은 프로젝트라고 가정하고 Develop 브랜치까지 파지 않고 Main 브랜치와 각각의 기능별 브랜치를 판다고 가정.
(Develop 브랜치를 파면 나중에 Develop 브랜치에도 규칙을 적용시켜 주면 된다.)
레포지토리 파는 사람이 할 일
1. 깃에서 레포지토리를 판다. README도 추가해 놓는다.
README추가는 옵션! 근데 만들어놓는게 난 더 편했다. 내가 bash에서 명령어를 직접 입력하는데 README를 추가해놓지 않으면 깃허브에서 주는 명령어로 하는데 그거로 하다보면 오히려 헷갈린다..
2. Settings - Branches - Add branch protection rule
main 브랜치의 rule을 정하려면 Branch name pattern에 main을 적고
Protect matching branches - Require a pull request before merging ✔(이 브랜치에 머지하기 전에 풀리퀘스트가 필요) - Require approvals ✔(풀리퀘스트를 머지하기 위해 승인이 필요한지 필요하다면 몇 명의 승인이 필요한지)
여기서는 간단하게 1명의 승인이 필요하다고 설정! 밑에서 Create 버튼 꼭 눌러서 protection rules가 만들어졌는지 확인한다.
3. 프로젝트의 틀을 만들어서 첫 commit하기!
프로젝트 폴더에서 git bash를 열어준다.
1) git init으로 git을 활성화 시켜주기
2) git remote add origin <레포지토리 ssh 주소> (<< 레포지토리에서 <> code 버튼을 누르면 확인할 수 있다.)으로 원격 저장소를 등록한다.
3) git pull origin main : origin(원격 저장소)에 있던 내용을 main브랜치로 가져온다. 뭘 가져오냐면 아까 README 파일 추가했던 커밋을 가져온다. main브랜치에서 커밋이 한 번도 이루어지지 않으면 브랜치를 만들 수 없기 때문에 README파일을 만들지 않았다면 main브랜치에서 다른 파일로 commit을 해줘야 한다.(이게 귀찮아서 처음에 README 만듬)
4) 프로젝트 파일들을 first라는 브랜치에서 main 브랜치로 PR을 보낼 것이다.
git branch first : main 브랜치에 있는 상태로 이 명령어를 입력하면 main브랜치에서 first라는 브랜치로 분기를 낸다.(브랜치를 만들 때는 현재 위치가 중요하다..!)
git branch : 브랜치 목록을 확인하는 명령어. first 브랜치가 잘 만들어져있나 확인한다.
git checkout first : 작업 브랜치를 first 브랜치로 옮긴다.(checkout도 조심해서 써야 한다. 현재 내 브랜치에 change상황이 있는데 여기저기 옮겨다니면 다른 브랜치에 내 change로 영향을 끼친다던가 할 수 있기 때문에 그럴 때는 git stash를 이용해서 change를 저장해두고 브랜치를 옮겨야 한다. )
first 브랜치로 작업 브랜치가 잘 바뀌었나 확인!! 오른쪽에 하늘색으로 first로 바뀐 것이 보인다.
5) 여기서는 status를 확인하고, 모든 파일을 add 해주고, 간단하게 commit해주고, push를 해주면 된다.
여기서 이 warning은 나올 수도 있고, 안 나올 수도 있다. OS마다 줄바꿈을 바라보는 문자열이 다른데, 내가 쓰는 윈도우의 경우 CRLF를 쓰고 있기 때문에 깃에서 이런 경고를 주는 것 같다. 반대로 윈도우즈에서 LF로 쓸거야 라던가, 맥에서 CRLF를 쓸거야! 하면 바꿔줘야 하겠지만 나는 윈도우즈고 나중에 CRLF로 알아서 해준다니까 여기서는 그냥 넘기면 된다.
6) 깃허브로 돌아온다. pull request 를 보낼 수 있는 창이 뜬다.
가끔 안 뜨기도 한다. 그럴 때는 Pull requests 탭에 들어가서 New pull request로 PR을 직접 보낼 수 있다. 여기서는 버튼이 활성화가 되어 있으니까 버튼으로 해보겠다!!
7) 어디로 PR을 보낼 것인지 여기서 정하면 된다. develop 브랜치로 보내려면 base를 develop 브랜치로 바꿔주면 된다. 아래에서 commit, 변화된 파일, contributor를 볼 수 있다.
8) X Review required 라고 되어 있다. 아까 main브랜치 규칙을 정할 때 1개 이상의 승인이 필요하다고 해서 이렇게 된 것이다. 원래는 Files changed에 가서 Revies changes에 approve 옵션을 선택해주면 승인이 되지만, 일단 여기서는 승인이 필요없는 단계이므로 Merge without waiting~ 옵션을 선택하고 Merge pull request 옵션을 보면
Create a merge commit : PR커밋과, 브랜치에서 했던 여러 커밋이 같이 올라간다.
Squash and merge : PR안에 여러 커밋이 있을 수 있는데 여러 커밋을 올리지 않고 main에는 PR 커밋만 올라간다.(커밋 기록이 깔끔해진다.)
Rebase and merge : 안 써봤다!! 몰라!! rebase 어려워!!
여기서는 Squash and merge를 선택해서 PR 커밋만 올라가게 하겠다. 선택 후 Squash and merge를 눌러 준다. cloise pull request가 아니라 Squash and merge를 눌러줘야 한다.(예전에 내가 몰라서 헤맷던 것..)
그리고 Confirm squash and merge를 눌러준다.
9) PR이 잘 머지되었다고 나오고, Delete branch가 나온다. 여기서 내가 팠던 first branch는 프로젝트 틀을 만들기 위한 branch였으므로 바로 삭제해준다.
4. Settings - Collaborators - Manage access에서 팀원들을 추가한다.
콜라보레이터가 해야 할 일
1. git clone : 원격 저장소를 내 로컬 저장소로 가져오는 명령어를 이용한다.
Repository에 있는 <>Code 부분에서 SSH 주소를 복사해준다. 내가 작업할 폴더에서 git bash를 열어서
git clone "SSH 주소" 명령어를 입력한다.
2. 내가 작업할 브랜치를 만든다.
git branch : branch 목록을 확인한다.
git branch feature/2/Login : main에서 이 명령어를 실행하면 main 브랜치에서 이 브랜치 이름으로 분기를 낸다.
여기서는 feature : 기능추가 / 2 : 이슈번호 / Login : 기능 설명 식으로 지었다.
git checkout feature/2/Login : feature/2/Login 브랜치로 checkout한다. 작업하는 곳을 바꾼다!
오른쪽 하늘색으로 checkout이 잘 되어 있는지 확인한다.
3. 작업 후 commit, push
나는 여기서 README.md 파일을 변경했다.
git status : git 상태 확인 어떤 파일이 add 되어 있는지 되어 있지 않은지 확인할 수 있다.
git add README.md : README.md 파일을 add 해준다.
git commit -m "~" : ~를 제목으로 하여 commit한다.(내용은 없다. 원래 작업할 때는 내용도 같이 하는게 좋다. 근데 사실 그 내용도 PR할 때 자세히 쓸거긴 한데 내 commit을 보고 나도 그걸 바탕으로 PR 을 기록할 수도 있기 때문에 commit 명은 깔끔하게! commit 내용은 자세하게!
git push origin feature/2/Login : 원격 저장소(origin)에 내 브랜치에 있던 내용을 push한다.
4. 깃허브 사이트로 가면 풀리퀘스트 버튼이 활성화 되어 있다.
** 여기서 알아두면 좋은 점!! : 만약 풀리퀘스트가 아직 승인이 안 되어서 머지를 안했는데 푸시를 하고 싶으면 어떻게 하는가. 그러면 기존 풀리퀘스트가 최신 푸시로 바뀐다. 정확히는 덮어씌워지는 느낌인 것 같다.
그래서 하루가 끝나면 일단은 자신이 작업한 데까지 커밋하고 푸시한 다음 PR을 보낸다. 또 작업하고 커밋하고 푸시한다. 작업이 이루어짐에 따라서 자신이 PR내용을 수정할 수 있다. 그리고 어느 정도 완성이 되면 그 때 코드 리뷰를 받고, 풀리퀘를 승인하는 식으로 진행이 된다.
승인이 되면 자신이 작업했던 브랜치는 삭제하고 다시 main브랜치에서 git pull origin main으로 원격 저장소에 있는 최신버전을 내 main브랜치로 가져온 후, 다시 브랜치를 파고 다시 작업하고 PR을 올리는 식으로 진행하면 된다.
PR을 이용하여 코드 리뷰하는 방법은 다음 링크를 참고!
https://gilded-meeting-f87.notion.site/1-09602c95f98240b6a9b64f2271f1a32a?pvs=4
풀 리퀘스트로 코드 리뷰하기 (1)
자신의 포크해 온 레포지토리가 아닌 원래 레포지토리(여기서는 제 계정의 Java_Study 레포지토리)로 들어오셔서 풀 리퀘스트로 들어옵니다.
gilded-meeting-f87.notion.site
'STUDY > GIT' 카테고리의 다른 글
[TIL] Github Action 2 - Workflow 구성해보기(작성 중) (0) | 2023.08.01 |
---|---|
[TIL] Github Action이란? CI/CD에 대해 (0) | 2023.07.28 |
[TIL] 포크 저장소와 내 로컬을 동기화하기 (0) | 2023.06.18 |
[TIL] 풀리퀘스트로 코드 리뷰하기! (0) | 2023.06.13 |
[TIL] Git reset & revert 연습 (0) | 2023.06.10 |