[Git] Git 기초 및 GitKraken 실습_4

해당 게시물은 모두의 깃&깃허브 책을 기반으로 작성되었습니다.

깃허브로 협업하기

개발자의 SNS, 깃허브

github에 tensorflow repository에 들어가보자. 우측에 보면 Star가 있다. SNS 속 마음에 드는 게시물에 '좋아요'를 누를 수 있는 것처럼 마음에 드는 오픈 소스 프로젝트에 Star를 눌러 호감을 표시할 수 있다.

Star를 누르면 다음과 같이 표시된다.

다음 그림의 작은 박스를 보면 160,609 commits 라는 항목이 보인다. 또한, 8분 전에 새로운 커밋이 추가된 것을 알 수 있다.
그 아래 큰 박스를 보면 텐서플로를 이루고 있는 소스 코드를 볼 수 있다. 보면 해당 파일 또는 폴더가 마지막으로 변경된 시점도 알 수 있고, 그 좌측에 마지막으로 변경된 시점의 커밋 메시지도 볼 수 있다.

이제 아래로 스크롤을 내려보자. 다음과 같이 텐서플로 프로젝트와 관련한 안내가 적힌 화면을 볼 수 있다. 이건 README.md라는 파일 속의 내용이다.

README.md는 해당 프로젝트의 설치 방법, 사용 방법 등을 담고 있는 파일이다.

또한, 깃허브에서는 Issues로 오류를 제보하거나, 더 다양한 기능을 제안할 수도 있다. 스크롤을 다시 최상단으로 올리고 Issuses를 클릭해보자.

텐서플로와 관련한 다양한 이슈를 확인할 수 있다. 텐서플로와 관련한 오류를 제보하는 이슈도 있고, 새로운 기능을 제안하는 이슈도 있다.

---

원격 저장소 호스팅 서비스, 깃허브

깃허브는 개발자의 SNS이기도 하고, 원격 저장소 호스팅 서비스이기도 하다. 앞선 절에서 SNS로서의 깃허브를 알아보았다면 이번에는 원격 저장소를 제공하는 원격 저장소 호스팅 서비스로서의 깃허브를 알아보겠다.

깃허브가 제공하는 원격 저장소란 무엇일까? 원격 저장소라는 이름 그대로 원격(remote)에 있는 저장소이다. 앞선 게시물에서 깃을 통해 저장소를 만들어 보았을 것이다. 이 저장소는 여러분의 컴퓨터 속에만 존재하는 저장소, 즉 로컬(local) 저장소라고 한다.

반면, 원격 저장소는 여러분의 컴퓨터 속에만 있는 저장소가 아닌, 인터넷 세상 어딘가에 있는 다른 컴퓨터 속의 저장소를 의미한다.

그렇다면 왜 로컬 저장소를 두고 원격 저장소를 사용할까? 원격 저장소가 있으면 뭐가 좋을까? 원격 저장소를 통해 얻을 수 있는 이점에는 크게 두 가지가 있다.

• 백업
• 협업

여러분이 열심히 개발한 프로젝트가 로컬 저장소에만 있다면 여러분의 컴퓨터가 고장 나거나 실수로 로컬 저장소를 삭제할 경우 큰일이 날 것이다.

하지만 로컬 저장소의 프로젝트를 원격 저장소에 백업해두고, 언제든 원격 저장소에서 프로젝트를 내려받아 사용할 수 있다면 여러분의 컴퓨터가 망가지거나 로컬 저장소가 삭제되어도 전혀 문제가 되지 않는다.

그리고 이렇게 원격 저장소를 이용하면 다른 개발자들과 협업도 수월하게 할 수 있다. 모든 개발자가 이해하는 공통 코드를 원격 저장소에 업로드하고, 이를 내려받아 새로운 커밋들을 추가한 뒤 이를 다시 원격 저장소에 추가하는 방식으로 작업한다면 로컬 저장소에서만 작업하는 것보다 훨씬 효율적으로 협업할 수 있게 되기 때문이다.

---

원격 저장소 만들기

본인 repository로 와서 우측 상단의 +를 클릭한 뒤 New Repository를 클릭한다.

다음 그림의 각 항목은 다음 설명과 같다.

