[Git 관리] - 혼자서 협업 연습해보기

ain·2023년 5월 7일

git

목록 보기

2/3

본 글에서는 실제 협업할 때 Git 관리를 어떻게 해야하는지 소개하는 글이 아닌 협업 전에 연습해볼만한 방법을 소개합니다.

Git 관리가 뭐죠?

혼자서 프로젝트를 해왔다면 GitHub을 사용하면서 그저 commit push만 반복해서 작업해왔을 것입니다. GitHub는 내가 만든 프로젝트를 기록하는 역할을 하는 것뿐만 아니라, 협업을 할때에도 매우 유용한 툴입니다. 이때 협업이라고 해서 10명쯤은 되야 하는 것이 아니라 2명이서 작업할때도, 심지어 혼자 작업할 때도 관리를 할 수 있다는겁니다.

그렇다면, 혼자서 작업할 때 관리라는 것을 해야 할 필요가 있을까요? 어차피 내가 작업해온 것들이니 내 취향대로 commit하고 push하면 되는 것 아닐까요? 코드 짜는 것도 시간 없는데 Git 관리를 꼭 해야 할까요?

이러한 질문들은 제 과거의 질문들이였습니다. 지금에서야 깨닫고 Git 관리하는 방법을 소개해보려고 합니다.

Git 관리 순서

이슈 정의하기 -> commit 쪼개고 push하기 -> PR 날리기 -> 코드리뷰하기 ->merge하기

알고리즘 강의를 보면 코드를 짜기전에 손으로 먼저 순서를 적으라는 말을 들어 볼 수 있습니다. 여기서도 먼저 작업할 내용(Issue)을 정의하고 작업을 합니다.

1. 이슈 정의하기

대부분의 오픈소스를 보면 Issue는 앱 실행 도중 발생하는 문제나 제안을 적는 공간입니다. 하지만 개인 프로젝트를 할때에는 Todo List를 적는 공간으로도 사용할 수 있습니다. 추가로 Issue와 Pull Request는 마크다운으로 스타일링이 가능하여 깔끔하게 볼 수 있습니다.

이슈 정의 예시입니다

이슈를 적는 곳 오른쪽에는 작성자 태그, 라벨 선택, 그리고 Pull Request와 연동할 수 있는 칸이 있습니다.

Assignees: 써있는 그대로 본인을 태그하면 됩니다.
Labels: documentation, bug, enhancement등 이슈내용에 맞는 라벨을 선택하면 됩니다.
Projects: 협업을 여러명이서 할 때 organization을 만들어 Project에서 일정을 관리할 수 있는데 그때 연동할 수 있습니다.
Milestone: 사용해본 적이 없으므로 생략하겠습니다.
Development: 특정 Pull Request와 연동할 수 있으며, 연동시 Pull Request가 머지 되어 닫히게 되면 해당 Issue도 자동으로 닫힙니다.

Submit new issue를 하면 Issues에 열립니다.

이제 본인이 작성한 대로 작업을 진행하면서 완료된 task는 체크를 해나가면 됩니다.

2. 작업 branch 만들기

보통 main 브랜치는 배포시 사용하며, main브랜치에서 develop브랜치를 따로 만들어 해당 브랜치에서 개발을 진행합니다.

커맨드를 사용하여 브랜치를 develop 브랜치로부터 파생합니다.(브랜치 이름은 본인취향에 맞게 네이밍합니다.)

%develop git checkout -b <new-branch/issue-number>
// 예시
%develop git checkout -b feature/1

이제 develop 브랜치에서 모든 코드를 합칠 것이기 때문에 merge 할때 헷갈리지 않기 위해 default branch를 develop 브랜치로 변경해줍니다.

Default branch 변경 방법
Settings -> General -> Default branch -> Switch to another branch 아이콘 클릭 -> 선택 후 Update 클릭

이제 feature/1라는 브랜치에서 작업을 한 뒤, commit push를 진행합니다.

3. commit 쪼개기

commit을 쪼갠다는 것은 무슨 말일까요? 왜 쪼개는 것일까요? 어떻게 쪼갠다는 것일까요?

쪼갠다?
commit을 쪼갠다는 것은 한번에 모든 commit을 올리는 것이 아니라, 기능 단위로 쪼갠다는 것을 의미합니다.

