[프로젝트] Github 협업하는 방법

협업 => 코드 합치기 : CI (Continuous Integration)

요즘은 깃헙에 CI를 많이 한다.

a, b, c가 협업을 시작하기 전에 가장 먼저 해야 할 일은 다음과 같다.

1. git init
2. git remote add origin 저장소 (원격 origin)
3. git pull (내려받기)

= git clone

위의 1, 2, 3은 clone과 같은 과정이다.

내려받으면 모두 1번 2번의 히스토리(형상)를 갖게된다.

이방식 말고 다른 방식이 있다.

저장소를 복제(fork)하는 것이다.

대규모 협업을 할 때 사용하는 방식이다.

a도 자기만의 저장소가 있고, b도, c도 자기만의 저장소에 깃헙 형상을 복제한다.

복제한 저장소를 downStream, 원 저장소를 upStream이라고 한다.

원래 하나 있을 때는 깃헙을 origin이라 하고

저장소를 복제할 때는 downstream을 origin이라고 한다.

우리는 첫 번째 방식을 사용해 협업해볼 것이다.

a가 3번 작업을 하고 있고 b가 4번 작업을 하다가

b가 4번을 마쳐서 push를 하면 origin과 과거 형상(1번, 2번)이 같기 때문에 push가 가능하다.

push를 하면 origin과 형상이 일치하여 잘 관리되고 있는 것이다.

이때 a가 3번 작업을 마쳐서 push 하려고 하면 거절당한다.

현재 origin은 1번, 2번, 4번의 형상을 갖고 있고,

b는 1번, 2번이기 때문에 형상이 다르다.

a는 과거 형상이 같았기 때문에 push가 가능했지만

b는 과거 형상(history)이 다르기 때문에

pull을 먼저 해서 형상을 일치시킨 후에 push를 해주어야 한다.

깃헙에 1번, 2번 로그가 있다.

홍길동과 내가 clone까지 되어있는 상태이다.

홍길동이 3번 작업을 완료하고 push 하면

내가 완성한 4번 작업은 push하지 못하고 pull을 먼저 해줘야 한다.

pull이라는 것은

깃의 임시 보관 영역(remote 저장소)에 1번, 2번, 3번을 내려받는다.

그리고 내가 가지고 있는 1번, 2번, 4번을 비교한다.

내가 가지고있는 것을 마스터 브랜치라고 하고

리모트 저장소에 있는 것을 리모트 브랜치라고 하는데,

이 둘을 병합해야 한다.

pull은 병합하는 것까지 포함하여 내려받아주는 것이다.

둘을 비교해서 3번을 마스터 브랜치에 합치는 것을 merge라고 한다. 병합!

pull = 다운 + 병합

머지 충돌 해결

a와 b가 같은 파일을 수정했다.

a의 작업이 먼저 끝나서 pull -> push 하고

b가 push 하기 위해 pull을 했을 때 머지 충돌이 일어난다.

해당 파일을 수정하다가 CONFLICT가 일어났다고 알려주는데

제일 마지막에 수정한 사람이 충돌을 해결해야 한다.

충돌이 일어난 해당 파일을 확인해보면 이상한 코드가 추가되어있다.

남겨두고 싶은 내용을 놔두고 필요 없는 문구들은 지워주고,

a와 b가 작업한 내용 둘 다 남겨놓으려면

둘 다 남겨두고 다른 문구를 지워준 뒤 저장해 주면 된다.

그리고 다시 git add . 부터 해줘야 한다.

이게 충돌 해결하는 방법이다.

동일한 파일을 건드리는데 충돌이 나지 않는 방법이 있다.

주석으로 코드의 자리를 나눠놓으면 같은 파일을 건드려도 충돌이 일어나지 않는다.

하지만 잘 사용하지 않는다.

같은 파일은 동시에 건드리지 않는 게 좋다.

// 팀장자리~~~~~~~~~~~~~~~~~
[팀장] 작업 완료

// 니자리~~~~~~~~~~~~~~~~~
[팀원] 나도 완료

