git을 사용한 버전관리와 협업 문화

 

도구를 통해 git 사용하기

git을 이용해 버전 관리를 하게되면 CLI를 사용할 수도 있고 GUI를 사용할 수도 있다. 나는 기본적으로 sourcetree라는 GUI를 사용하고, (github Desktop으로 바꿔보려고 하는데, 역시 익숙해져있는건 소스트리라서 자꾸 쓰게된다...) CLI도 함께 섞어 쓰고 있다. 

 

CLI와 GUI

• 대부분의 사람들은 GUI를 더 빠르고 쉽게 배워서 사용할 수 있다.
• GUI는 대부분의 경우 사용자에게 즉각적인 시각적 피드백을 제공하는 반면 CLI의 경우 명확한 피드백이 없는 경우가 많다.
• GUI에는 명령줄 인터페이스와 같은 수준의 기능과 세부적인 제어가 없다.
• CLI는 사용에 더 큰 유연성을 제공한다. GUI로는 하기 어렵거나 불가능한 일을 쉽게 할 수 있다. 
  (개인적으로는 git force push 나 stash 같은 명령은 CLI가 훨씬 편하게 느껴진다!)
• GUI는 일반적으로 동시에 여러 작업을 쉽게 조작할 수 있는 더 높은 기능을 가지고 있다.
• CLI를 사용하면 사용자가 파일 시스템과 운영 체제를 모두 제어할 수 있으며 작업이 간단해진다.

https://tableplus.com/blog/2018/08/cli-vs-gui-which-one-is-better.html

CLI vs GUI - Which one is better?

두 가지 방식 모두 장단점이 있는만큼 프로젝트 규모, 팀 환경에 따라 효율적인 방식은 다를 수 있겠다.

개인적으로는 프로젝트 규모가 커질수록 흐름이 복잡해지고 변경사항 또한 많아지기에 직관적이고 시각적으로 빠르게 파악할 수 있는 GUI를 더 선호하고 있다.

 

코드 리뷰하기

 

코드 리뷰는 다른 사람이 작성한 코드에 대해 피드백을 주고 받으면서 더 좋은 코드를 만드는 과정이다.
코드 리뷰는 왜 협업문화에서 중요할까?

먼저 내가 미처 파악하지 못한 실수나 문제점을 인지할 수 있게 만든다. 이러한 과정을 통해 프로젝트의 버그나 장애를 사전에 예방할 수 있게 만든다. 또한 개인간의 격차를 해소하고 전체적인 조직의 역량을 끌어올리는 상향 평준화의 기능도 한다.

 

하지만 무엇보다 가장 중요한 점은 어떤 문제가 발생했을 때, 그 문제가 발생한 코드를 작성한 사람에게 책임을 묻거나 비난하는 상황이 일어나지 않게 된다는 것이다!

코드 리뷰 문화가 잘 정착된 경우, 리뷰가 진행되었던 코드들이 최종적인 결과물에 반영되기 때문에 모든 구성원들이 책임을 갖게 된다. 그렇기 때문에 더 좋은 품질의 코드들이 만들어지고 그 과정에서 모두가 같이 성장하는 협업문화가 만들어지게 될 것이다.

 

코드리뷰의 방식은 다양하지만 대표적으로 github의 issue와 pull request를 통한 코드 리뷰 프로세스가 있다. 

팀원들은 issue 생성을 통해 개발해야할 사항, 개선해야할 것들, 버그들을 공유할 수 있다. 그리고 등록한 issue 마다 브랜치를 생성해서 그 issue에 대한 작업을 할 수 있게 된다. issue를 확인하는 것을 통해 구성원들이 진행하는 작업단위를 이해하고 프로젝트의 진행 방향을 파악할 수 있다.

브랜치에서 작업을 완료하고 로컬 저장소에 push까지 마치게 되면 pull request를 생성해서 최종적으로 병합되기전 절차를 거친다. 여기에는 작업한 내용이 무엇인지, 어떤 것들이 변경되었는지를 확인할 수 있다. 이 과정에서 우리는 코드에 대한 피드백을 주고 받을 수 있다.

