11. 협업을 위한 Clone(최초 복제)/ Pull(협업 작업전 가져오기 + push직전 가져오기)

현재까지는 로컬에서 원격저장소로 파일을 업로드하는 Push를 했었다.

하지만 새로운 멤버가 프로젝트에 참여했다고 가정해보자. 그 멤버는 원격저장소에서 로컬저장소로 다운로드해야하는 Clone(복제)을 해야한다.

원격저장소의 소스코드를 Clone하여 --> 소스트리에서 Clone Respository를 통해 새로운 로컬저장소에 다운로드 하게 된다.

새로운 멤버가 Clone하기

이 때, 현재 로컬저장소의 이름은 [operntutorials_git]이다.
새로운 협업자는 [operntutorials_new]라는 이름으로 작업을 할 것이라 가정하고 진행해보자.( _뒤에 작업자 이름을 붙힌다)

• 소스트리에서 새로운 탭을 만들고, Clone을 선택하자.
  
  
  
• 원격저장소의 프로젝트에서, Clone with HTTPS 을 통해 https url를 복사해온 뒤, 첫번째 칸에 붙혀넣자
  
  
  
  
  
• Destination Path는 원격저장소의 프로젝트를 저장할 로컬저장소의 위치이다.
  이 위치를 지정하면서, 새로운 작업자의 이름을 붙힌 폴더명으로 수정해준다.
  Browse를 눌러서, 프로젝트를 모아둔 폴더에 간 뒤, 새로운폴더[opentutorials_new]를 만들어서 저장해주자.
  
  
  
  
  
• 원격저장소의 프로젝트를 Clone해서, 새로운작업자의 이름으로 복제하게 되었다.
  [ Open in Explorer ] 를 눌러서  Clone하여 가져온 파일들도 직접 확인해보자.
  

소스트리의 2개의 탭에서
open~ _git 은 내가 하는 작업
open~ _new는 새로운 멤버가 하는 작업이라고 가정하고 다음을 실습해보자.

하나의 원격저장소로 두 멤버간 협업하기

하나의 원격저장소에 새로운멤버가 push를 할 경우 , 컴퓨터의 이름에 해당하는 Author가 다르게 올라간다.
지금은 하나의 컴퓨터로 작업을 하므로, Author를 터미널에서 일부러 변경해주는 작업을 해보자.
[opentutorials_new]를 선택한 상태에서 우측상단의 [Terminal]을 클릭한 뒤, 아래와 같이 입력해준다.
- git config user.name "new"
- git config user.email new@gmail.com

• 먼저 git이라는 사용자가, 새로운 내용을 추가해보자.
  
  
  
  Push옆의 숫자는 원격저장소와 로컬저장소의 버전차이다.
  타임라인을 보면, 원격저장소를 의미하는 origin/master와 버전차이가 2개가 나는 것을 확인할 수 있다.
  
  
  
• 이제 push를 통해 원격저장소로 올려보자.
  원격저장소의 commits에 가보면, push해준 버전이 업로드 된 것을 확인할 수 있다.
  
  
  
  
  
  
• 이제 새로운멤버인 new가 작업을 시작해야한다.
  협업자는 새로운 작업을 시작하기 전에, 반드시 원격저장소에 새로운 내용이 있는지 없는지 확인해야한다.
  그 때 사용하는 기능이 [ Pull ]이다. 즉,  이전에 Clone을 통해 프로젝트를 다운받아놨다하더라도,
  새로운 내용을 Pull을 통해 다운로드 해야한다.
  
  
  
  원격에 있었던, [ git이 push 버전]이,  새멤버의 프로젝트로 가져와지는 것을 확인할 수 있다.
  
  
• 이제 new라는 새멤버가 작업을 해서 push를 해보자.
  
  
  
  push를 완료하면, 아래와 같이 원격저장소(origin/master)와 new라는 새멤버의 로컬저장소(master)가 버전이 같아진 것을 확인할 수 있다.
  
  
  
  
