[지옥에서 온 Git] 5. 깃허브로 협업 - 공동 작업자와 원격저장소 및 브랜치 사용

5. 깃허브로 협업하기

5.1 원격 저장소 함께 사용하기

하나의 깃허브 계정으로 둘 이상의 컴퓨터에서 원격 저장소를 공유해 버전을 관리할 수 있다.

원격 저장소 복제하기 (clone)

클론clone
: 원격 저장소를 지역 저장소로 똑같이 복제하는 것.

• 원격 저장소를 클론하면, 복제된 지역 저장소와 원격 저장소는 자동으로 연결된다.

클론 절차

1. 깃허브 원격 저장소의 Code를 누르고, 원격 저장소의HTTPS링크를 복사한다.
2. 클론할 디렉토리를 만들 위치로 이동한 후 다음 명령어를 사용한다.
   • git clone HTTPS링크 디렉토리명
     : HTTPS링크의 원격저장소를 해당 디렉토리로 클론함 (해당 이름이 없으면 새로 생성)
   • git clone HTTPS링크 .
     : HTTPS링크의 원격저장소를 현재 디렉토리에 클론함

개인 컴퓨터에서 작업 후, 원격 저장소에 올리기

원격 저장소를 clone으로 복제한 로컬 저장소에서 작업 후, 커밋-푸시 한다.

• git commit -am "커밋메시지"
• git push

회사 컴퓨터에서 작업 후, 원격 저장소에 올리기

윗 단계를 거치며, 원격 저장소의 내용이 회사 컴퓨터의 지역저장소 내용과 달라졌다.
따라서 회사 컴퓨터에서 작업하기 전에 원격 저장소의 커밋 변경내역을 가져와야 한다(풀 pull)

• git pull
  (회사 컴퓨터의 지역 저장소에서)

• 내려받은 내역을 가지고 작업 후,
  git commit -am "커밋메시지"
git push

이후 다시 개인 컴퓨터에서 작업하기 위해서는, 마찬가지로 git pull 먼저 한 다음 작업하고, 그 뒤 git commit - git push 하면 된다.

5.2 원격 브랜치 정보 가져오기

git pull로 원격 저장소의 커밋을 가져오기 전에, 원격 저장소에 어떤 변화가 있었는지 정보를 미리 확인할 수 있다.

원격 master 브랜치

로컬저장소의 master브랜치처럼, 원격저장소도 만들 때 master브랜치가 기본 생성됨.

$ git log
commit 7942f91d298d355e4fe1679553c65603a5765752 (HEAD -> master, origin/master, origin/HEAD)
Author: Haina <bibi6666667@kakao.com>
Date:   Tue Feb 9 22:45:03 2021 +0900

    add c

• HEAD -> master : 이 커밋이 지역 저장소의 최종 커밋임을 의미함.
• origin/master, origin/HEAD(빨간색) : 이 커밋이 원격 저장소의 최종 커밋임을 의미함.

rnala@DESKTOP-SL978IQ MINGW64 ~/git_home (master)
$ git log --oneline
cc70393 (HEAD -> master) create f3.txt
7942f91 (origin/master, origin/HEAD) add c
4b0204e Create f2.txt
2c6193f add b
14e8677 add a

rnala@DESKTOP-SL978IQ MINGW64 ~/git_home (master)
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

• 위처럼 (HEAD -> master)의 위치와 (origin/master, origin/HEAD)의 위치가 다르다는 것은 로컬 저장소 상태와 원격 저장소 상태가 다르다는 것을 의미함.
• git status로 상태를 보면,
  Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits) 와 같이
  현재 로컬 저장소의 master 브랜치가 원격 저장소(origin)의 master브랜치보다 1 커밋 앞서 있다고 알림이 뜸.
  -> git push를 통해 로컬 저장소 커밋을 원격 저장소로 올려서 둘을 맞춰 주어야 함.
• git push이후에는 다시 (HEAD -> master, origin/master, origin/HEAD) 상태가 됨.

❗ git push에서, 아래와 같은 오류 발생시

$ git push
To https://github.com/bibi6666667/github_test.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/bibi6666667/github_test.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

• 원인 : fetch를 하지 않고 push한 경우 발생하는 오류. (다음 문단의 내용 참고)
• 해결 1 : git push origin +master (비추천 - 원격 저장소의 기존 데이터는 보장할 수 없음)
• 해결 2 : pull을 먼저 해서 원격저장소의 데이터를 받은 뒤 다시 push

원격 브랜치 정보 가져오기 (fetch)

패치 fetch
: 불러오다, 가져오다의 의미.

• git fetch
  : 원격 저장소의 정보를 가져오는 명령어.
• git fetch와 git pull의 차이점은?
  : pull은 원격 저장소의 커밋을 가져와 무조건 로컬저장소에 합친다
  fetch는 원격 브랜치에 일어난 정보만 가져온다.