• Owner : 원격 저장소의 소유자
• Repository name : 원격 저장소의 이름
• Description : 만들 원격 저장소에 대한 설명을 적는 공간
• Public : 모두에게 공개된 저장소
• Private : 모두에게 공개하지 않고 여러분(또는 여러분이 지정한 일부 사용자)만 볼 수 있는 저장소
• Add a README file : 원격 저장소를 생성할 때 자동으로 README 파일을 생성
• Add .gitignore : 원격 저장소를 생성할 때 자동으로 .gitignore을 생성
• Choose a license : 이 저장소에 담길 프로젝트의 라이선스를 선택하는 항목

생성된 원격 저장소의 모습이다.

이렇게 생성한 원격 저장소는 Settings 메뉴의 최하단에 Delete this repository를 클릭해 삭제할 수 있다.

원격 저장소와의 네 가지 상호 작용

이제 이 원격 저장소와 상호작용 하는 방법에 대해 알아보겠다.

1. clone : 원격 저장소를 복제하기
2. push : 원격 저장소에 밀어넣기
3. fetch: 원격 저장소를 일단 가져만 오기
4. pull : 원격 저장소를 가져와서 합치기

clone : 원격 저장소 복제하기

clone은 말 그대로 깃허브상에 존재하는 원격 저장소를 로컬로 복사하여 가져오는 방법이다.

여러분이 직접 만든 원격 저장소뿐만 아니라 깃허브상에 공개된 모든 원격 저장소를 여러분의 컴퓨터로 클론하여 가져올 수 있다.

방금 만든 원격 저장소를 클론해보자. GitKraken에서 상단 메뉴바 > File > CLone Repo 를 클릭한다.

그럼 다음과 같은 화면이 나타나는데, 중간에 위치한 목록 중 현재 우리는 Clone with URL과 GitHub.com을 사용할 수 있다.

• Clone with URL
  • Where to clone to : 클론해올 내 로컬 저장소
  • URL : clone할 깃허브 주소

    URL은 다음과 같은 과정을 따라 복사한 URL을 사용해야 한다.
    

결과는 다음과 같다. 이대로 하단의 Clone the repo! 버튼을 클릭해주면 클론 완료된다. 해당 로컬 저장소로 가면 원격 저장소에 존재하는 파일 및 폴더들이 클론된 것을 확인할 수 있다.

• GitHub.com
  • Where to clone to : 클론해올 내 로컬 저장소
  • Repository to clone : GitKraken과 연동되어 있는 계정에 존재하는 repository 목록

결과는 다음과 같다. 이 방법 또한 하단의 Clone the repo! 버튼을 클릭해주면 클론이 완료되며, 해당 로컬 저장소로 가면 원격 저장소에 존재하는 파일 및 폴더들이 클론된 것을 확인할 수 있다.

성공적으로 완료되었고, 열어보기 위해 Open Now 버튼을 클릭하자.

클론한 직후의 모습이다. 유일한 커밋으로 보이는 Initial commit은 test-repo의 README.md 파일이 추가되며 만들어진 커밋이다.

좌측의 LOCAL과 Remote 을 클릭해보자.

그러면 LOCAL에 'main'이, REMOTE에 'origin/main'을 볼 수 있다.

이 브랜치들은 무엇일까? 앞서 깃에서 관리하는 기본 브랜치는 main 브랜치라고 말했다. 클론하면 원격 저장소가 그대로 로컬로 복제된다. 그래서 로컬로 클론한 저장소의 기본 브랜치 이름도 깃허브의 기본 브랜치 이름과 동일한 main이 된다.

'origin/main'은 원격 저장소 origin의 기본 브랜치를 지칭한다. 여기서 origin은 원격 저장소 경로에 붙은 일종의 별명이다.

Push: 원격 저장소에 밀어넣기

깃에서 사용하는 push는 원격 저장소에 로컬 저장소의 변경 사항을 밀어넣는 것을 의미한다.

현재까지는 test-repo라는 원격 저장소를 클론하기만 했다. 따라서 현재 원격 저장소 test-repo와 로컬 저장소 test-repo의 상태는 동일하다.

그럼 이 상태에서 로컬에서 커밋을 추가한 뒤 이를 원격 저장소에 푸시하는 예를 실습해보자.

로컬 저장소 test-repo에 문자 A가 담긴 a.txt 파일을 추가한 뒤 커밋하자. 커밋한 GitKraken은 다음과 같은 상태가 된다.