• 만약 git이라는 사람이,   원격저장소의 pull 없이 새로운 작업을 한다고 가정해보자.
  이 상황에서 원격저장소에 push를 하게 되면, 어떤 일이 일어나게 될까?
  
  git은 push를 거절한다.
  pull을 먼저하고 나서, push를 해야한다!
  
  
  
  이러한 상황에서는 Pull을 먼저해서, 충돌이 없다면 자동으로, 병합(merge)를 한 다음, Push를 해야한다.
  
  
• 먼저, 빠트린 Pull을 해보자.
  원격저장소의 버전을 가져와, 로컬저장소의 버전 과 병합(merge)가 된, 새로운 버전이 만들어지는 것을 확인할 수 있다.
  
  그래프를 보게 되면, 원격저장소의 new가 push한 버전(분홍색) 과, git이 새로운 작업을 한 버전(파란색) 사이에, pull을 통해  자동으로 병합된 것을 확인할 수 있다.
  git이 자동으로 병합하여, 별도의 버전을 만들어주는 것이다.

원격저장소가 있고, 협업하는 개발자가 있다면, push전에 무조건 pull을 하자!

[ Pull -> ~~~~~~~~~작업~~~~~~~ -> commit -> Push직전에 Pull한번더 -> Push ]이 작업이다.

같은 부분을 수정하여 충돌이 일어나는 경우

서로 같은 부분을 다른 작업자들이 작업할 때, 충돌이 일어나게 된다.

혼자 작업하는 경우에도, 실험적인 작업을 다른브랜치에서 작업하다가 같은 부분을 수정하여 충돌이 일어날 것이다.

• 먼저 충돌을 발생시키도록 만들어보자. 같은 ul태그 속 라인에서 li를 만들어보자.
  
  
  
  
• 이렇게 같은 부분(li마지막 라인)을 수정한 상태에서,
  new라는 사용자에서 먼저 push를 한다. (단, push전에는 pull을 먼저해야한다. 반드시)
  그리고, push를 하자마자, 1초만에 git이라는 사용자가 pull을 했다.
  
  그랬더니, Uncommited changes와 함께 느낌표의 충돌이 발생한 것을 알 수 있다.
  
  
  
  
• 충돌이 일어날 땐, 직접 파일을 수정해야했다.
  git이라는 사람은 push를 하기 직전에 pull을 했을 뿐인데, 같은 부분이 수정되어 충돌이 일어난 것이다.
  
  
  마찬가지로, ======위쪽의 HEAD는 git이 작업한 부분이고,
  =====아래쪽은 new라는 사람이 작업한 뒤 원격저장소에 올려놓은 코드이다.
  git입장에서는 같은 곳을 수정했기 때문에, 선택하지 않고, 사람에게 위임한 것이다.
  수정을 통해 정확한 코드만 남겼다고 가정하자.
  
  
  
  
• git이라는 사람이 직접파일을 수정하여 충돌을 해결했다면,
  Mark Resolved를 한 뒤, commit해야한다.
  commit하기 전에, Mark Resolved만 한 상태에서, 타임라인의 Graph를 먼저 살펴보자.
  
  
  충돌을 해결하고 난 뒤의 Working Copy의 부모를 보자.
  파란색 부모은 원격저장소(origin/master)이고, 분홍색 부모은 로컬저장소(master)이다.
  
  Pull 버튼을 통해서, 2개의 버전이 병합되었고, 아직 커밋되지않은 버전이 생긴 것이다.
  하지만 같은 부분수정으로 충돌이 발생했기 때문에--> 버전이 생성안되고, Uncommitted 형태로 주어진상태다.
  
  
  
• commit을 눌러서 충돌을 병합해보자.
  회색동그라미가, 버전이 생기면서 파란색으로 변한 것을 확인할 수 있다.
  
  
  
  
• 이제 Push를 통해서 원격저장소에 업로드 시켜보자.
  

이렇게 먼저 push한 new보다는, 나중에 push한 git에게 충돌해결의 임무가 주어진다.
그리고 원격저장소와 자주 동기화해야지만, 이러한 충돌을 해소할 수 있다.