• 용도
  : 원격 저장소의 수정 내역을 확인한 다음에 지역 저장소와 합치고 싶을 때,
  fetch로 커밋을 가져와 확인한 뒤 괜찮으면 pull로 합치면 된다.

rnala@DESKTOP-SL978IQ MINGW64 ~/git_office (master)
$ git fetch
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0
Unpacking objects: 100% (5/5), 587 bytes | 45.00 KiB/s, done.
From https://github.com/bibi6666667/github_test
   5b12a9f..ef8e7de  master     -> origin/master

rnala@DESKTOP-SL978IQ MINGW64 ~/git_office (master)
$ git status
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean

rnala@DESKTOP-SL978IQ MINGW64 ~/git_office (master)
$ git log --oneline
5b12a9f (HEAD -> master) add d
7942f91 add c
4b0204e Create f2.txt
2c6193f add b
14e8677 add a

• git fetch를 하면..
  • git status에는
    Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch) 라는 안내가 나타난다.
    → 내 브랜치(로컬 저장소)가 origin/master(원격저장소)보다 2커밋 뒤처져 있고, fast-forward가능하다. git pull을 통해 지역 저장소를 업데이트하라.
  • git log에 (HEAD -> master)만 보이고, origin/master는 보이지 않는다.
    왜? 원격 저장소의 최신 커밋정보를 가져오긴 했지만, 아직 지역 저장소에 합치지 않은 상태이기 때문.
  • 즉 fetch로 가져온 원격 저장소의 최신 정보는,
    origin/master브랜치가 아닌 FETCH_HEAD라는 브랜치로 가져온다.
• git fetch로 가져온 원격 브랜치의 최신 커밋을 보려면..
  • git checkout FETCH_HEAD
    : FETCH_HEAD브랜치로 체크아웃.
  • (FETCH_HEAD에서)git log
    : FECTH_HEAD브랜치에 저장된 원격브랜치의 최신 커밋을 확인 가능.
    (해당 브랜치 최신 커밋에origin/master, origin/HEAD가 표시되어 있다)
  • git diff HEAD ofigin/master
    : 지역 저장소의 최신 커밋과 fetch한 커밋의 차이를 비교함
• 패치로 가져온 내용을 현재 브랜치에 합치려면..
  • git pull 로 원격 저장소 소스 내려받기
  • git merge FETCH_HEAD로 FETCH_HEAD브랜치의 커밋 병합하기 (추천)
    (git merge origin/master : 원격master브랜치의 커밋을 병합하도록 지정)
    (git merge origin/브랜치명 : 원격 해당 브랜치의 커밋을 병합하도록 지정)

✔ 생각해보면, 결국 git pull 명령은..

: git fetch와 git merge FETCH_HEAD 를 합친 것과 같은 기능을 하는 명령어이다.

5.3 깃허브 협업의 기본 절차

깃허브 원격 저장소를 사용해 협업할 때, 기본적으로 사용되는 절차와 방법을 알아본다.

공동 작업자 Collaborators 추가

깃헙 public repository는 주소만 알면 누구든 소스를 보고, 다운로드 받을 수 있다.

하지만 누구나 저장소에 커밋을 푸시할 수는 없다. (소스가 무분별하게 수정될 수 있기 때문)

마찬가지로 공개/비공개 저장소에서 협업하려면, 승인된 공동 작업자(Collaborators)에게만 커밋을 올릴 권한을 주어야 한다.

1. 팀원 중 한 명이 깃헙 원격 저장소를 만든다.
2. 나머지 팀원들을 원격 저장소의 공동 작업자로 추가한다.
   • Settings - Manage access - Invite a collaborator
   • 초대할 팀원의 깃헙 아이디/메일주소 를 입력하고 초대를 보낸다.
   • 초대를 받은 팀원이 Accept Invitation을 누르면 추가가 완료된다.

작업 환경 구성

공동 작업자들은 서로 다른 컴퓨터들에서 하나의 깃허브에 접속해, 번갈아 커밋을 올리고 내려받으면서 작업해야 한다.

3. 각 작업자의 컴퓨터에 로컬 저장소를 만들고, 공동 작업에서 사용할 이름 및 이메일주소를 지정한다.
   • git init 로컬저장소이름
   • cd 로컬저장소이름
   • git config user.name "사용자이름"
   • git config user.email 메일 주소

원격 저장소에 첫 커밋 푸시

4. 첫 문서를 작업하고, 스테이징 및 커밋한다
   • vim 첫문서.txt
   • git add 첫문서.txt
   • git commit -m "첫 커밋"
