짐 덩어리, Git 브랜치 삭제 적용해본 이야기

1) 서론

이 글을 읽는 대부분은 이사를 해본 경험이 있을 것입니다. 그리고 아마도 "왜 이렇게 짐이 많지? 이걸 왜 안 버리고 있었을까?"라는 생각을 한번쯤은 해보셨을 텐데요.

지금은 쓸모없어 보이는, 구석에 어딘가 둔 물건이 과거의 나에게는 소중했었을 것입니다. 혹은 미래에 소중할 것이라고, 당시에 생각했었을 수도 있고요. 

하지만 중요한 건 현재의 내가 느끼는 필요성일 텐데요. 모든 기준은 현재의 나 자신입니다. 과거를 후회하는 것도, 미래를 희망하는 것도 현재의 나 자신입니다.

GIt도 마찬가지입니다. GIt이라는 VCS로서 역사를 기록하지만, 결국에는 마지막으로 merge 된 최종본이 중요합니다. 

Git의 역사를 기록하는 방법 중 하나인 branch를 더 깔끔히 유지하는 방법에 대해서 알아봅니다.

 

---

2) 짐 덩어리 branch들

현재의 근무 중인 회사는 Github 저장소를 철저하게 관리하지는 않았습니다. 아마도 저장소 관리보다는, 빠르게 코드를 반영시키고 성장을 하는 것이 우선이었을 것이라고 추측하는데요. 미처 Github까지 관리할 수 있는 여유가 없었을 것 같습니다.

사실 Github 저장소를 관리한다고, 성장이 빠르거나 코드의 품질 자체가 올라가지는 않는다고 생각합니다. Github 없이도 빌 게이츠는 윈도우를 만들었고, 래리 페이지는 구글을 만들었으니까요. 

이러한 배경 때문에 회사 Github의 브랜치들은 산더미처럼 쌓여있었는데요. 어떠한 이유가 있어서, 보관하고 있지는 않았었습니다.

그래서 저는 브랜치를 삭제하자고 제안했는데요.

 

(항상 모든 제안을 귀담아들어주는 개발팀원분들 덕분입니다)

---

3 ) Branch가 뭔가요?

파일을 만들고, git에 commit 하는 과정은 아래와 같습니다.

• git add [파일명]: staging area로 파일을 등록합니다.
• git commit: staging area에 변경된 파일을 최종 commit 합니다.
• commit 후 3개의 object가 생깁니다.
  • blobs: commit 된 파일의 내용
  • tree: blobs 및 디렉터리의 정보들
  • commit: root tree의 pointer 및 metadata

각각의 tree는 snapshot으로서 git이 관리하고, 다음 commit은 바로 이전 commit을 point 하게 됩니다. 

 

뜬금없이 git의 commit에 대해서 너무 길게 이야기 했나요?

Branch도 마찬가지입니다. Branch를 추가한다면, master 브랜치에 영향을 주지 않으면서, 별도의 독립적인 작업환경을 가질 수 있습니다. 그리고 이를 master 브랜치에 merge 할 수 있습니다.

이것이 가능한 이유는 git branch [브랜치명]을 했을 때 이전 commit을 바라보는 pointer를 가지기 때문입니다. 즉 특정 시점의 commit을 바라보는 작업환경을 가질 수 있습니다. 

---

4) 그래서 Branch를 왜 삭제해야 해요?

앞서 말씀드렸듯이 branch는 다른 작업환경에 방해받지 않고, 독립적으로 작업할 수 있습니다. 즉, 각각의 작업을 분기할 수 있다는 것인데요. 이를 위해 이전 commit을 point 합니다.

하지만 작업한 내용이 이미 master 브랜치에 merge 됐고, head가 이를 가리키고 있다면, 과거에 작업한 branch를 남겨야 하는 이유가 있을까요?

최신의 결과물은 master 브랜치를 참고하면 되고, 과거의 내역이 궁금하다면 이전 commit으로 돌아가서 보면 됩니다. branch라는 작업 환경 자체를 유지해야 할 필요는 없어 보이는데요.

현재 근무하는 회사에서는 이를 계속해서 쌓고 있었고, 삭제를 제안하고 적용했습니다.

---

5) 어떻게 삭제하나요?

Branch를 삭제하는데 세 가지 방법이 있습니다.

5. 1) 현재 상황

• test1 파일을 만들었습니다.
• 이를 main 브랜치에 commit 후 push 했습니다.

• main 브랜치에서 test_branch2를 만들었습니다.
  • git checkout -b [브랜치명] - 새 브랜치를 만들고, 이동합니다.
• test2 파일을 만들었습니다.

• 두 번째 commit을 PR을 올렸습니다.
• 그리고 Merge 합니다.

 

드디어 branch 삭제합니다!

5. 2) Github에서 바로 삭제하기

• PR merge 됐습니다.
• Github에서는 branch 삭제를 위한 버튼을 제공합니다.

5. 3) CLI 사용해서 삭제하기

• git branch: 해당 git directory가 관리하는 branch를 보여줍니다.
• git branch -d [브랜치 이름]: local 브랜치를 삭제합니다.
• git push --delete [원격 저장소] [브랜치 이름]: remote 브랜치를 삭제합니다.

• test_branch2는 삭제됐습니다.

5. 3) Github 설정으로 자동 삭제

현재 회사에 제안하고, 적용한 부분은 자동 삭제인데요. 매우 쉽습니다.

 

Repository - Settings - 아래로 쭉 - Pull Request

그리고 아래를 체크합니다.

 

위의 설정을 하게 되면, PR이 merge 된 후 자동으로 브랜치를 삭제해줍니다.

 

• 세 번째 PR이 merge 됩니다.
• merge 후 자동으로 branch 삭제됩니다.

---

6) 결과

기존에는 과거의 branch들이 어떠한 목적에 의해서 보관되고 있지 않았습니다. 사실 알고 있었지만, 귀찮아서 delete가 되고 있지 않았습니다. 그로 인해서 미처 둘 곳을 찾지 못 한 이삿짐들 마냥, 과거의 branch들이 존재했었는데요. 

 

Github의 merge 후 자동 삭제 기능을 통해서, 조금 더 깔끔하게 branch 목록을 관리할 수 있게 됐습니다. 사실 있다고 해서 아무런 문제는 없습니다. 하지만 없어도 된다면, 해당 방법을 통해 더 깔끔하게 유지하는 게 좋을 것 같습니다. 왜냐하면 branch는 그저 당시의 작업환경을 구분하는 공간일 뿐이니까요.

 

하지만, 아직까지는 경험하지 못했지만, branch를 반드시 남기고 관리해야 하는 경우도 있을 것 같습니다. 위의 방법은 모든 PR에 대해서 적용이 되므로, 꼭 남겨서 관리해야 하는 branch가 있다면, 수동 삭제 방법이 더 안전할 것입니다.

---

7) 참고 문헌

https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell#:~:text=A%20branch%20in%20Git%20is,branch%20pointer%20moves%20forward%20automatically.

https://www.atlassian.com/git/tutorials/using-branches