꾸준히 개발하기

04. 깃허브로 백업하기

04-3. 지역 저장소를 원격 저장소에 연결하기

git init, git add, git commit까지 해주고 나면 현재 지역 저장소가 버전별로 잘 관리되고 있는 상황이다. 나의 컴퓨터에만 소스가 저장되지 않고, 서버 상/온라인 상에 백업&협업을 해줄 수 있도록 원격 저장소에 업로드하자. 가장 대표적인 사이트 GitHub를 사용한다.

GitHub 회원가입 및 레포지터리 생성은 굳이 정리하지 않고 넘어가겠다.

깃허브 레포지터리를 만들었다면, 해당 주소를 복사한 뒤 다음 명령어를 실행한다

• git remote add origin 복사한 레포지터리 주소

이 명령은 원격 저장소(remote)에 origin을 추가하겠다고 알려주는 것이다. * 여기서 origin = github 레포주소

* 깃에서는 기본 브랜치를 master라고 하듯, 깃허브에서는 origin이라는 이름으로 레포 주소를 명명한다.

원격 저장소(remote)에 제대로 연결됬는지 확인하려면 다음 명령어를 실행한다.

• git remote -v 

04-4. 원격 저장소에 올리기 및 내려받기

지역 저장소 -> 원격 저장소 : push

원격 저장소 -> 지역 저장소 : pull

원격 저장소에 파일 올리기 - git push

• git push -u origin master (최초 push 때에만)

지역 저장소의 브랜치를 origin(원격 저장소)의 master 브랜치로 푸시하라는 뜻

* -u 옵션 : 지역 저장소의 브랜치를 원격 저장소의 master 브랜치로 연결하기 위한 것으로 맨처음 한번만 사용하면 ok

한번만 연결해준 뒤에는 git push 명령어만으로 쉽게 원격 저장소에 소스를 업로드할 수 있다.

• git push

원격 저장소에서 파일 내려받기 - git pull

원격 저장소에 있는 파일이 수정된 경우, 지역 저장소와 원격 저장소의 파일에 차이가 생긴다. 이 때 원격 저장소와 지역 저장소의 상태를 같게 만들기 위해 원격 저장소에서 파일을 가져올 수 있는데, 이것을 pull이라고 한다.

• git pull origin master

* 기본 원격 저장소가 origin이고 지역 저장소의 기본 브랜치가 master이기 때문에 git pull만 입력해도 ok

04-5. 깃허브에 SSH 원격 접속하기

* SSH : Secure Shell

아이디와 비밀번호를 통해 인증하는 방법 대신, 프라이빗 키와 퍼블릭 키를 이용하여 현재 사용하고 있는 기기를 깃허브에 인증하는 방식이다. 

음... 일단은 이 부분은 넘어가고 싶다 ... 추후 필요하면 다시 정리하자.

05. 깃허브로 협업하기

이 책을 읽게 한 메인 부분이다! 

05-1. 여러 컴퓨터에서 원격 저장소 함께 이용하기

원격 저장소 복제하기 - git clone

원격 저장소를 기존에 연결된 지역 저장소 외에 다른 지역 저장소에서 사용하려면 원격 저장소에 담긴 내용 전체를 지역 저장소로 가져와야 한다. 원격 저장소를 지역 저장소로 똑같이 가져오는 것을 복제(clone)한다고 한다.

터미널 창에서 디렉터리를 만들 위치로 이동한 뒤, git_home, git_office 디렉터리에 각각 레포를 복제하자.

• git clone 복사한 레포 주소 git_home
• git clone 복사한 레포 주소 git_office

이제 개인 컴퓨터(git_home)에서 작업한 내용을 push하게 되면 원격 저장소, git_home 디렉터리에만 최신 소스가 반영되어 있을 것이다. 따라서 회사 컴퓨터(git_office)에서 작업을 하기 전에, 먼저 git pull 명령어를 통해 가장 최신 소스를 가져온 뒤 작업을 진행해야 한다!

하나의 원격 저장소에 둘 이상의 컴퓨터를 연결하여 사용한다면 풀과 푸시를 습관화하자. 그래야 어떤 컴퓨터에서 접속하든 가장 최신 소스를 유지할 수 있다.

