[Westagram] 1.Github 사용으로 느낀점

위스타그램은 인스타그램을 클론코딩한 프로젝트이다.

백엔드 개발을 맡아 Django로 api를 보내주는 연습을 해보았다.

 

처음으로 git을 사용하여 브랜치 생성, PR 작성, 코드리뷰를 진행했다.

1. git 브랜치 활용

내용

한 앱에 있는 기능도 git 상으로는 제각기 다른 브랜치에 존재한다.

예를 들어 회원가입, 로그인, 팔로잉은 모두 users앱에 있지만

회원가입은 feature/sign-up 브랜치에서, 로그인은 feature/login 브랜치에서, 팔로잉은 feature/following 브랜치에서 작업했다.

 

기억할 점

1) a 브랜치에서 b 브랜치를 만들면, b 브랜치는 a 브랜치를 바탕으로 생성된다.

=> initial-setting 브랜치에서 프로젝트를 생성하고, main으로 merge하지 않은 상태에서 모델을 만들어야 하는 상황.

여기서 main에서 model 브랜치를 만들면, model 브랜치에는 manage.py 등 필요한 파일이 하나도 없음을 알 수 있다.

이 때는 initial-setting 브랜치에서 model 브랜치를 만들어야 manage.py 등의 파일이 model 브랜치에 들어간다. 

 

2) a 브랜치 생성 후 파일을 수정했는데 아무것도 commit하지 않고 b 브랜치로 이동하면 b 브랜치에 a 브랜치의 내용이 섞인다.

=> git checkout할 때는 git status로 현재 브랜치 상태를 확인하고 이동하자.

 

느낀점 

이전에 혼자 공부하며 프로젝트를 만들어 봤을 때는

git에 대해 잘 몰라 모든 기능을 main 브랜치에서만 작업했는데

이번에 브랜치를 써보니까 그게 얼마나 불편한 방식인지 새삼 느낄 수 있었다.

 

이전에는 한 기능에서 문제가 생기면 어디서부터 잘못됐는지 찾을 수가 없어

작업했던 모든 기능을 살펴보아야 했는데,

이번에는 팔로잉에 문제가 생기면 팔로잉 브랜치의 이력만 살펴보면 된다는 것이 엄청 편리했다.

또 작업하다 실수를 해도 파급력이 적어서 해결이 훨씬 쉽다는 생각이 들었다.

 

2. PR(Pull Request) 작성

내용

각 브랜치에서 작업이 끝나면 main 브랜치로 push한 후 PR(pull request)을 작성했다.

 

느낀점

PR을 잘 작성하면

1) 내가 정확히 무슨 작업을 했는지 설명할 수 있다. 

2) 내 작업이 전체 프로젝트에서 어떤 맥락을 갖는지 설명할 수 있다.

 

이전에 혼자 프로젝트를 만들어 봤을 때는

기능 구현에 급급해서 기능을 완성하고 나면 내가 정확히 무슨 작업을 했는지 정리가 되지 않았다.

일단 만들었으니 됐다는 생각으로 대충 넘어갔더니 내 코드를 이해하기 어려워서 리팩토링 하기도 힘들었다.

 

이번에 꼼꼼히 PR을 작성해보니 나 스스로 정리가 된다는 점이 좋았고

다른 사람들에게 내 작업을 이해시키기도 쉬웠다.

 

위스타그램은 개인 프로젝트에 가까웠지만,

앞으로 더 큰 프로젝트를 다른 사람들과 같이 작업하는 경우

위 두가지를 나 스스로에게도 다른 사람에게도 잘 설명할 수 있어야 협업하기 좋을 것 같다.

 

3. 코드리뷰 진행

내용

동기들과 github를 통해 코드리뷰를 주고받았고, 

동기들과 코드리뷰가 끝난 후에는 멘토님의 코드리뷰를 받았다.

 

느낀점

왜 가독성 있게 코드를 짜야 하는지 느낄 수 있었다.

어떤 프로젝트를 하든 내가 짠 코드는 나 혼자만 읽는 것이 아니기 때문이다.

 

변수명, 함수명을 잘 짜면 특별한 주석 없이도 코드가 잘 읽힌다는 것을 체감했고

다른 사람들과 프로젝트를 할 때 특히 이런 부분을 신경써야겠다고 느꼈다.