팀원들과 함께 협업하기 위해서는 팀장 깃허브 Repository 콜라보레이터에 팀원을 추가해줘야 한다.

콜라보레이터로 추가되고 나면 팀원들은 뭘 할 수 있을까?

모든 게 가능하다.

해당 공유 저장소에서만!!

팀원들의 깃허브에는 저장소가 생성되지 않는다.

머지 로그는 누구 파일을 내려받았는지 알려주는 로그이다.

pull은 origin과 형상을 맞추는 일인데 굳이 필요한 로그는 아니기 때문에

안 보이게 설정해줄 수 있다.

git log --no-merges

학원에서 급하게 하다가 집에 가서 이어하고 싶은데 어디에 올려야 하는지

1.~~

2.~~

해야 할 일이 5번까지 있는데 2번까지 하고 집에 가야 할 때는 어떡해야 할까?

로그인 파일 하나 만드는데 로그를 3개씩 남기면 좋지 않다.

브랜치를 만들어야 한다.

자기 이름에 하이푼(-) 기능으로 브랜치 이름을 만들어주자.

jaewon-login 이런 식으로!

# 브랜치 생성
git branch jaewon-login

# 브랜치 이동
git checkout jaewon-login

1. 로그인 디자인 완성

3번까지 해야 하는데 학원에서는 1번까지 마무리하고

집에 가서 3번까지 하고 싶을 때 jaewon-login 브랜치에서 커밋해준다.

git add .
git commit -m "[정재원] 로그인 디자인 완성까지 완료"

이제 마스터 브랜치랑 jaewon-login 브랜치랑 형상이 다르다.

jaewon-login 브랜치에서 git log를 확인해보면 로그인 디자인 완성까지 생겼지만

git checkout master로 마스터 브랜치로 옮겨가면 그 로그는 날아간다.

서로 다른 가지이니까!

다시 git checkout jaewon-login으로 가서

git push origin jaewon-login

jaewon-login에 push 해준다.

완성 후 push 해주면 끝!

팀원이 브랜치에서 push 하고 나면 팀장에게 마스터 브랜치와 합쳐달라고 연락하는 게 제일 좋다.

팀장이 바쁠 때는 직접 합쳐야지!

마스터 브랜치와 합치는 것을 병합(merge)라고 하는데

머지 요청을 할 때 깃허브에서 pull request를 해줄 수 있다.

팀장이 이 PR을 확인하고 아래와 같이 3가지 방법으로 머지할 수 있다.

create a merge commit 마지막 2개 브랜치 로그들이 나옴

squash and merge 찌그려트려서 최종 로그만 나옴 (추천)

rebase and merge 로그 변경 (절대 쓰지 마)

팀장이 할 일

1. 프론트앤드 Repository
- 프로젝트 세팅(gradle mustache 포함시켜서 - db연결은 필요 없겠네!)
- 이니셜 커밋(최초 커밋) initial commit
- 전체 파일 다 만들기 post폴더 writeForm.mustache, layout 폴더, js 폴더 등등
- 프로젝트 세팅 완료 커밋
- push 하고 콜라보

(*** 거절 comment or 승인 squash merge)

2. 백엔드 Repository
- 프로젝트 세팅(gradle spring 시작)
- 이니셜 커밋(최초 커밋) initial commit
- 컨트롤러, 서비스, 레파지토리, yml 세팅
- 프로젝트 세팅 완료 커밋
- push 하고 콜라보

개인이 할 일(로그인, 회원가입)

1. git clone
2. 기능 브랜치 생성 - 이동
3. 작업 시작 - commit, commit, commit -> git push origin 기능 브랜치
4. 작업 끝 - git push origin 기능 브랜치 -> PR(pull request) 요청 -> 팀장에게 보고
5. 거절 : 추가 작업해서 push -> PR 요청
승인 : 로컬 master 브랜치 이동, git pull origin master
--------------------
6. 회원가입 브랜치 생성 - 다음 작업 시작

핵심 : Master 브랜치는 배포 브랜치 (중요한 곳)
-> 기능별로 새로운 브랜치 만들어서 PR 요청하고 검사받는 것