05-2. 원격 브랜치 정보 가져오기

git pull 명령어는 원격 저장소의 최신 커밋을 지역 저장소에 합쳐준다. 하지만 최신 커밋을 합치기 전에, 원격 저장소에 어떤 변화가 있었는지 먼저 살펴봐야 한다. 이럴 때는 원격 브랜치에서 정보만 먼저 가져올 수도 있다. 

원격 master 브랜치

• HEAD -> master : 이 커밋이 지역 저장소의 최종 커밋
• origin/master : 원격 저장소의 최종 커밋

지역 저장소의 최종 커밋과 원격 저장소의 최종 커밋이 다른 것을 볼 수 있다. git status를 입력하면 push 명령을 통해 지역 저장소의 커밋을 원격 저장소로 올리라고(publish) 하는 것을 볼 수 있다. 

시키는 대로 push를 하고 다시 로그를 찍어보면 다시 지역 저장소와 원격 저장소의 상태가 같은 것을 확인할 수 있다.

원격 브랜치 정보 가져오기 - git fetch

git fetch 명령은 원격 저장소의 정보를 가져오는 기능이 있다. 팀 작업을 할 때 다른 사람이 수정한 소스를 한번 훑어보고 지역 저장소와 합치고 싶다면 pull 대신 fetch를 사용하여 커밋을 가져온 뒤 지역 저장소와 합치면 된다.

git_office로 이동한 뒤 git fetch 명령을 실행하면 지역 저장소에는 실질적으로 바뀐 것이 아무것도 없다. 로그 역시 변화가 없다. 원격 저장소에 있는 최신 커밋 정보는 가져왔으나 아직 합치지 않았기 때문이다. 따라서 git status 명령을 실행해보면 현재 한개의 커밋이 뒤쳐져 있다고 나온다.

그렇다면 fetch로 가져온 최신 커밋 정보는 어디에 있을까? 바로 origin/master 브랜치가 아니라, FETCH_HEAD라는 브랜치로 가져온다. 패치해서 가져온 최신 커밋을 살펴보고 싶다면 FETCH_HEAD 브랜치로 checkout해서 살펴보면 된다.

• git checkout FETCH_HEAD
• git log

fetch한 후 최신 커밋을 현재 브랜치에 합치려면 git pull 명령어를 사용하여 원격 저장소의 소스를 내려받을 수도 있고, git merge 명령어로 FETCH_HEAD에 있던 커밋을 병합할 수도 있다. git merge를 사용해보자!

• git checkout master
• git merge FETCH_HEAD

* fetch한 뒤 merge 할 때 git merge origin/master 나 git merge origin/브랜치명 을 적어 커밋할 수 있다. 하지만 매번 브랜치 이름을 적는 것은 번거로우므로 지역 저장소에 반영하지 않은 최신 커밋을 모두 반영하려면 git merge FETCH_HEAD를 사용해주면 된다!

05-3. 협업의 기본 알아보기

앞서 배웠던 내용의 복습이다. collaborator로 등록된 경우 git init 해준 뒤, git config user.name "이름", git config user.email 이메일주소 명령어를 통해 환경을 셋팅할 수 있다.

원격 저장소에 첫 커밋을 push하는 팀장이나, 원격 저장소를 clone해오는 팀원의 사례는 앞서 정리해둔 것과 동일하므로 추가로 작성하지는 않겠다! 하지만 정말 중요한 것은 여러 명이 한 레포에서 작업할 때 최신의 상태를 가져오지 않고 작업한 뒤 push하게 되면 최신 커밋이 반영되지 않은 채로 push했기 때문에 reject되는 경우가 발생할 수 있다. 따라서 첫번째 커밋이 아니라면 항상 pull을 먼저 하는 습관을 들이자! 

05-4. 협업에서 브랜치 사용하기

각각 기능을 나눠 개발할 때, 보통 브랜치로 작업한 뒤 master에 합치는 경우가 대부분이다. 한번 살펴보자.

먼저 작업을 수행하기 전에 꼭! git pull을 해준 뒤 시작하자.

