"깃허브로 협업한다"라는 말은 자주 듣지만 정확히 어떻게 이루어지는지 잘 모르는 경우가 많고 실제로 해도 깃허브 기능을 제대로 쓰지 못하는 경우도 많다. 팀프로젝트를 할때마다 깃허브는 항상 새로웠던 경험이 있어서... 이제는 그러지 않기 위해 정리를 해보려고 한다.
- 협업을 위한 repository를 github에 만든다. 이 repository가 바로 우리가 코드를 올리는 장소인 것이다. 이때, 만약 웹서비스를 만든다고 하면 FE와 BE가 있을텐데 이 둘을 나누느냐 마느냐도 선택해야한다. 결론부터 이야기하면 FE레포와 BE레포를 따로 파는 것이 좋다. 만약 하나의 레포에 만든다고 하면 FE/BE 폴더를 각각 따로 만들어서 해주면 되는데 이때 문제가 있다.
먼저, branch별로 기능을 관리하기가 어렵다. 예를 들어 로그인/회원가입 기능을 구현하는 사람이 있고, 마이페이지를 구현하는 사람이 있다고 하면 이것을 branch별로 파서 login/signup 브랜치와 mypage 브랜치를 따로 만들어야 하는데 만약 FE와 BE가 하나의 레포에 있다면 이 브랜치가 굉장히 많아질 것이고 보기도 불편하다. 예를 들면 이런 식이다. FE_login/signup , BE_login/signup , FE_mypage , BE_mypage 이런식으로 같은 기능인데도 FE와 BE를 나누어서 branch를 파줘야 해서 브랜치가 굉장히 많아질 우려가 있고 보기에도 안좋다. main 브랜치는 보통 최종 배포할 때 사용한다고 하니 보통 dev 브랜치를 하나 파서 이곳에 기능들을 merge하는데, dev 브랜치도 FE_dev와 BE_dev를 따로 파야하고 만약에 이것을 실수로 BE코드를 FE에 덮어 씌우기라도 하면 더 복잡해진다. 그래서 굳이 이런 위험을 가질 필요가 없으므로 FE레포와 BE레포는 따로 파주는 것이 좋다고 생각한다. 웹서비스 외에도 이렇게 업무가 나뉘어진다면 대분류에 따라 레포를 따로 파는 것이 좋을 것 같다.
- 이렇게 repository를 만들어 줬으면 이제 branch를 만들건데, 앞에 이미 branch 이야기가 나와서 순서가 조금 이상하지만 어느정도 알고 있다는 가정 하에 설명한 거라 양해 바란다. branch는 아주 쉽게 만들 수 있다. repository에서 main 브랜치를 누르면 브랜치 목록이 나오는데, 거기서 "Find or create branch" 부분에 브랜치 이름을 넣어서 만들어주기만 하면 끝이다. 그렇게 만들어지면 다음과 같이 된다. branch명은 팀원들과 협의해서 기능별로 또는 맡은 사람별로 짤 수도 있다.
- 브랜치까지 만들었는데, 이제 이것을 나의 환경으로 clone하면 된다. 각자가 사용하는 파이참, 인텔리제이, VScode 등의 IDE가 있을 것이다. 이것을 이용하면 굉장히 편하게 쓸 수 있다. 필자는 이것을 사용하지 않은 채로 git을 사용하느라 remote를 매번 설정하는 등의 좀 어려움이 있었는데, cmd에서 clone 하는게 아니라 IDE 내에서 clone을 해주면 더 편하게 사용할 수 있다. 물론, 깃허브 데스크탑을 사용하면 더 쉽다고 하는데 아직 배우질 못했다. 이 글에서는 파이참을 이용해서 해보겠다. VScode는 모르겠는데 아마 똑같을 것이라고 생각되고, 인텔리제이도 똑같은 맥락으로 진행되는 것을 확인했다.
- 먼저 내가 작업할 폴더를 하나 만들어줘야한다. 이 폴더를 깃허브와 연결할 것이므로, 폴더를 임의로 바꾸거나 위치를 이동하면 아마 제대로 실행이 안될것이다. 나는 study-sm 이라는 폴더를 하나 만들었다.
- 그럼 이제 이 폴더를 IDE에서 open해준다. 폴더를 오픈해도 어차피 내부에 아무것도 없으므로 그냥 폴더만 open될뿐, 아무것도 들어있지 않다. 이곳에 clone해줄것이다. 이때 clone한다는 코드는 해당 IDE의 Terminal에서 쳐주는 것이다. cmd를 켜거나 다른 곳에서 하는 게 아니다.
- 이렇게 clone을 해주면 우리가 만들어준 repository의 내용들이 나의 작업 환경으로 복사된 것이다. 이때, branch들도 복사가 되는데, 이것은 "git branch -a"로 확인할 수 있다. 다만, 주의할 것은 우리가 clone한 주소는 study-sm이라는 주소이지, branch가 들어있는 파일의 주소가 아니므로 주소를 옮겨줘야 한다. 만약 clone한 곳에서 branch를 확인하려고 하면 오류가 뜨게 된다.
- 그래서 주소를 다음과 같이 이동한 후에 branch를 확인하면, 우리가 만든 branch들이 빨간 글씨로 잘 표시되는 것을 알 수 있다.
- branch까지 확인을 잘 했으니, 이제 나의 branch로 이동해서 작업을 진행해주면 된다. 이때는 "git checkout 브랜치명" 을 사용해주면 이동할 수 있다.
- 이렇게 브랜치를 이동하면 자동으로 소스파일들이 해당 브랜치 내의 소스파일들로 바뀌게 된다. 예를들어 내가 checkout하기 전에 main 브랜치에 있었고, main 브랜치에 1,2,3 이라는 파일이 있었다면 git checkout jeonkwanghwi를 해주면 1,2,3 파일은 없어지고 jeonkwanghwi 브랜치에 있는 파일들로 대체된다는 것이다. 예를 들면 아래와 같다. 먼저 main 브랜치로 이동하면 다음과 같이 보인다.
- 그러나 나의 브랜치로 이동하자, 내가 작업하던 폴더들이 나오는 것을 볼 수 있다. 이런식으로 IDE의 터미널로 브랜치들을 왔다갔다 할 수 있다. 그래서 다른 사람이 작업하는 코드를 굳이 github에 직접 들어가거나 따로 clone 또는 다운로드를 하지 않아도 간편하게 볼 수 있는 것이다.
- 이렇게 나의 브랜치에 도착을 했으면 여기서 작업을 해주고 add commit push를 해주면 끝이다. 만약 내가 브랜치를 제대로 옮겼는지 확인하고 싶다면 "git branch"를 쓰면 현재 내가 있는 브랜치가 나온다.
- add, commit, push는 우리가 작업하던 branch에서 하는건데, 작업이 다 완료되면 터미널에서 git add, git commit -m "커밋 메세지", git push 를 차례대로 치면 완료된다. 커밋 메세지 또한 팀원들과 협의해서 정하기도 하는데, 이곳에는 그냥 간단한 메세지를 남기면 된다. 만약 내가 DP 문제를 풀었다면 git commit -m "DP문제 풀이 완료" 이런식으로 쓰면 되고, 로그인 구현을 완료 했다면 git commit -m "로그인 구현 완료" 이런식으로 커밋 메세지를 남기면 된다. 그리고 push같은 경우, github에 연결되어 있지 않다면 우리가 따로 git push origin jeonkwanghwi 와 같이 뒤에 어디서 어디로 보내는지 설정을 해줘야하는데 우리는 애당초 clone을 할 때 깃허브와 연결을 한것이므로 git push 만 해줘도 나의 브랜치로 작업물이 올라간다. 이렇게 올라간 작업물은 우리가 만들어준 github repository에 가면 아래와 같이 확인할 수 있다.
- 저기서 Compare & pull request를 누르고 아래와 같이 간단한 메세지 작성 후 pull request를 올린다.
- 여기서 말하는 pull request는 풀어서 설명하면 "나의 브랜치에서 작업한 내용을 main 브랜치로 합쳐도 될까요??" 라는 것에 대한 요청이다. 이 요청을 허락해서 main에 합치는 것은 보통 개발리더(아마 팀에서 개발을 제일 잘하는 사람)를 맡은 사람이 검토하고 이상이 없으면 merge하고 이상이 있으면 merge를 보류하고 코멘트를 남긴다. 그리고 문제가 해결되면 merge한다. 이런 맥락에서 볼 때 pull request라는 말보다는 merge를 request한다는 의미가 좀 더 적합하다고 생각한다. 내 코드를 main에 merge하도록 요청하는 것이다.
- 이후 merge가 완료되면 main 브랜치에 최신 버전이 업로드 된 것이므로 이것을 각자가 pull 해줘야한다. pull을 한다는 것은 내 코드를 최신 버전으로 업데이트한다는 의미이다. pull은 그동안 했던 것과 마찬가지로 IDE 터미널에서 git pull을 써주기만 하면 최신 버전으로 업데이트가 된다.
- 그래서 순서를 정리하면 작업완료 후 add, commit, push 하고 깃허브 들어가서 pull request 작성, 리더가 보고 괜찮으면 merge, 궁금한게 있거나 잘못됐으면 pull request에 댓글을 남기고 잠시 보류할 수 있다. 그리고 문제가 해결되면 리더가 다시 merge하고, 그것을 팀원들 모두가 다시 pull(최신 버전으로 업데이트) 한다.
- 참고로, 브랜치에서 기능 구현이 완료되면 해당 브랜치는 삭제하고 새로 하나 파면 된다.
+추가) 브랜치를 지우고 새로운 브랜치를 만들었을 때 git pull만 해도 최신 버전으로 반영된다는 사람이 있고 아닌 사람이 있어서, 직접 업데이트 해주는 경우를 써본다.
기능 구현이 완료된 브랜치는 삭제하고 새로운 브랜치를 만들어야 하는데, 이 정보를 업데이트 해줘야한다. 그때 사용하는 것이 git remote prune origin(유효하지 않은 브랜치 지우기), git fetch -p(브랜치 최신으로 갱신) 이다.
- 먼저 git branch -a 로 현재 브랜치들을 살펴보자. 아래 사진은 인텔리제이에서 한건데, kakaoLogin과 comment+bugfix 기능은 구현이 완료돼서 브랜치를 지워야한다고 가정해보자.
kakaoLogin과 comment+bugfix는 기능구현이 완료가 되었는데도 아직 브랜치에 남아있는 것을 볼 수 있다. 이것을 지워줘야 한다. 지우는 것은 github에서 view all branches를 누르면 아래와 같이 브랜치들을 모두 볼 수 있고, 표시해놓은 부분에서 수정/삭제를 진행할 수 있다.
- 위 과정들로 깃허브에서 삭제를 진행했다면 그 내역을 한번 확인해보자. 브랜치의 상태를 보는 코드는 git remote show origin이다. 이렇게 입력하면 아래와 같이 새로 생긴 브랜치와, 지워진 브랜치들을 볼 수 있다.
위 사진을 보면 remote 저장소에 삭제돼서 더이상 유효하지 않은 브랜치임에도 로컬에서 계속 참조되고 있는 모습을 알 수 있다. 이것을 갱신해서 지워주자. ex. refs/remotes/origin/kakaoLogin
- git remote prune origin 이라고 명령어를 쳐주면 안쓰는 브랜치들을 잘라준다. 정확히는 remote branch의 유효하지 않은 참조를 지우는 명령어이다. prune라는 단어가 생소할 수 있는데, 기억하기 매우 쉽다. prune는 "가지를 잘라내다" 즉 가지를 친다는 의미의 단어이다. branch(나뭇가지)들을 prune(가지치기)한다는 의미이므로 명령어를 쉽게 기억할 수 있다. 이렇게 진행해주면 깃허브에서 우리가 직접 삭제한 브랜치들이 아래와 같이 pruned 됐다고 나온다.
- 그럼 깨끗하게 지워졌는지 git fetch -p로 확인해보자. 이 명령어로 로컬 저장소를 최신 버전으로 갱신한다. 그 말은 깃허브에서 우리가 만든 새로운 브랜치도 생긴다는 말이다. 아래와 같이 profileEdit 등의 새로운 브랜치들이 생겨난 모습을 볼 수 있다.
깃허브는 사용할 때마다 새로웠던 분야인데 이제 좀 적응해나가는 것 같다. 아래는 참고자료로 깃 저장구조를 첨부한다.
'CS 개념 > Github' 카테고리의 다른 글
| warning: LF will be replaced by CRLF (1) | 2024.01.23 |
|---|---|
| 프로젝트를 github에 연결하기 (왕초보) (0) | 2024.01.18 |
