[Github 특강] Github 이용해서 협업 과정 + 팁(dev)

브랜치(== 복사본):

보통 기능 추가 코드 짤 때 브랜치 만들어 사용

• git branch 브랜치이름

 

• 브랜치 이동 명령어
  • git switch 브랜치이름

 

git switch 로 브랜치 이동

 

예전에는  브랜치 이동할 때 checkout 썼음...

• git checkout 브랜치 이름

git checkout 으로 브랜치 이동

 

브랜치 생성과 동시에 이동 가능

 

여기서 login 브랜치가 최신인데 main으로 합치는 이유:

협업 시 여러 사람들이 코드를 한곳에 합쳐야되기 떄문에....

 

<합칠 때>

최종 브랜치로 이동을 하고

• git merge 브랜치명 (위 예시에서는 git merge login)

 

근데 보통 github 에서 합치는 게 더욱 선호됨 : 터미널에서 직접 커밋하고 병합하는 것보다 협업과 코드 품질 관리를 체계적으로 할 수 있기 때문

 

 

• 코드 리뷰: PR을 통해 팀원들이 코드 변경 사항을 검토하고 피드백을 줄 수 있습니다. 터미널에서는 이런 코드 리뷰 과정이 없으므로 코드 품질을 보장하기 어렵습니다.
• 협업 관리: PR을 통해 누구의 코드가 어떤 변경 사항을 포함하고 있는지 명확히 관리할 수 있습니다. GitHub에서는 PR에 대한 논의, 리뷰, 변경 기록이 남아 있어 추적이 용이합니다.
• 자동화 도구와 통합: PR을 사용하는 경우 GitHub Actions와 같은 CI/CD 도구를 자동으로 실행할 수 있습니다. 이로 인해 코드를 병합하기 전에 테스트, 빌드 검증이 자동으로 수행됩니다.
• 브랜치 보호: GitHub에서 PR을 사용하면, 특정 조건을 충족해야만 merge가 가능한 브랜치 보호 정책을 설정할 수 있습니다. 예를 들어, 코드 리뷰가 완료된 후에만 병합을 허용하거나, 모든 테스트가 통과해야만 병합할 수 있습니다.
• 히스토리 관리: PR은 코드 변경 히스토리를 명확하게 남길 수 있어, 나중에 문제가 발생했을 때 특정 변경 사항을 쉽게 추적할 수 있습니다.

 

 

pull request란? 코드 합치는 것을 요청하는 거

• github에 올리기 하고나서...
  • git push origin 브랜치명

pull reuqest 버튼이 뜨고, 그 버튼 누르면 위 화면이 뜸. 기능 브랜치(내가 push 한 브랜치)에서 최종 브랜치(보통 main 아니면 dev)로 합쳐짐.

 

 

코드 리뷰: 바뀐 코드를 볼 수 있음, merge pull request 버튼으로 merge 가능

<브랜치를 로컬 환경으로 가져오고 싶을때>

• git pull origin 브랜치명

---

Main 브랜치 === 배포용

 

그래서 브랜치에서 수정한 혹은 생성한 코드들을 바로 main에 push 하면 문제가 생김!!

 

문제점:

 

1) 완벽하게 기능 개발해야 merge가 가능

회원가입, 로그인, 로그아웃 만드는게 걸리는 시간이 오래걸리면: 결국 main에 합치기까지 다 만드는 데 시간이 오래걸림, 그리고 한번에 위 기능을 다 합친 코드를 실행해서 생긴 오류를 해결하는 것이 너무 비효율적임. 보통 만들어진 모든 기능이 다 들어간 많은 양의 코드를 실행헀을 때 오류가 생기면 오류 찾기 어려움. 작은 단위로 계속 합쳐서 테스트해야 빠르게 오류 찾기 쉬움.

 

 

헤결법: 개발용 브렌치를 하나 더 만들기

develop 브랜치를 만들어서, develop을 잠시 main 대신 default로 두고 여기서 온갖 테스트(실험)을 해서 그때 그때 오류 및 충돌 문제 해결한 후 최종적으로 다 만들어지면, 배포용인 main 브랜치에 코드 넣는 방식!!!

 

문제:

2) 충돌이나 오류가 있는데도 main에 push 했을 경우 이를 모르고 다른 팀원들이 그 코드를 가져와서 뒷 작업을 하면, 나중에 오류 찾고 해결하는데 시간이 많이 소비될 수 있음.

 

같은 변수명을 썼는데 이를 main에 무작정 넣으면 문제 생김. 고치고 넣어야함!!

 

해결: dev 브랜치 만들어서 그 dev에 기능 하나씩 추가될 때마다 코드 merge하고, 충돌이나 다른 오류들 수정하기

dev(팀원들과 내가 볼수 있는 최신 버전의 코드와 다름 없음)를 먼저 가져와서 내 로컬에서 내가 만든 코드와 합치고 충돌이나 오류 해결 후 dev에 다시 push!!!

---

<github 협업 과정 총정리>

팀장은 먼저 git init으로 깃 시작한 후 초기 코드 작성된 것을 생성한 github 레포지토리에 push

 

 

그리고 배포되기 전 다양한 오류와 충돌 문제 해결을 위한 dev 브랜치를 만들고, github에도 그 생성된 브랜치를 반영함.

