📆 22.10.05 - git & git flow 부셔버리기

협업에 있어서 개발자는 Github를 빼놓을 수가 없다..
오늘은 간략하게 라도 git flow 협업방식에 대해서 기술해보려고 한다.

git flow?

협업에서 A라는 사람과 B라는 사람이 기능별로 역할을 나누었다. 그렇다면 그 사람들이 같은 branch에서 작업을 하게 되면 어떻게 될까? 다른 기능을 맡게되어 겹치는 부분이 적다해도, 계속해서 기능들을 나누어 같은 공간에서 작업을 하면, PR 후에 수많은 conflict를 마주하게 되고, 또한 계속 같은 부분을 만지게 되어 어느 순간 pull을 땡겼을 때, 내가 열심히 만든 부분이 덮여씌여질 수도 있다.

그런 불상사를 방지하려면 github 브랜치를 적극 활용해야 한다!

github 내에서 branch를 이용 / 운영하는 브랜치 전략을 git flow라고 부른다
이 브랜치는 크게 master, develop, feature, release, hotfix를 기본 모델로 잡고하면 편하다. (현업에서도 이런 git flow 브랜치 명을 자주 이용한다고 함!)

위의 5개의 브랜치를 이름을 저렇게 정하게 된 이유는 해당 브랜치에서 맡게되는 기능을 알게되면 이해가 쉬울 것이다.

• master : 정식으로 배포되는 코드들을 관리하는 최종 브랜치. Github Action 등으로 CI / CD가 잘 되어있는 곳에 master 브랜치를 deploy branch로 걸어두면 master에 변경점이 있을 때마다, 그 변경점을 배포 사이트에 적용을 할 수 있게 된다. => (netlify, vercel 도 사용해보세요)
  일일이 정적으로 npm run build build 파일들을 계속 변경 될 때마다 배포 사이트에 적용시켜주는 귀찮음을 해결해줄 수 있다..!
  단, 이 브랜치는 정말 배포 만을 위한 브랜치이므로, 팀원들끼리 서로 만든 기능을 합쳐서 그 부분에서 잘못된 부분을 미리 찾고 완성본을 해당 브랜치에 반영을 해야된다. 만약에 뭔가 문제가 있는 코드가 master로 넘어오게된다면, 바로 배포에 적용이 되어 유저들이 흰색 화면을 보게 될 수도 있다.

• develop : 위의 문제사항이 발생하기 전에 미리 모든 개발 관련 코드들을 한번 합쳐봐서 검토까지 하는 브랜치를 develop이라고 한다. 여기서 각자 나눈 기능을 합쳐보고 client server에서 잘 구현이 된다면 master branch PR을 하게 되면 깔끔하게 배포서버에 문제 없이 반영이 될 것이다.

• feature : 해당 브랜치는 말 그대로 기능, 기능 브랜치이다.
  팀원들이 각자의 기능을 나눈 부분을 feature라는 이름의 브랜치로 나눠서 개발을 진행하게 된다.
  다른 분들은 어떻게 해당 브랜치가 이러한 기능을 하는 브랜치이다..! 라고 정의하는지는 잘 모르겠다. 내 생각은 이 개발이라는게 서비스를 만드는 사람들끼리의 약속만 잘 정의가 된다면 상관이 없다고 생각하는 케이스이다.
  나는 feature/login (로그인 파트), feature/mainpage (메인페이지) 등으로 사용을 하고 있다.
  ( 더 좋은 방법이 있으시면 댓글로 알려주세요! 서로 좋은 정보 공유해가면서 개발합시다 )

• release : 성능 개선 그리고 버그 수정을 위한 브랜치이다. 구글링을 해보니 이렇게 정의가 되어있어서 기술을 해본다. 그런데 나는 해당 기능이 있는 feature 브랜치에서 처리를 해도 괜찮다고 생각을 하기 사용을 해본 적이 없다.. (이것도 의견 등을 받고싶습니다!)

• hotfix : 급하게 긴급 패치 작업을 해야되는 브랜치로 변경점은 develop으로 거치지 말고 바로 master로 PR을 하여 빠르게 반영을 할 수 있는 기능을 목표로 한다.

git flow에 많이 사용되는 git 명령어

처음에 브랜치를 만들어야지 시작을 할 수 있다. 보통 처음 프로젝트를 열면 main이라는 브랜치가 보일 것이다. 이때 내가 브랜치를 만들고 해당 브랜치로 바로 넘어가고싶다!
이럴때 쓰는 명령어가 바로 git checkout -b 브랜치명

이 명령어를 사용하게 되면 바로 해당 브랜치로 넘어가져서 작업이 가능하므로 정말 유용하다고 생각한다. 실제로 주변 동료들도 내가 알려준 이후로 버릇처럼 사용하고 있는 명령어이다. (좀 뿌듯합니다 ㅎ)

그리고 이렇게 만든 브랜치는 내 local branch (내 컴퓨터에서 만들어진 branch) 이지 remote branch (github에 연동된 브랜치) 가 아니라서 연동을 시켜줘야한다.

먼저 git branch 명령어로 내 로컬환경의 브랜치를 볼 수가 있으며, git branch -r로 remote 환경, 즉 github의 브랜치를 볼 수가 있다.

만약 내가 방금 만든 브랜치가 없다면 push를 하게 되면 바로 remote 환경에 브랜치를 생성할 수 있다.

또 다른 팁으로 만약에 다른 팀원이 만든 브랜치를 내가 기능을 추가해야되는 일이 생겼다..!
근데 내가 만든 브랜치가 아니라서 접근이 어려워..
이럴 때는 해당 remote 에 있는 기능 브랜치 이름을 똑같이해서 내 local 브랜치에 생성해주고 이후 push를 하면 commit 이 바로 연동이 됩니다

이제 remote 환경에서 반영하는 순서를 작성해보려고 한다.
git init (새로 생성된 파일등을 등록) -> git add . (내가 작업을 하여 변경된 파일을 git에 올리기 위해 추가) 만약 무슨 파일들이 추가되었는지 확인하려면 git status로 확인 -> git commit -m "커밋이름" (commit 만들기) -> git push origin 브랜치 명 (git에 등재)

그런데 push 과정에서 오류가 발생할 때도 있다. 그때 터미널을 자세히 들여다 보면 git pull...이라는 글귀가 보이면 해당 브랜치에 변경점이 있으니 pull 받아서 확인하고 그 합본을 다시 push 해라 라는 뜻이다.
그렇다면 git pull origin 브랜치 명으로 받아와서 확인 후 다시 push 해주면 정상적으로 올라간다.

여기까지가 기본적인 브랜치에서 commit 변경 점을 적용하는 방법이다.

git flow 의 장점

• 사용이 간편해저 쉽게 접근 가능
• branch 관리가 훠~~얼씬 클-린해진다
• 버전 관리가 쉬워짐
• 배포 및 수정이 간편해져 빠르고 쉽게 배포가 가능