5. 지역 저장소의 커밋을 원격 저장소에 푸시한다
   • git remote add origin 원격저장소HTTPS주소
     : 원격저장소 주소를 지역저장소의 origin으로 지정함
   • git push -u origin master
     : origin의 master브랜치에 커밋을 푸시함
     (-u : 다음부터는 git push만으로 커밋을 푸시할 수 있는 옵션)

공동 작업자 컴퓨터에 원격 저장소 복제

6. 공동 작업자들은 각자 자신의 작업을 진행하기 전에, 로컬 저장소에 원격 저장소를 복제한다
   • git clone 원격저장소주소

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

깃허브 협업은 여러 사람이 문서를 수정하고 푸시하기 때문에, 작업 전에 반드시 원격 저장소의 최신 커밋을 풀한 다음 나의 커밋을 푸시해야 한다.

원격 저장소를 clone한 뒤에도 원격 저장소에 새 커밋이 올라올 수 있기 떄문이다.

각 작업자들은 풀 pull - 커밋 commit - 푸시 push 순서대로 작업해야 한다.

7. 공동 작업자들은 작업 시작 전에 원격 저장소에서 풀pull을 진행한다

   • git pull

   • ❗pull을 먼저 진행하지 않고 혼자 작업한 뒤 add-commit-push하면 아래와 같은 오류가 발생할 수 있다. ! [rejected] ...

     $ git push To https://github.com/bibi6666667/github_test.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/bibi6666667/github_test.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

     발생 이유 : 원격저장소의 최신 커밋 정보가 팀원의 로컬 저장소에 저장되어 있지 않기 때문.
     해결 : 커밋을 푸시하기 전에, git pull로 원격저장소의 최신 커밋을 가져온다.

8. 각자 작업한 뒤, 작업 내역을 원격 저장소에 커밋하고 푸시한다.

   • git add 작업파일.txt
   • git commit -m "커밋메시지"
   • git push -u origin master

5.4 협업에서 브랜치 사용하기

협업 시 팀원들이 각각 다른 기능을 맡아 작업하게 된다.
각 작업이 master브랜치의 문서와 섞이지 않도록, 개별 브랜치를 만들어 버전을 관리해야 한다.
각 팀원이 만든 브랜치 역시 원격 저장소에 푸시할 수 있다.

깃허브에서 협업할 때는 보통 작업자마다 브랜치를 만들어 진행하며, 작업 중간중간 풀 리퀘스트를 보내 master브랜치에 병합한다.

새 브랜치 푸시

로컬 저장소에서 새 브랜치를 만들고, 커밋한 다음, 원격 저장소에 푸시한다.

1. 원격 저장소에서 최신 커밋 정보를 가져온다

   • 항상 풀pull부터 한 다음 작업을 진행한다.
     왜? 깃허브로 협업할 때는 다른 작업자의 변경사항을 반영해야 하므로

   • git pull

2. 새로운 기능을 작업할 새 브랜치를 로컬 저장소에 만들고, 새 브랜치로 체크아웃한다.

   • git branch 브랜치명
git checkout 브랜치명
   • 또는 git checkout -b f(브랜치 만들기 + 해당 브랜치로 체크아웃)

3. 새 브랜치에서 작업한 뒤 커밋

   • git add 작업파일.txt
   • git commit -m "커밋메시지"

4. 원격 저장소에 새 브랜치를 함께 푸시

   • git push origin 브랜치명
     : 원격 저장소(origin)에 해당 브랜치를 푸시한다.

5. 깃허브 원격 저장소에 접속해 푸시한 브랜치를 확인한다.

풀 리퀘스트 pull request 로 푸시한 브랜치 병합

원격 저장소에 푸시된 브랜치는 풀 리퀘스트(pull request, PR)를 통해 병합(merge)해야 한다.
그래야 해당 브랜치에서 작업한 내용이 원격 저장소에 반영된다.

풀 리퀘스트는 해당 원격 저장소의 공동 작업자라면 누구나 살펴보고 병합할 수 있다.

6. 원격 저장소에 푸시된 브랜치 옆의 [New pull request]를 누른다
7. pull request 메시지(제목, 내용)를 작성한 후 [Create pull request]를 눌러 풀 리퀘스트를 전송한다
8. 원격저장소에서 Pull request를 눌러 등록된 풀 리퀘스트 목록을 확인한다.
9. 각 풀 리퀘스트 메시지를 확인 후, 작업 내용에 문제가 없으면 [Merge pull request]를 누른다
   • 해당 공간에서 풀 리퀘스트를 남긴 사람과 메시지를 주고받을 수도 있다.
10. 커밋 메시지를 입력하고 [Confirm merge]를 눌러 브랜치를 병합한다.
11. 브랜치에 있던 파일이 master브랜치에 잘 병합되었는지 확인하고, 브랜치 목록을 눌러 브랜치가 잘 병합되었는지 (merged상태인지) 확인한다.