Git의 원격 저장소

Git remote 저장소

우리는 앞선 실습을 '로컬'에서만 진행을 했다. 물론 예의 경우 '로컬' 뿐 아니라 '원격'에 있는 저장소에도 모두 해당되는 내용이다. 원격 저장소는 git hub를 통해서 진행한다!

• 결국 우리가 로컬에서 작업한 것을 원격으로 합칠 것 이다. 우리의 local branch를 git push 를 통해서 branch을 푸쉬할 것 이며, 원격 저장소에서는 해당 브랜치를 '병합(원격에서 merge)' 하기 위해 pull request를 만들고, target branch에 merge를 진행할 것이다.

• 앞서 해당 페이지 문두를 꼭 먼저 읽어보자. Git hub 와 연혁에 대해 잘 설명되어있다.

Github

• 깃허브 페이지 https://github.com 에 접속하자.
• 깃허브(GitHub)는 분산 버전 컨트롤 소프트웨어 깃(Git)을 기반으로 소스 코드를 호스팅 하고, 협업 지원 기능들을 지원하는 마이크로소프트Microsoft의 웹서비스입니다. 2020년 현재 가장 인기 있는 소스 코드 호스팅 서비스이자 소프트웨어 개발 플랫폼입니다.
• 즉, 로컬에 있는 깃을 원격 저장소에 저장할 수 있는 하나의 큰 Hub이다.

• git hub 홈페이지에서 가입 -> 로그인을 하고, 나의 페이지에서 새로운 repository(이하 repo)를 만들자. ( 로그인, 회원 가격 정책 / 기본적인 깃허브 홈페이지 사용법은 생략 : 참조 )

Git clone

• git clone은 git repository 저장소를 복사해서 가져오는 것을 말한다. 이게 로컬이 될 수 있고, 원격이 될 수 있다. 이번엔 '원격'에 대해 알아보자.

• repo를 만들었으면 code 을 눌러 clone을 위한 url을 확인하자. 방법은 3가지가 존재한다. GitHub CLI는 github에서 최근에 제공하는 툴이다. 보통 HTTPS 또는 SSH을 많이 사용하며, 두 가지는 '네트워크 프로토콜'을 의미한다. HTTPS와 SSH는 주제와 많이 벗어나므로 생략하겠다.
• 우린 복사해온 url로 위와 같이, 우리 로컬 폴더에서, 즉 클론을 하고 싶은 로컬 디렉토리에서 아래 git clone 명령어를 통해 복사해서 가져올 수 있다.
• git clone https://github.com/레포지토리
• 그리고 clone은 git init부터 원격 저장소로 remote 까지 자동 설정되어서 가져온다.

Git remote

• 우린 복사해온 url로 위와 같이, 우리 로컬 디렉토리에서 git remote add origin https://github.com/레포지토리 를 실행해서 원격와 '연결' 할 수 있다.
• 해당 디렉토리에 하나의 원격 저장소만 연결하는 것은 또 아니다. 여러개의 원격 저장소를 연결 할 수 있다.
• clone과 다르게 remote는 '연결 만' 하므로, 원격 저장소 내용을 remote 후에 가져오려면 아래 커맨드를 실행 시켜야 한다.
• git pull origin(별칭) master(원격저장소의 마스터브랜치)

• git remote / git remote show origin 을 이용해(별칭 다른 점 주의), 내가 연결한 원격 저장소와, 해당 원격 저장소와 연결된 상태와 remote branches까지 모두 확인이 가능하다.
• git remote rename origin rename_test 와 같은 명령어로 원격 저장소 이름 변경도 가능하다.
• git remote rm rename_test 명령어도 주소가 바뀌거나 필요 없어진 원격 저장소는 삭제할 수 있다.

Git 원격 저장소 동기화