좌측의 main을 잘 보면 둘 다 main인데 아이콘이 다르다. 랩탑 아이콘이 로컬 브랜치이고, 깃허브 프로필 사진 아이콘이 원격 저장소의 main 브랜치이다.

이렇게 아이콘으로 어느 저장소 작업 내용인지 확인할 수 있다.

이 상태에서 원격 저장소를 로컬 저장소와 같게 만들려면, 다시 말해 a.txt 파일을 원격 저장소에 추가하려면 로컬의 변경 사항을 원격 저장소에 푸시해야 한다. 상단의 Push을 클릭한다.

GitKraken의 좌측 하단에 다음과 같은 화면이 나타나며 푸시가 완료된다.

원격 저장소 깃허브를 확인해 보자. a.txt 파일이 잘 추가됐을 뿐 아니라 커밋 수가 두 개로 늘었다.

한 번 더 해보자. 이번에는 a.txt 파일을 삭제하고, B가 저장된 b.txt 파일을 추가한 뒤, commit해보자.

커밋이 잘 되었다면 Push한다.

위에서 잠깐 설명했듯이, 랩탑 아이콘은 로컬을 의미하고, 프로필 사진 아이콘은 원격 저장소를 의미한다. Push를 함으로써 로컬 저장소와 원격 저장소가 동일한 커밋 위치에 있는 것을 확인할 수 있다. 즉, 두 저장소가 동기화되었다는 의미이다.

fetch: 원격 저장소를 일단 가져만 오기

fetch는 '가져오다'를 의미한다. 다시 말해, fetch는 원격 저장소의 변경 사항들을 가져오는 방법, 더 정확하게는 일단 가져만 오는 방법이다. 이게 무슨 말일까?

지금까지의 실습을 그대로 따라왔다면 현재 로컬 저장소와 원격 저장소의 상태는 같을 것이다. 다음과 같은 상태이다.

현재 원격 저장소 test-repo는 오로지 여러분만이 사용하고 있지만, test-repo를 여러 개발자가 협업하여 개발하고 있는 상황을 가정하자. 다른 개발자가 언제든 test-repo에 새로운 변경 사항을 추가할 수 있기 때문에 test-repo는 시시각각 변할 수 있다.

다른 개발자가 푸시한 내용을 여러분의 로컬로 가져오고 싶을 때 패치를 사용할 수 있다. 다시 말해, 원격 저장소의 변경 사항을 로컬로 가져오고 싶을 때 fetch를 사용한다.

---

이 상황을 직접 실습해보겠다.

깃허브에서 b.txt 파일을 직접 수정하고, 커밋을 추가해보겠다. 원격 저장소 test-repo에 접속해 b.txt 파일을 클릭한다.

연필 아이콘을 클릭한다.

여기에서 b.txt 파일을 수정한 뒤 Commit changes... 버튼을 클릭한다.

이후 커밋 메시지를 간단하게 작성한 후 Commit Changes 버튼을 다시 한 번 클릭한다.

새로운 커밋이 만들어지고, b.txt 파일이 수정된 것을 확인할 수 있다.

자, 그렇다면 현재 원격 저장소와 로컬 저장소의 상태는 어떨까? 그림으로 표현하면 다음과 같다. 로컬 저장소가 모르는 사이 원격 저장소에 변경 사항이 추가된 셈이다.

그렇다면 원격 저장소의 변경 사항을 fetch해보겠다. GitKraken의 상단에 Pull 버튼 오른쪽에 보면 화살표 모양이 있다. 이를 클릭해준 뒤, Fetch All을 클릭해준다.

응? 약간의 로딩이 있고 나서도 변화가 없다.

fetch는 단순히 원격 저장소의 변경 내역을 확인만 하고 로컬 브랜치와 병합은 하고 싶지 않은 경우 사용한다. GitKraken은 이미 fetch 작업을 시각적으로 실시간 반영해서 보여주고 있는 것이다.

따라서 다음 그림과 같이 원격 저장소의 내용과 로컬 저장소의 내용이 병합되지 않고, 각각 다른 아이콘을 가진 main이 다른 곳에 위치한 것을 알 수 있다.

패치 전후를 그림으로 표현하면 다음과 같다.

main 브랜치를 origin/main 브랜치와 병합해보면 다음 그림처럼 로컬의 main 브랜치도 네 번째 커밋을 가리키게 된다.

