많은 개발자들이 Github를 사용합니다. 저도 대학교 때 '멋쟁이 사자 처럼' 이라는 웹 개발 동아리에서 나름 작업하면서 Github를 엄청 자주 접했고 사용하는 것에 익숙 했습니다.
특히, "개발자는 간지가 생명이다" 라는 마인드로 git 을 늘 CLI로 다루었기에 git 명령어나 bash에서 git을 보는 것 또한 익숙한 상태였습니다.
그렇게 자만하고 있을 와중에 오늘 패스트캠퍼스 AI LAB 부트 캠프에서 협업을 위한 Git 사용법을 배웠습니다.
다른 말 필요 없이 "혁명" 그 자체 였습니다. 제가 사용한 것은 진짜 대학교 조별 과제 수준 이었습니다.
오늘 드디어 현업의 깃헙 사용법을 배운 어마무시한 감동을 주는 수업을 들었습니다.
그렇기 때문에 오늘이 지나기 전에 사용법에 대해 정리해 보겠습니다.
0. Git branch 전략
저도 소프트웨어 학과를 전공해서 "소프트웨어 개발론" 일명 "소개론"을 배운 사람입니다. 그렇기에 Git branch 전략은 들어는 보았습니다. 아마 전공자들은 아래 사진 보면 바로 아실 겁니다.
위 사진은 Git Flow 전략이라고 합니다.
이에대한 자세한 설명은 생략 하도록 하겠습니다.
왜냐면 오늘의 주인공은 Git Flow가 아닌 Github Flow 전략이기 때문입니다.
위 그림이 Github Flow 전략입니다.
둘의 차이를 설명하자면
| Github Flow | Git Flow | |
| 복잡도 | 간단 | 더럽게 복잡해 |
| 버전 관리 | 버전은 딱히 ... | 명확한 버전이 있음 |
| 팀 규모 | 소 | 대 |
즉, 빠르고 작은 프로젝트에서는 Github Flow를 사용하고
버전관리가 빡세고 코드를 엄격한 관리가 필요한 프로젝트에서는 Git Flow를 사용합니다.
그림만 봐도 Github Flow가 쉬워 보이잖아요 ㅎㅎ
오늘은 Github Flow를 Github에서 사용하는 방법을 예시 프로젝트와 함께 정리하고자 합니다.
전체적인 순서
1. organization Repository 만들기
2. Issue template 설정하기
3. .gitignore, README.md 파일 넣기
4. fork 해서 자기 repository와 local로 가져오기
5. issue 사용해서 해야할 일 정리하기
6. 새로운 브랜치 파기
7. 코드 작업 후 add -> commit -> push 하기
8. organization repository로 자신의 작업물 올리기
9. Code Review & 수정
10. approve 난 code Merge
11. pull 받기
12. 브랜치 지우고 5 ~ 12 과정 반복
1. Organization Repository 만들기
설마 팀장 맡은 친구의 github repository 에서 작업하는 건 아니지??
사실 저는 이때까지 팀장 맡은 사람이 Repo 만들어서 협업을 했습니다.
그러나!!!!
Organization Repo 기능을 아십니까?
모르시면 바로 보시죠!!
ps. 해당 작업은 팀에서 팀장 1명만 하셔야 합니다!!!
깃 허브 보면 오른쪽 위(그림 속 빨간 동그라미)에 +를 눌러보세요!!
여기서 New organization 클릭!!
가난뱅이인 우리는 당연히 Free 버전으로 클릭!
동그라미 친 부분 작성합니다.
organization name은 기업 이름으로 중복 허용이 안되요!!
다른 사람이 이미 쓰고 있는 이름이 안되요...ㅜㅜ
이름짓기 역경을 끝내고 나면 다음 페이지가 보이는데 빨간동그라미 부분에 팀원의 이메일 주소를 넣어주세요!! 나중에도 추가 할 수 있어서 skip하셔도 큰일은 안납니다.
이러면 기업 Github를 만든 것입니다!!!!
그러고 이제 개인 Repo 만드는 과정과 같습니다.
상위 탭에서 Repositories를 클릭하고 New repositiory 버튼 클릭하면
이런식으로 나옵니다.
이때 Repo 이름쓰고 public으로 바꿔주는게 좋아요!!
저는 여기에 license를 MIT로 넣긴 하는데 이건 개인 취향이에요.
여기까지 하면 Team Repo가 완성됩니다!!!
2. Issue Template 설정하기
Issue는 각 팀원들이 무슨일을 하는지 적어두는 공간 입니다.
팀원들간의 소통하기도 좋고, 특히 내가 무슨 일을 해야하는 정리되어 있어서 작업에 있어 뇌정지를 예방 할 수 있습니다.
Issue는 일반 md 파일이기 형식 없이 자유롭게 적을 수 있습니다.
그러나 너무 자유롭게 적다보면 어떤 팀원은 할일을 맨 밑에 적어두고 어떤 팀원은 자기 할 일을 맨위에 적어서 Issue를 볼 때마다 어디에 내용이 적혀 있는지 찾아야 하는 수고를 해야합니다.
그렇기 때문에 사용하는 것이 Issue Template입니다.
특정 template로 고정하고 사용하는 것 입니다.
이번 수업에서는 가장 간단한 형태의 Template를 생성했습니다.
Settings 탭에 가서 아래로 내리면 Issue부분에 Set up templates 라고 있습니다.
해당 부분에서 간단한 template를 마크다운 형식으로 만들어 주시면 팀원들이 요기나게 사용 할 것입니다.
가장 하찮은 형태의 Issu Template는 다음과 같습니다.
## Description
한 줄로 추가할 기능 설명
디테일 하게 다시 설명 ( 사진 영상 등 자유롭게 추가 가능)
## Tasks
- [ ] to do thing 1
- [ ] to do thing 2
- [ ] to do thing 3
## References
- [Link text] (Link addr)
팀원들은 이제 template 바탕으로 자신이 해야 할일을 적으면 됩니다!!
3. .gitignore, README.md 파일 넣기
팀원들이 fork를 하기 전에 .gitignore 파일과 README.md 파일을 적어야 한다.
https://www.toptal.com/developers/gitignore
gitignore.io
Create useful .gitignore files for your project
www.toptal.com
위 사이트를 이용하면 쉽게 gitignore를 작성 할 수 있다.
4. fork 해서 자기 repository와 local로 가져오기
이제 팀원들이 작업하기 위해서 팀원들이 organization repo 에 있는 파일을 가져오는 작업이 필요하다.
이를 설명하기 전에 작업 전체의 과정을 보자
노란색 = 자신의 컴퓨터 / 파란색 = 자신의 github repo / 검정색 = organization repo를 의미한다.
지금까지는 검정색만 만든 상태로고 보면 된다.
먼저 fork를 통해 organization repo에 있는 것을 자신의 github로 가져오는 것을 해보자.
만든 organization repo에서 fork를 누르면 자기 자신 github로 가져올 수 있습니다.
이제 fork로 만들어진 자신의 repo에서 clone 작업을 진행 하는 것이다!!!
꼭 team repo가 아닌 자신이 fork 받아서 생성된 자신의 repo의 주소를 복사해서 clone 하자.
clone은 많이 해본사람들은 알거지만 빠르게 정리하자면
1. Github URL 복사
2. 터미널 이용해서 원하는 파일 위치로 ㄱㄱ
3. git clone [복사한 url]
하면 local에도 해당 파일들을 가지고 올 수 있다.
5. issue 사용해서 해야할 일 정리하기
위에서 팀장이 정성스럽게 만든 issue template를 이용해서 팀원은 자신의 할일을 적으면 된다.
클릭해서 들어오면 팀장이 고이 만들어둔 template 대로 세팅이 되어 있음을 볼 수 있다.
이를 활용해서 그냥 적으면 된다.
Tasks 부분은 작업이 진행 함에 따라서 check 해주면 좋습니다.
이를 통해 팀원들이 어디까지 진행 됐는지 파악 할 수 있습니다.
해당 Issue가 끝이 나면 클릭을 Issue를 닫을 수 도 있습니다.
또한 commit message에 `resolve #[issue id]` 라고 적어준다면
해당 commit이 github에 올라 가는 순간 issue id가 동일한 issue는 자동으로 닫힙니다.
6. 새로운 브랜치 파기
자신의 일을 시작하기 전에 브랜치를 만들어서 브랜치에서 작업을 한다.
브랜치를 만드는 git 명령어는 다음과 같다.
git branch [새 브랜치 명]
git checkout -b [새 브랜치 명]
git switch -c [새 브랜치 명]첫 번째 명령어는 새 브랜치만 만들고 나머지 두 줄은 만듬과 동시에 해당 브랜치로 위치를 옮긴다.
따라서 첫 번째 명령어로 브랜치를 만든 후에는 checkout이나 switch를 사용해서 브랜치 위치를 옮겨야 한다.
지금 현재 브랜치 위치를 알기 위해서는 'git branch' 명령어를 실행 해 주면 된다.
참고로 checkout은 이제 옛날 명령어 이고 siwtch가 새롭게 업데이트 된 명령어 이다.
checkout은 브랜치를 옮기는 기능도 있고 이전으로 commit을 되돌리는 기능도 있어서 기능 분리가 필요하다는 얘기가 계속 논의 되었었다.
git에서는 해당의견에 따라 branch를 옮기는 명령어는 switch를 사용하기로 해서 새롭게 명령어를 만들었다.
(commit 되돌리는 명령어는 뭐 있었는데 기억이가 나질 않습니다 판사님...)
7. 코드 작업 후 add -> commit -> push 하기
이제 자신이 issue에 적인일을 코딩하면 된다.
자기가 맡은 부분을 다 하면
이제 add 와 commit을 하면 된다.
add와 commit은 다음과 같은 명령어로 할 수 있다.
git add [파일명]
git add .
git commit -m "commit message"
git commit이때 팀프로젝트에서는 add와 commit을 작업 단위로 나눠서 올리는 것이 중요하다.
만약 README.md도 수정하고 main.py도 수정 했다면
add . 을 이용해서 모든 것을 올리기 보다 add [파일명] 을 통해 하나씩 add 하자.
그래야 commit message를 쓸때 무슨 작업을 했는지 쉽게 적을 수 있다.
또한 개인 프로젝트만 하는 경우 commit message를 대충 쓰는 습관이 있을 텐데
팀 프로젝트의 경우에서는 다른 사람들이 commit message를 보고 무슨 작업을 했는지 알 수 있게
commit convention에 맞춰 쓰는 노력을 하자!!
https://velog.io/@archivvonjang/Git-Commit-Message-Convention
[Git] Commit Message Convention
Git을 협업에 알맞게, 커뮤니케이션에 유용하게, 깔끔한 가독성을 가지도록 사용하기 위해서 좋은 커밋 세미지를 사용하는 것이 중요하다. 그러기 위해서 커밋 컨벤션을 정리하였다.
velog.io
이렇게 꼼꼼히 commit을 끝낸 후 push를 자신의 repo에 하자!!
바로 팀 repo에 하면 절대 아니되오!!!
git push -u origin [새 브랜치 명]
8. organization repository로 자신의 작업물 올리기
push까지 완료하면 자신의 local에서 자신의 github repo로 작업물을 올린 것 까지 완료한 것이다.
이제는 자신의 작업물을 organization repo로 옮기는 과정이다.
자신의 repo github에 다음과 같이 새로운 브랜치가 나타났음을 아려 줄 것이다.
compare & pull request 클릭
만약 위 모습이 보이지 않는 다면 pull requests 탭으로 이동해서 new pull request 버튼을 클릭하면 된다.
그러면 위 사진과 같이 볼 수 있을 것이다.
이때 왼쪽은 organization repo에 있는 branch가 보일 것이고
오른쪽은 자신의 branch가 있어야 한다.
이 둘을 비교해서 Merge 가능 여부를 github가 알아서 판단한다.
그림은 다행히 Create pull request를 할 수 가 있다.
사실상 main에 바로 올리면 안되지만 ... 이번만큼은 올릴게요...
confilic가 나지 않으면 다음과 같이 깔끔한 모습을 볼 수 있을 것이다.
여기서 Merge pull request => Confirm merge를
누르면 된다.
이것을 한다고 해도 바로 main에 Merge가 되는 것은 아니다.
찐으로 Merge 가 되려면 팀장의 승인이 필요하다.
9. Code Review & 수정
위 작업을 끝나고 organization repo에 pull requests 창을 가면 자신이 보낸 요청을 확인 할 수 있다.
지금 부터는 팀장 권한이 있는 사람만이 할 수 있다.
해당 요청에 들어간 후 Files changed에 가면 해당 요청이 어떤 코드 작업을 했는지 확인 할 수 있다.
팀장은 코드를 읽으면서 code review가 시작된다...
마음에 안드는 부분이 있으면 해당 줄에 +버튼을 누르면
요청 사항을 적을 수 있다.
오른쪽 위 Review changes를 누르면
코드에대한 전체적인 평가를 적을 수가 있다.
이후 팀장은 3가지 선택을 할 수가 있다.
1. Comment
: 단순한 의견이 있어 적어 두었다.
2. Approve
: 너무 잘했다! Merge해 두겠다.
3. Request changes
: 수정이 필요한 부분들 언급해 놓았으니 이것들 수정하기 전까지 통과할 수가 없다.
3가지 중 상황에 따라 선택 한후 submit review를 누르면
팀원은 pull request에 있는 자신의 요청에 들어가면 확인 할 수 있다.
팀원은 이를 확인하고 팀장님이 만족 하실 때 까지 수정하고
add -> commit -> push 과정을 반복 하면 된다.
이때!!! pull request 과정을 해 줄 필요 없다.
왜냐하면 팀장님이 approve 하기 전까지 해당 request가 살아 있기 때문에 자동으로 pull request가 된다.
10. approve 하고 code Merge하기
팀장은 팀원이 한 코드를 리뷰후 만족한다면 approve하고 merge를 해줘야한다.
이 권한는 팀장만 할 수 있으므로 팀원은 해당기능이 막혀있다.
위 사진과 같은 과정으로 approve를 할 수있다.
approve를 한뒤 resolve conversation -> Merge pull request -> Confirm merge
를 하면 최종 팀원 코드를 Merge 하는 것이다.
11. pull 받기
다음 과정으로 터미널에서 코드를 실행하면 organization repository에 있는 수정된 코드를 받을 수 있다.
git remote add upstream [organization github http]
git fetch upstream main // FETCH_HEAD라는 파일이 생성됨
git merge FETCH_HEAD // CONFLICT 발생시 수동 해결후 다시 add -> commit -> push
git fetch -> merge 가 아닌 git pull upstream main 으로 받을 수도 있다.
git pull을 사용하는 경우 auto merge 를 하기 때문에 Conflict가 있다면 실행 되지 않는다.
하지만 위 방법으로 merge를 하면 conflict가 있으면 고치라고 알려준다.
conflicict는 수정하여 다시 팀장한테 요청을 보내면 된다.
12. 브랜치 지우고 5 ~ 12 과정 반복
드디어 마지막 브랜치 지우기이다!!!
작성이 완료된 브랜치는 과감없이 지우고 새로운 브랜치로 시작하자.
git branch -d [브랜치 명]
이러면 local의 브랜치는 지워지고
자신의 git repo는 아래 과정으로 삭제 하면 된다.
이러면 github내에서도 branch가 지워진다...
다음과 과정을 동영상으로 보고 싶은 사람을 위해 링크를 남겨 두겠습니다.
https://youtu.be/g3GEnjppUV0?si=JAsbDYkyMXm1BF51