여기서 주의할 점은 하나의 PR에 너무 많은 작업을 담지 말아야한다는 것이다. 작업단위가 커지면 리뷰 진행도, 반영도 오래걸리고 힘들어지기 때문이다.

 

 

최선의 협업 환경을 만들어내기 위해 노력해야 할 것

 

git이라는 하나의 협업툴 안에서도 다양한 세팅과 선택이 존재한다. 그렇기 때문에 최대한 효율적인 프로젝트 관리와 진행속도를 내기 위해서 어떤 룰셋을 만들것인지 팀원들 간의 충분한 협의과정이 필요하다. 하지만 처음부터 완벽하게 모든 룰셋을 정해서 프로젝트를 시작하려고 한다면, 오히려 그 과정에서 피로가 많이 누적되어 개발하는 시점에서 100%의 에너지를 내지 못하거나, 진행 속도가 더뎌질 가능성도 있다.

처음부터 완벽하게 룰셋을 정하기 보다는, 어느 정도의 규칙안에서 진행을 시작하고 팀의 성격과 팀원들의 성향에 맞게 서로 핏을 맞춰가는 것이 좋은 접근이 아닐까하는 생각이 든다.

 

2024의 리제파 : 지금과 당시를 비교해보았을 때 개인적인 생각이나 취향이 바뀌지는 않았네요. 다만 커밋 메시지 같은 경우 실무에서는 작은 작업 단위로 하나씩 끊어서 커밋하는게 쉽지 않음을 느꼈습니다.
현재 팀 내에서는 하나의 PR이 merge 될 때의 커밋 메시지만 신경쓰는 편입니다. 그 작업이 squash merge 될 때의 커밋 메시지만 컨벤션을 정해놓는 식! 이렇게 하니 작업할 때 커밋 단위에 대한 고민이 사라져서 오히려 작업 능률이 오르는 것을 느끼고 있습니다. (오히려 좋아..?)
하지만 역시 코드 리뷰시 작업 내용을 파악하고 리뷰하기에는 불편한 점이 있는데요, 이런 단점은 작업에 대해 커밋을 쪼개기 보다 PR 단위를 쪼개는 방식으로 해결하고 있습니다.

위에서는 git과 같은 환경 안에서 협업에 대해 어떻게 접근하면 좋을지에 대한 이야기를 한 것이지만, 지금 읽어보니 프로젝트 구조나 코드 컨벤션에 대해서도 맥락이 같은 부분이 있다고 생각되네요!
최근에 기존 vue2 프로젝트를 vue3 로 마이그레이션 하는 작업을 진행하고 있습니다.
엄격하지 않은 커다란 규칙들만을 정하고 작업을 시작하긴 했으나... 진행하면서 나오는 의견들로 중간중간 프로젝트 구조의 방향이 바뀌는 일이 잦아져서 진행이 더뎌지고 있음을 느꼈습니다.
물론 가장 이상적인 것은 더 좋은 방향과 구조가 떠오를 때마다 논의 후 반영하면서 develop 하는 것이겠죠?
저는 더 좋은 방향으로의 전환 의견이 나올 때마다 거의 찬성하는 일이 많았는데요, (약간 팔랑귀 스타일.. 👂🏻)
제한된 일정 안에서는 어느 정도만 타협하면서 일정을 맞추는게 우선인 것 같습니다.
처음부터 너무 완벽한 프로젝트를 만들려는 욕심은 오히려 모두를 힘들게 한다! 를 느끼고 있습니다 ㅎㅎ
조금 더 냉정하게(?) 주어진 상황을 읽고, 현실적으로 지금 반영이 가능할지를 고민해보는 것도 중요하다는 것을 배우고 있어요.

위에서 고민했던 내용들이 실무에서도 비슷한 맥락으로 고려되고 있음을 알 수 있네요!

 

2022/04~ 2022/07 개발 인턴 타임라인