• 우린 '원격' 저장소를 만들고, 복사하고, remote를 연결하는 방법을 알아봤다. 위에 살짝 언급했지만, 그 '원격' 저장소를 '로컬' 과 동기화 하는 방법에 대해 살펴보자.
• 로컬은 나만 쓰고 원격이 곧 협업하는 공간으로 다 같이 작업한 브랜치를 밀어넣는 공간이다.
• 나만 쓰는 로컬 공간을 원격 저장소와 같게 만들고 작업해야 업데이트 되는 사항을 계속해서 볼 수 있습니다! 또한 내가 작업한 로컬 공간을 원격 저장소에 밀어 넣어줘야 다른 사람들도 그 부분을 공유해서 볼 수 있고, 적용이 됩니다!!

Git pull

• git pull 은 원격 저장소에서 데이터(정확하게는 해당 branch) 가져오고, 해당 branch를 merge까지 해준다.

• 위 이미지는 git init -> git remote add origin url -> git pull 을 한 것이다. 해당 repo 를 그대로 가져온 것을 볼 수 있다. 위 과정은 사실 clone과 동일하다.

• git log --all 을 통해 살펴보면, (HEAD-> master, origin/master) 로 가장 마지막 커밋지점 (snapshot)으로 merge(병합)까지 진행된 것을 볼 수 있다.

Git fetch

• git fetch 는 원격 저장소에서 데이터만 (정확하게는 해당 branch만) 가져오는 것이다.

• 위 이미지는 git init -> git remote add origin url -> git fetch origin 을 한 것이다.

• git branch -a 를 통해 모든 브랜치를 살펴보면 위와 같다.
• fetch를 통해 origin에 있는 모든 브랜치를 가져왔고, 우리는 원하는 브랜치를 골라서 merge를 진행해야 한다.
• 해당 브랜치의 commit log를 보고 싶으면, git log origin/master 와 같이 "원격 저장소 별칭/타겟 브랜치" 형태로 로그를 살펴보면 된다.

• 위 이미지와 같이 fetch후 merge를 하지 않으면 전혀 동기화가 되어 있지 않다. 내 로컬 브랜치 대상으로 remote branch를 merge 하자. git merge origin/master
• 그러면 동기화가 된 모습, 해당 repo의 master브랜치 snapshot과 동일해진다. 해당 merge는 fast-forward 방식으로 merge가 된다. 그래서 merge commit (새로운 커밋)은 만들어지지 않는다.

Git push

• git push를 통해 이제 로컬에 있는 것을 원격 저장소에 올려보자! 아래 작업 플로우를 살펴보자. 아주 간단한 작업 플로우와 push의 예시이다.

• checkout을 -b 옵션을 줘서 브랜치를 생성하며 체크아웃하고, txt파일을 하나 만들었다. 해당 파일은 track을 하지 않는 상태라 add를 통해 staging area를 보내 tracking을 해줘야 한다.

• add와 commit을 진행한 모습. 이제 작업이 다 끝났다. 작업하고 저장한 해당 브랜치를 원격 저장소에 push 해주자. 미리 알아야 할 것은 지금 push하려는 해당 브랜치가 다른 사람이 먼저 push 한 상태에서는 push를 할 수 없다!
• 특히 branch를 따지 않고 master를 push 할 경우 (현업에서는 이런 경우가 있으면 안된다), pull (or fetch & merge)를 통해 update를 시켜줘야 한다.

Git pull request

• push를 원격 저장소에 정상적으로 했다면, compare & pull request가 생겼다.
• 만약 이 버튼이 생기지 않았다면? master브랜치를 push했기 떄문이다.
• 사실 여기서 부터는 git hub 사용법에 가깝긴 하지만, bitbucket 또한 동일하다.
• 해당 버튼을 클릭해서 pull request를 만들어 주자. (이하 P.R)

• 색션을 3가지로 나누어 볼 수 있다.
• 상단은 해당 브랜치를 remote branch 중 어디에 merge를 할 것이냐.
  • [그림에서는 master로 merge 하려고 한다.]
• 중간은 해당 P.R의 새부 내용을 쓸 수 있다.
• 하단은 commit이 여러개인 branch의 경우, 해당 커밋과 메시지를 한꺼번에 볼 수 있고
• 최하단은 diff(merge 하려는 target branch), 다른점을 살펴볼 수 있다.
  • [그림에서는 master와 only_test branch의 다른점을 표시한다.]
