협업과정

개인(몸 풀기)

1) 파일 생성, 작업 후 commit, gir에 저장소 생성

• 해당 주소 복사

2) 저장소 연동

• default remote까지 클릭.
• 이러게 완료되면 우리의 지역저장소와 원격저장소가 연결이 됨.

3) 팀원 초대

• add ppl을 눌러 팀원을 email을 넣고 상대방이 승인을 누르면 된다.

4) 연동

• 두번째 칸은 browse를 통하여 원하는 장소를 클릭하여 바꿔주면 된다.

협업

1. a가 먼저 코드를 수정하고 commit을 했다.

• 이때 commit을 해서 원격저장소로 보냈다면 다시 지역저장소로 다운 받은 수 수정해나가는 것이 좋다.

2. b가 a가 올려놓은 파일을 다운 받은 후 수정하여 push를 시도한다.

• hint에서 알 수 있듯 a가 commmit해놓은 최신화된 파일이 아니라 error가 뜨는 것 이다.

3. 이때 a와 b가 같은 부분을 수정하여 a가 올려놓은 파일을 pull할 때 b컴퓨터에 error가 발생한다.

• 이때 merge를 클릭하면 다음과 같은 comflict가 발생한다.
  
• 이를 외부도구를 이용하여 처리해보자
  

P4merge

• 한글이 깨지긴 하지만 똑똑한 P4 merge가 알아서 merge 준비를 마쳤다.
  
  
• 저장을 누르고 끄면
  
• 병합된 파일 하나와 백업파일 하나가 들어있다.
  
  이제 merge commit을 할 수 있는 상태가 되었다.

4. 이제 만약 다시 a가 작업을 하려고 한다면 항상 최신화 되어있는 파일로 작업하기 위해 pull로 당겨오는 것이 좋다!!!

• 즉, push와 pull의 주기가 짧을 수록 comflict가 덜 나고 조직의 소통이 원활하게 된다는 것이다....!!!

fetch는 무엇인가?

• 그냥 master은 local 이고 oring/master은 remote이다.

5. 이후 a가 작업을 진행했다면

• 다음과 같은 상황이 된다. 이는 현재 remote repository와 지역 저장소의 불일치를 의미한다. 이때 이를 동기화하려면 어떻게 하면 될까? push하면 된다.
  

6. 이제 b가 작업을 시작하기 전에 패치를 누르면

• 다음과 같은 상황이 되고 이는 현재 내 local 저장소가 remote보다 뒤쳐져 있다는 것을 알 수 있다.
• 즉, 패치는 remote를 가져오기만 할 뿐 local에 영향을 주진 않는다.
• 이때 remote 파일을 병합을 누르게 된다면
  
• 로컬이었던 master 브랜치가 한 칸 위로 올라온 것을 볼 수 있다.
• 즉 pull : fetch+merge이다.

7. 이때 불안하다면 신중하게 merge하고 싶다면

• test branch를 하나 따서 merge를 진행한 다음 잘 된다면 그때 master branch를 merge 후 test branch를 삭제해도 된다.

pull request

• 만약 open source project라면 다른사람이 함부로 push해선 안 된다.
  
• 이때 다른 사람이 이 open source project에 뭔가 더 도움이 되고자할 때 pull request를 한다.
  

fork 버튼

• 다른 사람의 코드를 가져와 내꺼인 것 마냥 내가 마음대로 하겠다. 라는 뜻. 이렇게 된다면 repository의 이름은 갖지만 소유자의 이름이 바뀌게 된다.
  
• 하지만 이때 수정 후 push를 하게 되면 나의 git hub에 pull request가 뜨게 되고 이를 누르면 원래 주인의 화면에 pull requests가 뜨게된다.

기타

1. 리베이스 정리 참조
2. 코드 리뷰 (Gerrit) : 개발자의 코드를 상호 검증하는 것. 투표를 통하여 최다 득표자가 commit됨
3. git에는 issue를 확인할 수 있는 창이 있음.