왜 쪼개?
a, b, c 작업을 한번에 다하고 commit을 하였는데 a까지 작업한 곳으로 돌아가고 싶어졌습니다. 하지만 a를 수정하려면 여기저기서 되돌려야 할 것이 많기 때문에 어려울 것입니다. 한마디로 수정을 쉽게 하기 위해 commit을 쪼갭니다.

또, 코드리뷰할때 보기 편한 이유도 있습니다.
아래 사진의 commit을 보면 어떤 부분을 작업했는지 알아보기 쉬울까요?

어떤 페이지 작업이 끝났다는 commit만 있으면 나중에 디버깅도 힘들것이고, 코드리뷰를 하는 사람이 나말고 더 있다면 십몇개의 변경된 파일을 하나 하나 보면서 리뷰를 진행해야 할 것입니다.

위의 예시를 보면 "write journal form에 있는 date를 지웠구나." 라고 얼추 예상할 수 있습니다. 또, 이 commit안에 다른 내용은 없고 date를 지운 내용만 있다면 훨씬 보기 수월할 것입니다.

어떻게 쪼개?
작업을 마치면 기능 단위로 혹은 한줄로 설명할 수 있을 만한 작업들을 commit 합니다.

%feature/1 git add ./src/pages/MainPage.jsx
%feature/1 git commit -m "feat: implements main page UI"

이렇게 쪼개고 commit하고를 반복합니다.
다 마쳤으면 push를 합니다. 작업중인 branch를 remote에 올린 적이 없다면 git push --set-upstream origin <branch>을, remote에 branch가 올라와있다면 git push를 하여 push를 하고 Pull Request를 날립니다.

4. Pull Request 올리기

줄여서 PR, 풀리퀘라고도 불리는 Pull Request를 올릴 차례입니다.
Pull Request는 다른 사람에게 자신의 코드를 보여주고 리뷰를 받기 위함입니다. 개인 프로젝트를 하고 있다면 자신의 코드를 돌아볼 수 있는 시간이 됩니다.
Issue와 동일하게 마크다운이 지원되고, Issue 번호를 <#이슈번호> 이렇게 적어올리면 해당 Issue와 연동이 됩니다. 이 Pull Request가 수락되어 merge를 진행한다면 연동되어있는 Issue도 자동으로 닫힙니다.

Pull Request 올리면 작성한 내용과 그동안 작업한 commit들, 연동된 Issue, 그리고 내 PR과 commit에 달린 댓글들을 볼 수 있습니다.

Issue와 동일하게 오른쪽에는 태그 항목들이 있습니다.

Reviewers: 리뷰를 요청할 사람들을 태그합니다.
Assignees: Pull Request를 작성한 본인을 태그 합니다.
Labels: documentation, bug, enhancement등 Pull Request내용에 맞는 라벨을 선택하면 됩니다.
Project: Project가 있다면 연동합니다.
Milestone: 사용해본 적이 없으므로 생략하겠습니다.
Development: 특정 Issue와 연동할 수 있으며, 연동시 Pull Request가 머지 되어 닫히게 되면 해당 Issue도 자동으로 닫힙니다. 이 부분은 Pull Request 작성부분에서 Issue 번호를 언급했다면 건들이지 않아도 됩니다.

5. 코드 수정하기

본인의 코드를 살펴보다가 수정할 사항이 있다면 수정을 진행하고 commit 및 push를 합니다. 이때 따로 Pull Request를 만들 필요없이 자동으로 이미 작성된 Pull Request로 커밋이 들어갑니다.

6. Merge하기

코드도 다 수정하고 Issue에 정의한 내용도 다 완료하였다면, Pull Request의 comment 다는 곳 바로 위에 Merge Pull Request버튼을 클릭하여 Merge합니다.
로컬에서는 머지해야 하는 branch로 이동하여 git pull 커맨드를 입력하여 원격에 있는 코드들을 땡겨옵니다.

%feature/1 git checkout develop
%develop git pull

여기까지 한 작업들을 반복해줍니다.

마지막으로 배포시에는 main에 코드들을 merge 한 뒤 main 브랜치를 default branch로 설정하여 배포합니다.

Git 관리 이유

위에 순서들을 쭉 훑고 직접 진행해보았다면 이유도 바로 알 수 있습니다. Git 관리는 나의 코드들을 관리하는 것이며, 나의 작업들을 하나하나 자세히 기록하는 일입니다. 혼자서 작업할 때에는 효과를 덜 보겠지만, 나의 코드를 보는 사람이 생겼을 때부터 관리를 해보면서 관리의 중요성을 깨닫게 됩니다.