Git & Github로 협업하는 법
브랜치 활용하기 (Terminal)
수정은 하고 싶은데 원래 파일은 그대로 두고 싶은 경우.
복사본 == 브랜치 (Branch)
- git branch branchName
- 하지만 변화가 없다.
- git branch
- 현재 브랜치의 종류가 나온다.
- 현재 branch와 master 두개가 있다.
git switch branchName / git checkout branchName (branchName명 변경)
- Branch 한번에 생성 및 이동
- git switch -c branchName
- git checkout -b branchName
- Branch 한번에 생성 및 이동
- 브랜치 병합
- git switch branchName (메인 브랜치)
- ex) git switch main
- git merge branchName (합칠 브랜치명)
- ex) git merge login
- git switch branchName (메인 브랜치)
A라는 branch에서 코드를 작성하고있었다. 이때 main branch로 돌아가면 코드는 어떻게 될까?
내가 작성한 코드는 없다.
Github에서 합치기 (Pull Request 활용)
우선 pull request는 pull(merge)와 request의 합친 말이다.
터미널에서 git merge를 통해 합치는경우는 거의 없다.
보통은 github에서 합친다.
코드 변경사항을 알 수 있고, 코드리뷰도 가능하기 때문.
Sequence는 다음과 같다.
브랜치 생성 및 이동
코드 수정 및 저장
코드 업로드 및 pull request생성
깃헙에서 merge
로컬에 반영 (git pull origin ~)
협업시 문제점 및 해결책
- 완벽하게 기능 개발해야 merge 가능
- Main Branch = 배포용
- 해결책 (개발용 브랜치 생성)
- main : 배포용
- develop : 테스트용
- feature : 기능 개발용
- 해결책 (개발용 브랜치 생성)
- Main Branch = 배포용
- 그냥 합치면 위험하다
- 팀원들이 이름이 같은 변수를 만들수도 있다.
- 해결책
- 로컬에서 먼저 테스트
- 해결책
- 팀원들이 이름이 같은 변수를 만들수도 있다.
실전 가이드
- 초기 세팅
- 팀장 : 초기 코드 작성 및 github 업로드
- 폴더 생성
- 간단한 코드 작성
- 레포지토리 등록 및 기타 작업 init, add, commit, push
- 팀장 : 초기 코드 작성 및 github 업로드
- 팀장 : dev(develop) 즉 개발용 브랜치 생성
- git switch -c dev
- local에서 dev branch 생성
- git push origin dev
- github에 반영
- git switch -c dev
팀장 : github에서 dev branch를 default 로 설정
팀장 : 팀원추가
팀원 : git clone
- 기능 개발 시작
- git switch -c featureBranchName
- 코드 작성
- git add, commit, push
pull request 생성
코드 작성자 : 리뷰요청
코드 리뷰어 : 코드리뷰
- 합치기 전 내 로컬에서 충돌 해결 및 테스트
- 기능 브랜치에서 git pull origin dev
실제로 사용해보기.
현재 메인으로 사용중인 맥북프로와, 서브로 사용중인 맥미니 이렇게 두대로 해보려고 한다.
맥북프로 : 팀장역할
맥미니 : 팀원역할
이렇게 나누어 진행하였다.
우선 repository를 하나 만들고, Directory도 하나 만들어 주었다.
1. 프로젝트 생성 후 repository에 올리기. (팀장)
이렇게 xcode프로젝트를 하나 생성하고 올렸다.
2. 개발용 브랜치 생성. (팀장)
- git switch -c dev
- git push origin dev
이렇게 dev가 branch에 생겼다.
하지만 default는 아니다.
3. dev branch 를 default로 변경. (팀장)
해당 repository에 들어가서 상단의 settings를 누른다.
그리고 Default branch에서 다음과 같이 해준다
이제 dev branch가 default branch가 되었다.
4. 팀원 추가
collaboratos에서 추가해주자.
테스트용 부계정이 이렇게 추가가 되었다.
테스트용도 일부러 윈도우대신 맥환경에서 진행하였다.
5. git clone (팀원)
일단 프로젝트용 디렉토리를 하나 만들어 주고 그곳에 클론을 하였다.
클론을 해주니 자동으로 dev branch가 main으로 되어있다.
기능 별 브랜치를 만들어 주자.
이제 코드를 작성을 해보도록 하자.
간단하게 코드를 작성하고 push 를 해주었다.
아무래도 계정을 만들고 바로 테스트를 하다보니 username과 password를 입력하라고 나왔는데 그건 패스하자.
6. pull request 생성 (코드 작성자)
그리고 github사이트로 들어가보자.
다음과 같이 Pull request가 뜬걸 알수있다. (팀원)
하지만 팀장의 화면엔?
고요하다.
우선 pull request를 해보도록 하자.
다음과 같이 작성 하였고 생성 하였다.
이렇게 Pull Request가 끝났다.
7. 리뷰 요청하기 (코드 작성자)
우측을 보면 이렇게 팀원과 함께 request로 요청이 뜬다.
눌러보자.
이렇게 바뀌었다.
이제 리뷰를 요청 받은 입장으로 돌아가보자.
이렇게 pull request가 1로 되어 있고 팀원이 적었던게 그대로 나온다.
한번 들어가보자.
이건 움짤로 만들어 보았다.
근데 팀장 메일을 확인하니 다음과 같이 왔다.
첫번째는 팀원이 올리고 나서 메일이 자동으로 보내진것 같다.
두번째것은 리뷰를 요청하고 메일이 보내진것같다.
8. 코드 리뷰하기 (코드 리뷰어)
Files Changed로 가서 어떤 코드가 수정이 되었는지 확인 해보자.
+ 로 커서를 갖다 대면 이렇게 나오는데 눌러보자
그러면 이렇게 창이 하나 뜨는데
박스안에는 사진과 같이 코멘트 혹은 변경 요청 중 하나를 선택해서 그것에 맞게 남기면 된다.
그리고 다음과 같이 되는데 이젠 Finish your review를 클릭해보자
각 3가지는 다음과 같다. (사실 단어에 의미가 이미 내포하고 있긴하다.)
- Comment : 일반적인 코멘트
- Approve : Comment와 달리 리뷰어가 승인을 하는 것으로, 머지해도 괜찮다는 의견
- Request Changes : 변경을 요청하는 것으로, 승인을 거부한다는 의견
일단 Approve를 했다.
9. 합치기 전 내 로컬에서 충돌 해결 및 테스트
그럼 저 위에있는 Merge pull request가 아른아른 거리기 시작한다. 하지만 깃에 올라가버리면 꼬이기때문에, 그전에 먼저 나의 로컬에서 테스트를 해보고 올리도록 하자.
일단 여기서는 pull은 팀장 position으로 했다.
지금상황에서는 뼈대만 만들고 아무거나 추가하고 했기에 코드 작성자가 pull을 안했지만, 나중에는 코드 작성자가 pull을하여 최종 확인을 해야 하지 않을까 싶다.
이부분은 조금 더 테스트후 수정 및 보완을 하도록 하겠다.
작동 확인결과 이상이 없다.
10. Merge 하기
- 만약 수정사항이 있다면?
- git add, commit, push를 하도록 하자.. 반복과정
- 수정사항이 없다면?
- merge!
merge pull request를 눌러보자.
마지막으로 한번 더 묻는다.
Confirm 하자!
다음과 같이 바뀌었다.
그리고 코드도 들어가보면?
바뀌었다.
11. 추가 기능 개발
1. 내 로컬의 dev에도 변경 사항 반영
- dev branch로 이동 (git checkout dev / git switch dev)
- 위의 이미지는 생략.
- git pull origin dev
2. 다음 기능 개발
기능 브랜치 생성 및 코드 작성
git add, commit, push
pull request 생성 및 코드 리뷰
내 로컬에서 충돌 해결 및 테스트
12. 반복….
Git GUI Application을 통한 history 확인.
선택은 자유
git kraken
sourcetree
git desktop
github (web)
실제로 사용해보기의 11번이 쪼금 취약한 것 같아서, 코드를 좀더 적어봐야겠다.