Git - Github decktop을 통해 협업하기!!
디프만을 통해 최근 프로젝트를 진행하고 있고, 혼자서 공부하던 것에 비해 적용해야 할 것이 많았다.
동아리를 통해 여러 방법을 통해 다른 사람들과 협업하는 것에 배울 수 있었는데, 이 내용에는 Notion, Slack, Kanban등 많은 것들이 있지만 이번에는 Git에 관한 것을 중점적으로 다루려 한다.
공통 개발 저장소 만들고 함께 사용하기
나는 백엔드 팀의 일원이고 동일한 백엔드 직무의 사람들과 함께 개발을 진행해야 한다.
그렇기 때문에 여러 백엔드 팀원이 하나의 프로젝트를 관리하기 위해 공통 개발 저장소를 사용해야 한다.
먼저 함께할 repository를 만든다.
참고로 동아리에서는 이미 동아리 명의로 되어있는 Organizations이 있었다.
Settings - Collaborators - Add people을 통해 원하는 사람을 초대한다.
이런 식으로 원하는 사람을 검색하고, 이후 추가해줄 수 있다.
이제 상대가 이 요청을 받으면 함께 사용할 수 있다.(현재는 public으로 두었지만, private으로도 가능하다)
Github desktop에서 해당 repo 클론
HTTPS를 쓰거나 SSH를 쓰는 방법으로 클론할 수 있는데, 이 둘의 차이는 나중에 기회가 되면 쓰겠다.
File - clone a repository에서 URL을 이용하여 해당 repository를 클론한다.
이제 Github desktop에서 intelliJ로 열거나, 만들어진 폴더에서 이를 본인의 IDE로 열어주면 된다.
위치는 이렇게 확인이 가능하다.
이제 무언가를 개발하고 이를 Git에 올릴 수 있을 것이다.
test.txt를 작성해 주었다.
commit - push - publish
이런 식으로 개발을 시작하고 내가 만든 내용들을 Git에 올려줄 수 있다.
참고로 깃에서 올릴 때 메세지의 경우도 생각해 주어야 할 것이 있다.
Branch를 나누자
보통 혼자서 개발을 하는 경우 위의 내용까지 진행하면 개발을 시작하고 Git에 올리면 될것이다.
근데 여러명이서 개발을 하는 경우, 몇몇 이유 때문에 이런 식으로 하면 안된다.
- 보통 여러 명이서 프로젝트를 하는 경우는 실제로 배포하는 경우가 많다.
- 모듈 단위, 기능 단위로 개발하는 경우가 많다.
- 코드 리뷰가 필수적이다.
- 다른 사람과 내 코드가 충돌을 일으킬수도 있고 서로의 상황에 맞추어 적용을 다르게 해야 한다.
여러 이유가 있지만, 개인적으로는 위의 4가지 이유가 중요하다고 본다.
모든 개발자가 하나의 main branch에서 바로바로 작업하는건 당연히 좋은 방식이 아닐 것이다.
그렇기 때문에 자신이 작업할 Branch에 해당 프로젝트를 가져오고, 여기서 작업한 뒤에 올리는 식으로 해 준다.
먼저 이런 식으로 intelliJ에서 branch를 따줄수도 있고
혹은 이렇게 Github desktop에서 따줄수도 있다. 이건 알아서
이렇게 하면 Git에서 자신의 Branch가 완성된다 참고로
본인의 working branch는 확인할 수 있고, 만약에 이 branch가 바뀌면 그곳에 맞추어 내용도 변경된다.
Branch에서 개발하기
이제 개발을 하고, 이 개발 내용을 main 브랜치에 적용해 보아야 한다.
이런 식으로 아무 파일을 하나 만들어 보자
실시간으로 Github desktop에서 이를 확인 가능하다.
개인 branch에서 main branch로 Pull Request 올려주기
이 파일을 이제 commit & push 해준다.
그런데 이제 Git의 main 브랜치에서는 이 내용이 확인되지 않는다.
당연한 것이, main 브랜치가 아니라 내 feachers/github-desktop 브랜치에서 만들어진 내용이기 때문이다.
이제 이걸 main에 올려본다.
Pull requests에 들어간다.
들어가보면 방금 내가 올린 내용이 compare&pull request에 나타난다.
여기 들어가보면
대충 이런식으로 나온다... 이 pull request의 경우도 컨벤션을 적용하는게 좋은데, 일단 이대로 간다.
여기서 여러 내용들을 설정해 줄 수 있다.
- Reviewers
- 해당 Pull Request(PR)을 확인해줄 리뷰어를 설정한다. 참고로 무료 버전에서는 public은 15명, private의 경우 1명밖에 설정 못한다.
- Assignees
- 이 PR의 담당자를 넣어준다. 보통 자신을 넣어줄 것이다.
- Labels
- 해당 PR의 목적을 넣어준다. 이것도 본래 디프만 Organization에서는 엄청 많은 내용이 있는데 내 개인 계정에는 몇 개 없었다.
- Projects
- 어떤 프로젝트에 사용될지 넣어준다.
- Milestone
- 해당 프로젝트의 진척도, Issue tracking에 사용된다.
올리면 이렇게 나온다.
이제 이 PR을 가지고 다른 사람들이 리뷰를 진행해 줄 수 있다.
PR 리뷰하기
files changed를 들어가면 main과 해당 branch에서 이루어진 PR내용의 차이를 볼 수 있다.
완전히 새로 만들어진 파일이 보이는데, 오타가 있다.
저 파란색 + 버튼을 누르거나, 원하는 구역이 많으면 드래그해서 그 내용의 커맨트를 달아줄수 있다.
이런 식으로 리뷰를 달아준다.
하나의 리뷰만 달거나, 다양한 파일에 대한 리뷰를 동시에 달 수도 있다.
다 달았으면 Finish your review에서 해당 파일을 적을 말과 함께 올린다.
추가로
- comment
- 커멘트
- Approve
- 리뷰 결과 문제가 없으므로 merge가능
- Request changes
- 변경 요청
이 있는데, 나는 원래 변경을 요청했으므로 request changes를 눌러야 하지만 내꺼라서 그냥 comment로 하겠다.
참고로 Approve의 경우 몇 명 이상이 Approve체크 해야 PR의 적용(merge)가능 이런 식으로 전략을 만들어줄 수도 있다.
이제 해당 PR에 코드 리뷰된 내용이 적용되었다.
PR리뷰 처리하기
내 코드가 잘못되었으니 이제 고쳐준다.
고쳐서 다시 commit & push하면 놀랍게도 알아서 고쳐진다.
이제 코드에 문제가 없으니까 이거를 적용하면 된다.
PR 머지하기
merge pull request 클릭
참고로 이거 여기서 나랑 동시에 누군가가 코드를 수정하고 먼저 main에 반영하면 conflict가 생길 수 있는데, 이 해결방법이 워낙 길고 복잡해서 여기서는 다루지 않겠다.
대충 설명하면 Git에서 바로 확인해서 문제되는 부분을 고쳐주거나, IDE에서 바꿀수도 있고, CLI를 통해서도 변경 가능하다.
암튼 적용하면
이렇게 나오고
해당 PR이 closed된다.
그리고 이제 Main쪽에 해당 내용이 적용됨을 확인 가능하다.
내 브랜치에서 main받기
그러면 개인 브랜치 -> main으로 코드를 적용하는건 되었다.
이제 반대로 내 브랜치에서 main쪽 코드를 받아와야 한다.
예를들어 feachers/intelliJ 브랜치에서는
지금 내용이 적용되어 있지 않다.
그러면 이걸 받아와야 하는데
사실 여러 방법이 있지만... 그냥 반대로 PR 받아서 하는게 깔끔해 보인다.
사실 지금 설명한 내용은 어느정도 익숙해지면 바로바로 쓸 수 있기도 하고, 이보다 중요한 내용이 어어어엄청 많긴 한데 그래도 Git을 사용한 협업에서는 가장 기초적이지만 중요한 것이라 생각해서 일단 작성했다.
협업 열심히 하자!
'기타' 카테고리의 다른 글
| 협업 전략 (0) | 2022.12.08 |
|---|---|
| Intellij 꿀팁 (0) | 2022.04.17 |