main 브랜치에 체크아웃한 후 origin/main 브랜치에 마우스 오른쪽 버튼을 클릭한 후 Merge origin/main into main을 클릭하자.

원격 저장소의 변경 사항을 로컬 저장소에 병합한 것이며, 로컬 저장소의 b.txt 파일을 확인해보면 깃허브에서 수행했던 변경사항이 반영되어 있는 것을 알 수 있다.

Pull : 원격 저장소를 가져와서 합치기

fetch가 원격 저장소를 '일단 가져오는 방법'이라면 pull은 원격 저장소를 '가져와서 합치는 방법'이다. 즉, pull은 fetch와 merge를 동시에 하는 방법이다.

깃허브 속 원격 저장소로 접속하자. Add file을 클릭하여 Create new file을 클릭하자.

c.txt 파일을 만들고 commit한다.

커밋이 완료된 모습이다. c.txt 라는 새로운 파일이 생성됐고, 커밋은 총 5개로 증가했다.

현재 상황을 그림으로 표현하면 다음과 같다.

GitKraken으로 돌아와 깃허브에서 생성한 변경 사항, 즉 c.txt 파일을 만든 다음 다섯 번째 커밋을 pull해보겠다. 상단의 pull을 클릭한다.

pull이 완료된 모습이다. main 브랜치가 다섯 번째 커밋을 가리키고 있다. 다시 말해, 원격 저장소의 새로운 변경 사항이 로컬 저장소로 바로 병합된 셈이다. 즉, pull을 하게 되면 원격 저장소의 변경 사항이 즉시 로컬로 병합된다.

실제로도 c.txt 파일이 생성된 것을 확인할 수 있다.

정리하자.

• clone : 원격 저장소를 로컬로 복제하여 가져오는 방법
• push : 로컬 저장소의 변경 사항을 원격 저장소로 밀어 넣는 방법
• fetch : 원격 저장소의 변경 사항을 일단 가져만 오는 방법 (merge X)
• pull : 원격 저장소의 변경 사항을 로컬 저장소로 가져와 병합하는 방법 (fetch + merge)

Pull Request : 깃허브로 협업하기

한 원격 저장소에 여러 개발자가 코드를 기여할 수 있다.

여기서 궁금증이 생긴다. 앞에서 여러분은 여러분이 소유한(여러분이 직접 만든) 원격 저장소에 푸시해 보았다. 그런데 여러분이 소유하지 않은 원격 저장소에도 푸시할 수 있을까? 일반적으로 그렇지 않다.

Collaborator로 추가하여 push 권한 주기
원격 저장소 소유자가 여러분을 Collaborator로 추가한 경우에는 여러분이 소유하지 않은 계정의 원격 저장소에 푸시할 수 있다.

그러나, 이는 권장하는 방법이 아니며, 대부분 직접 푸시할 권한이 없는 상태에서는 Pull Request으로 협업한다.

원격 저장소에 누구나 push할 수 있다면 여러 문제가 발생할 수 있다. 만일 누구나 허락없이 소유하지도 않은 원격 저장소에 푸시할 수 있다면 원격 저장소의 소유자가 원하지도 않는 변경 사항들이 원격 저장소에 마구 추가되는 불상사가 발생할 수 있다.

그렇다면 push 권한이 없는 원격 저장소에 어떻게 코드를 밀어넣을 수 있을까? 어떻게 다른 원격 저장소에 변경 사항을 추가할 수 있을까?

Pull Request를 통해 가능하다. Pull Request는 말 그대로 원격 저장소가 내 변경 사항을 pull하도록 요청(request)하는 방법이다. 즉, '내가 당신의 원격 저장소를 이렇게 변경하고 싶은데, 이 변경을 당신의 저장소로 풀 해주세요!'하고 부탁하는 방법이다.

Pull Request는 다음 단계를 통해 이루어진다.

1. 기여하려는 저장소를 본인 계정으로 fork하기
2. 포크한 저장소를 clone하기
3. 브랜치 생성 후 생성한 브랜치에서 작업하기
4. 작업한 브랜치 push하기
5. Pull Request하기

---

실습해보자.

다음 원격 저장소에는 practice.html이라는 파일이 있다. practice.html을 클릭해보자.

다음은 practice.html의 내용이다. 필자는 해당 repository의 소유자이긴 하나, pull request를 보내보겠다. li 태그 안에 내 이름을 적어 Pull Request를 보내겠다.

