5 - 2 협업의 기본알아보기

첫 번째 커밋이 아니라면 풀 먼저하기

깃허브에서 협업할 때는 여러 사람이 함께 문서를 수정하고 푸시하기 때문에 

반드시 작업하기 전에 원격 저장소의 최신 커밋을 풀한 다음 자신의 커밋을 푸시해야 합니다.

 

팀원 A와 팀원 B가 있다고 가정할 때

팀원 A가 새 커밋을 만들어 원격 저장소에 푸시하는 동안 팀원 B가 다른 커밋을 푸시한다고 가정해보겠다.

 

팀원 A

vim apple.txt
git add .
git commit -m 'apple'
git push

 

팀원 B ( git pull  안 한 상태)

vim ms.txt
git add .
git commit -m 'ms' // 여기까지는 오류 없음
git push // ERROR

오류가 발생하고 말았다. [rejected]라고 시작하는 오류 메시지는 

원격 저장소에 있는 최신 커밋 정보가 팀원 B의 컴퓨터에 저장되어 있지 않기 때문에 나타난 것이다.

 

이런 오류가 생기지 않게 하려면 자신의 커밋을 푸시하기 전에 원격 저장소의 최신 커밋을 가져와야 한다. ( git pull)

오류가 발생 했지만 자신의 지역 저장소에는 잘 커밋이 되어 있는 것을 확인할 수 있다.

git pull

자동으로 빔이 실행되면서 커밋메시지가 표시된다. 저장하고 나가자

ls -al

팀원A가 커밋한 apple.txt도 잘 받아와 진 것을 알 수 있다.

이제 맨 위에 있는 커밋 ( ms를 만들고 +  apple을 가져온 )을 push해주어 

원격저장소의 커밋을 업데이트 해주자!! ( 커밋을 업데이트하면 자동으로 브랜치가 최신 커밋을 가르킴 )

이렇게 잘 적용이 된 것을 확인할 수 있다.

 

협업에서 브랜치 사용하기

협업 하다보면 각자 다른 기능을 맡아서 작업하는 경우가 많다.

팀원 A는 기능A를 만들고

팀원 B는 기능B를 만드는 것처럼 말이다. 

이러 때는 각자의 작업이 master브랜치에 있는 문서들과 섞이지 않도록 새 브랜치를 만들어서 버전을 관리한다.

 

새로 만든 브랜치 푸시하기

팀원A가 새로운 기능을 만들기 위해 자신의 지역 저장소에 f라는 브랜치를 만들고  커밋한 다음 원격 저장소에 푸시하는 과정을 살펴보겠습니다.

 

1. 먼저 최신 커밋 정보를 받아오기 위해 git pull

git pull

 

2. 새로운 기능을 구현하기 위해 브랜치f를만들고 체크아웃한다.

git checkout -b f // -b옵션을 쓰면 f라는 브랜치가 없을 경우 만들고 이동해줌

 

3. new.txt라는 문서를 만든후 커밋한다. 커밋 메시지는 'new 1'

vim new.txt
git add .
git commit -m 'new 1'

 

4. 원격 저장소에 f 브랜치까지 함께 푸시 해야한다. git push 뒤에 origin f를 추가하면 원격 저장소(origin)에 f 브랜치를 푸시한다는 의미이다.

git push origin f

신기하다!!

HEAD는 f브랜치를 가리키고 f브랜치는 new 1커밋을 가리킨다.

 

풀 리퀘스트로 푸시한 브랜치 병합하기

아직 원격 저장소의 파일 목록에는 f브랜치에서 만들었던 new.txt파일이 없다.

푸시한 브랜치는 풀 리퀘스트를 통해 병합해야 원격 저장소에 반영되기 때문이다.

 

1. 브랜치 설명 옆에 있는 New pull request를 누른다.

 

2.풀 리퀘스트 메시지를 작성한 후 Create pull request를 누르면 협업 중인 저장소에 풀 리퀘스트가 전송된다.

3. 협업 중인 원격 저장소에 등록된 풀 리퀘스트는 공동 작업자 중 누구나 살펴보고 병합할 수 있다. Pull request버튼을 누르면 등록된 풀 리퀘스트 목록이 나타난다.

 

4. 풀 리퀘스트 메시지를 살펴본 다음 내용에 문제가 없으면 Merge pull request를 눌러 병합한다.

 

5. 커밋 메시지를 직접 입력하거나 메시지 사용 가능 Confirm merge를 누르면 병합이 끝난다.

 

6. 브랜치가 병합되면 해당 브랜치에 있던 파일이 master화면에 나타난다. 브랜치 상태를 알고 싶다면 파일 목록 위에 있는 2 branches를 눌러보면 된다.

 

7. 브랜치가 병합된 상태라면 merged라고 표시되어 있다. 그리고 공동 작업자 중 누가 브랜치를 병합했는지도 알 수 있다.

 

8. 깃허브에서 협업할 때는 보통 작업자마자 브랜치를 만들어서 진행하고 작업 중간중간 풀 리퀘스트를 보내서 master브랜치에 병합한다. 그래서 깃허브로 협업할 때는 다른 작업자의 변경 내용을 바로 반영하기 위해 항상 git pull부터 한 다음 자신의 작업을 진행하는 것이 좋다.

 

 

---------------------------------------------------------------------------------

f브랜치에서 new 2라는 커밋으로 푸쉬를 하고(git push origin f <- 전에 한 번 했다고 git push만 하면 안되고 origin f까지 적어줘야 함)

 

여기서 git checkout master로 master브랜치로 넘어간 뒤 git pull 해보면 아무것도 일어나지 않음

즉 푸쉬를 해도 원격으로 올라가지는 않았다느 것을 다시확인 가능

 

근데 ?? 풀 리퀘스트를 보내지 않고

master브랜치에서 git pull origin f를 해보니 아래와 같은 vim이 실행되면서 f브랜치에 있는 커밋이 잘 받아졌다. 그리고 push까지하여 원격 저장소의 커밋을 최신 상태로 변경해 주었고 역시 new 2커밋또한 원격 저장소에 잘 저장이 된 것을 확인할 수 있다.

 

master브랜치에서 git log에 f브랜치에 대해서 보이지 않는다

하지만 git pull origin f한 뒤에 

자동으로 f브랜치의 커밋들까지 병합이 된 것(+ 업데이트)을 확인할 수 있다. 

아마 f브랜치에서 커밋 했던 것들이 master에서는 보이지 않았던 것 같다.

 

근데 merged로 바뀌지 않았으나.. github에서 merged는 하지않았으나 결과적으로 지역 저장소에서 병합이 된 것같음

혹시나 해서 New pull request를 눌렀는데 위와 같은 화면이 출력됨 ..