• 위 사항을 다 살펴봤다면, create pull request를 통해 진짜 P.R을 만들자!

• P.R을 만들면 바로 위 이미지와 같은 화면이 뜬다. 다시 상단 메뉴중 Pull requests를 눌러보자.

• 우리가 만든 P.R이 "open"이라는 상태로 merge를 기다리고 있다.
• 이제 Merge pull request 버튼으로 원격 저장소에 우리가 push로 밀어넣은 브랜치를 master로 merge를 해주자!! 아주 기본적인 push 와 P.R, 그리고 merge가 끝이난다.

Git push "rejected"

• 나의 저장소에 있는 내용과 원격저장소에 있는 내용이 서로 다를때 push 요청은 "reject" 된다. 즉, 내가 지금 push 하려는 브랜치가 remote 에 있는 버전과 다르다는 의미다.
• 이 경우 이미 원격 저장소에 해당 브랜치 내용을 누가 덮어 씌워버렸거나 수정을 해버렸을때다.

1) git pull (또는 fetch & merge) 을 실행 해서 원격 저장소와 push하려는 브랜치의 버전을 맞춰 준다. 

2) conflict 가 났다면, (파일 추가 / 삭제만 한것이 아니라면 conflict가 날 것 이다.) 

3) git status 통해서 상태를 보며 충돌 난 부분을 해결해주자. 

4) 이때 유용한 것이 "rebase"이다. 사실 이때 뿐 아니라 conflict 해결에 rebase는 유용하다. 

• git pull 에서 conflict를 가장 많이 겪게 될 것이다.

Git P.R review, etc...

• 사실 위와 같이 P.R 올린 사람이 직접 master 등의 '배포를 위한 브랜치' 로 직접 merge하는 경우는 드물다. (어떤 협업 형태에 따라 물론 너무 다양하다)
• P.R을 만들고, "리뷰어" 를 지정해, 리뷰어 당사자가 달라진 파일 기반으로 코드 리뷰를 하고, comment를 남기며 해당 리뷰를 commit 으로 남기고, 승인 또는 반려를 할 수 있다. 살펴보기
• 이 review 부분은 사실 직접해보지 않으면 알기 쉽지 않다. 하지만 사실 버전관리의 '협업의 꽃'은 이 부분이라고 생각한다.
• 그리고 github - hook 을 통해 P.R 사실을 어딘가에 알리거나, 젠킨스(Jenkins)에 연동할 수 있고, DevOps로 유명한 지라(아틀라시안 제품군, Jira)와 연동도 가능하다. 살펴보기
• 이 사항은 러닝커브가 있고 '버전관리'를 넘어 DevOps 관점이라 주제에 벗어나기때문에 여기서 다루지는 않겠다.

이렇게 git 기반으로 버전관리를 시작해, 원격 저장소에서 버전관리를 하며 DevOps의 가장 기본적인 출발지점이 만들어 진다. 이렇게 github에서 제공하는 다양한 API를 응용할 수 있다는 점은 꼭 기억해두자. 물론 github만 제공하는 것이 아니라, 빗버킷에서도 제공한다.

Git 트래킹 브랜치

tracking branch

• git docs에서 설명하는 remote branch and traking
• 우리가 local에서 git init을 하여 git 작업을 하는 것과 같이, 원격 저장소도 git 저장소다. 하지만 'woring directory'가 존재하지 않는다.(즉 add할게 없고, 곧 commit할 영역이 없다는 소리다)
• 그러한 '원격 저장소'를 우리는 bare 저장소라고 부른다. 즉 우리가 직접 원격 저장소도 만들 수 있다는 소리다. 어떻게? 는 여길 참조하자
• 그런 원격 저장소를 remote, pull (또는 clone, fetch & merge)동기화 해서, 만들어진 브랜치가 remote-name/master 브랜치인데, 이 브랜치를 트래킹 브랜치라고 부른다.

• 트래킹 브랜치는, checkout 할 수 없고, commit 위치를 강제로 변경할 수 없다. 하지만 git merge origin/master등 과 같이 merge가 가능하다.