실제 소유자는 필자이지만, 직접 push할 수 없는 상황을 가정하겠다. 그러니 나는 'practice.html을 변경한 내용을 pull해주세요!'하며 Pull Request를 보내야 한다.

1. Pull Request의 첫 번째 단계는 기여하려는 저장소를 본인 계정으로 포크하기이다.

포크(fork)란 원격 저장소를 여러분의 계정으로 복제하는 방법이다. Fork를 눌러보자.

2. 포크하면 여러분의 계정으로 해당 레포지터리가 복제된다. 필자의 소유가 아닌(가정이지만) 저장소를 내 계정으로 복제했기 때문에 나는 복제된 저장소에 push할 수 있다.
   

다시 말해, 여러분은 여러분이 소유하지 않은 원격 저장소에 직접 push할 순 없지만, 여러분의 계정으로 포크(복제)한 원격 저장소에는 push할 수 있다.

3. Pull Request의 두 번째 단계는 포크한 저장소를 clone하기이다.

여기서 khuda-5th의 저장소가 아닌 포크한 저장소, 즉 여러분 계정으로 복제한 저장소를 클론하는 것이 중요하다. GitKraken으로 돌아와 여러분의 저장소를 클론해보자.

4. Pull Request의 세 번째 단계는 브랜치 생성 후 생성한 브랜치에서 작업하기이다. 클론이 잘 됐다면 새로운 브랜치를 생성해 보자.
   

5. 이제 practice.html 파일을 수정하고, commit하자.
   

6. 이제 네 번째 단계, 작업한 브랜치 push하기이다. 커밋을 push하자. 다음은 push한 결과이다.
   

7. 깃허브에 가보면, main 브랜치에는 변경 사항이 적용되지 않은 원본 그대로이고, add_name 브랜치에만 변경 사항이 적용되어 있다.

8. 이제 마지막 단계는 Pull Request 보내기이다. 깃허브 속 포크한 저장소로 돌아오자. 상단에 Compare & pull request가 생겼다. 이를 클릭하자.
   

9. 다음은 PR을 생성하는 화면이다.
   박스친 내용은 'HyejiYu/git-pracitce' 저장소의 'add_name' 브랜치를 'khuda-5th/git-practice' 저장소의 'main' 브랜치에 반영하고 싶다는 의미이다.
   

스크롤을 내려보면 작업 내역을 볼 수 있다.

작업한 내용이 맞다면 Create pull request를 클릭한다.

10. 이렇게 pull request가 생겼다. 여기까지 했다면 할 일은 끝났다.
    

11. 이제 khuda-5th/git-practice 저장소의 Pull requests 메뉴에서 여러분의 pull request를 확인할 수 있다. 이제 이 원격 저장소의 소유자, 즉 git-practice의 admin 권한을 가진 사람이 pull request를 검토하고, 작업에 문제가 없다면 이를 저장소에 병합할 것이다.
    

여기서부터는 pull request를 받은 사람 시점이다. pull request 하단에 보면 다음과 같이 Merge pull request 버튼이 있다. 이를 클릭하여 pull request를 병합할 수 있다.

다음과 같이 pull request에 댓글을 남길 수도 있다.

---

정리해보자. pull request를 보내는 과정은 다음과 같다.

1. 기여하려는 저장소를 본인 계정으로 포크하기
   일반적으로 여러분이 소유하지 않은 원격 저장소에는 push할 수 없다. 그렇기에 여러분의 계정으로 원격 저장소를 복제해와야 하는데, 이 과정을 fork라고 한다고 했다.
2. 포크한 본인 계정의 저장소를 clone하기
   여러분이 소유하지 않은 원격 저장소에 푸시하기는 불가능할지 몰라도 포크한 원격 저장소에 푸시하기는 가능하다. 그래서 포크한(여러분의 계정으로 복제된) 저장소를 클론한다.
3. 브랜치 생성 후 생성한 브랜치에서 작업하기
   새로운 브랜치를 생성한 후 해당 브랜치에서 변경 사항을 만들고 커밋한다.
4. 작업한 브랜치 push하기
   생성한 브랜치를 push한다. 그러면 깃허브에 pull request 버튼이 생성된다.
5. Pull Request 보내기
   마지막으로 Pull Request를 보내면 끝이 난다.