main은 배포용임으로 그 전에 안전하게 테스트할 dev를 github에서 defult 로 설정함

 

 

default로 잘 설정되었는지 확인!!

 

github세팅이 끝났으니 팀원들 add people해서 초대함

 

팀원들은 github 팀 레포지토리 url로 개인의 로컬 코딩 환경에 clone함

팀원들은 이제 로컬 환경에서 이미 작성된 코드를 가져와 수정할 수 있게됨.

 

--> 여기까지 팀장 , 팀원이 기능 코드 추가 전 할 일 끝

 

---

복사본 만들어서 코드 만들기

 

팀원이라면, 본인이 작업해야할 기능 개발 내용에 맞춰 브랜치명을 생각한 후 브랜치 만들고, 그 브랜치로 이동함.

 

기능 브랜치 생성 후 코드 짠 후 팀 레포지토리에 push함.

 

- 팀원들은 git init 할 필요없이 clone으로 가져와서 브랜치 만들고 수정하면 됨.

 

- 수정 후 push 하면 git pull request가 github에 뜸  --> 그럼 이제 github에서 merge하면됨

pull request 누르면 위 화면 처럼 merge하기 위해 create pull reuqest 버튼이 뜸. 이때 어떤 브랜치를 어디로 합칠건지 확인하기!!!!!!!!!!

 

이런 화면이 뜨면 merge 가능이지만,

 

충돌(같은 줄 다른 코드 있을 떄) 일어나면 위 이미지처럼 pull request 안됨.

 

- 이런 경우 로컬환경에서 충돌 문제가 일어난 파일을 pull을 해서 충돌을 해결한 후 push 하면 됨.

 

코드 리뷰 체크하기 위함. (코드 짠 후 팀원한테 이대로 merge해도 되는지 체크하기 위함.)

 

+ 버튼 눌러서 코멘트 달기(이 코드는 좋네요! 이거 문제있어요 바꾸세요 ~~이런거... )

comment: 이부분 조금 아쉬워용// approve: 좋아 승인 // request changes: 코드 아예 바꾸세여~~~

 

- 바꾸면 files changed에서 리뷰확인 가능..

 

위에서 말했듯이,

merge pull request 버튼은 충돌 문제에 의해 비활성화될 수도 있음. 이 경우, 내 로컬에서 충돌해결한 후 push 해야함.

 

git pull origin dev로 충돌된 코드 확인하기

충돌난 코드를 다 가져와서 쓰면 안되기 때문에, 합치기 전 내 로컬에서 충돌 해결해야함.

 

 

충돌 해결후 혹은 수정 끝난 후, github에 push 후 github에서 merge버튼으로 브랜치 합병하기

 

 

 

참고로, 

- origin dev는 깃허브에 있는 dev 를 가리키고, (팀원들과 내가 push한 코드 결과물이 있는 github 레포지토리에 있는 브랜치)

- vs코드 상에서 터미널에 있는 dev는 로컬 dev임.(결과물을 가져와서 내가 다시 수정 혹은 코드 추가하려는 브랜치 환경)

---

<그림으로 보는 git hub 협업>

즉, 깃허브에 생성되는 브랜치는 총 크게 3가지 종류: main(배포용), ,dev(테스트용), 기능 브랜치(각 팀원들이 기능 개발을 위해 만들 브랜치들...)

 

 

팀장이 위의 브랜치를 github에서 세팅하고 dev 브랜치를 default로 설정함. 이후, 팀원들을 초대하면, 팀원들은 clone으로 해당 레포지토리 코드를 가져옴. dev 브랜치에서 작업 시작!

 

각 팀원들은 dev 브래치에서 각각 담당할 기능 개발을 위한 브랜치를 생성해서 그 브랜치에서 작업.

작업 완성된 기능 브랜치를 팀 깃허브 레포지토리에 push함.

팀장 혹은 다른 팀원들이 push 된 해당 기능 브랜치를 리뷰하고, dev에 추가해도 되겠다~하면(승인), 깃허브에서 그 기능 브랜치를 dev 로 merge함. 이 때 충돌이 일어난다면,

 

해당 기능 브랜치를 작업했던 팀원이 dev 브랜치를 가져와서 본인이 작성한 코드와의 충돌을 해결 후 다시 push! (순서는 바뀌어도 됨: 애초에 dev를 pull 하고 충돌 해결후 리뷰 요청을 해도 됨.)

 

dev에서 모든 기능들이 잘 작동되고, 최종적으로 코드 작업과 테스트가 성공적으로 완료 되면, 배포를 위해 main으로 dev를 최종 합치기

 

 

 

github 으로 협업하는 과정을 다시 정리해서 좋았다. 특히, 튜터님들이 직접 회사에서 협업하면서 얻은 꿀팁인 dev 브랜치를 default로 두고 작업하는 과정을 자세히 알게 되어서 참 좋았다. 

 

첫번째 팀과제 때 깃헙 관련 이슈(충돌)로 시간을 많이 소비했었는데, 다다음주 팀원들과 협업할 때는 배운 위의 지식들을 바탕으로 github을 잘 사용하고, 더욱 복잡한 프로젝트도 소화해내고 싶다.