f라는 이름으로 브랜치를 만들어 새로운 기능을 개발한다고 가정하자. 다음과 같이 입력하면 이미 f라는 이름의 브랜치가 있다면 그 브랜치로 checkout해준다.

• git checkout -b f
• vim f4.txt
• git add f4.txt
• git commit -m "feature4"
• git push origin f (원격 저장소 origin에 브랜치 f를 push)

이렇게 브랜치를 push하고 나면 깃허브에서 pull request를 통해 푸쉬한 브랜치를 병합할 수 있다.

브랜치를 눌러 New pull request를 눌러, 메세지를 적절하게 작성한 뒤 Create pull request를 누르면 협업 중인 저장소에 풀 리퀘스트가 전송된다. 이 풀 리퀘스트는 공동 작업자들 누구나 살펴보고 병합할 수 있다. 저장소 파일 위의 pull request 버튼을 누르면 등록된 풀 리퀘스트 목록이 뜬다. 풀 리퀘스트 메세지를 살펴보고 문제가 없다면 Merge pull request 를 통해 병합한다. 필요하다면 메세지를 입력한다. Confirm merge 버튼을 누르면 브랜치 병합이 끝난다. 브랜치가 병합되면 해당 브랜치에 있던 파일이 원격 저장소에 나타난 것을 볼 수 있다.

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

06. 깃허브에서 개발자와 소통하기

(프로필, README 파일 작성은 책을 참고하자. 티스토리에서는 오픈 소스를 다루는 06-3부터 정리)

06-3. 오픈 소스 프로젝트에 기여하기

오픈 소스 프로젝트에 기여하려면 먼저 수정하려는 오픈 소스 저장소를 자신의 저장소로 복제해야 한다. 다른 저장소에 있는 소스를 직접 수정하면 안되기 때문이다. 이를 fork한다고 한다. fork하게 되면 나의 계정에 해당 레포지터리가 복제되어 있을 것이다. 이제 이 레포지터리를 clone해와서 add, commit, push하면 된다. 하지만 이것은 나의 복제된 레포지터리에만 반영되어 있고 원본 레포지터리에는 반영되어 있지 않다. 따라서 오픈 소스 개발자에게 수정한 내용을 원래 소스에 합쳐달라고 요청해야 한다. 이 요청을 풀 리퀘스트라고 부른다. 

포크한 자신의 저장소에서 New pull request 버튼을 눌러 수정한 내용을 확인한 뒤 개발자에게 이 수정 사항을 원본 저장소에 반영해달라고 요청할 수 있도록 Create pull request를 누른다. 커밋할 때 입력한 커밋 메세지와 설명이 나타나는데, 원본 개발자에게 문서의 이 부분을 왜 수정했는지 설명하는 내용을 추가로 입력하는 것이 좋다 :) 내용 입력이 끝나면 Create pull request 버튼을 누른다. 이제 화면이 원본 저장소로 바뀌면서 저장소의 개발자와 질문, 답변을 주고받으며 수정한 내용을 원본 소스코드에 반영할지 여부를 결정한다. 

06-4. 깃허브에 개인 블로그 만들기

깃허브는 정적인 페이지를 제공할 수 있도록 무료 웹호스팅 기능(GitHub pages) 을 제공한다. 

이미 작성한 페이지 소스가 있다면 계정.github.io 라는 이름으로 레포지터리를 만든다. Readme 파일로 이 레포를 초기화한다는 옵션에 반드시 체크하자! 이제 이 레포지터리에 페이지 소스들을 업로드한다. 깃허브 저장소에서 settings에 접속하여 GitHub pages 항목을 살펴보면 홈페이지 주소가 나타날 것이다. 

VS Code에서 깃 활용하기

이 부분은 VS code에서 친절하게 버튼으로 다 만들어줘서 보면서 사용하면 될 듯 하다! 잘 모르겠다면 책을 다시 참고하자~! 

매번 구글링해가면서 깃을 사용했는데 이번 기회에 책을 읽어가면서 차근차근 개념을 익혀서 좋았다. 얼른 오픈소스에도 기여해보고 브랜치도 잘 써보고! 힘내자