[git] 깃허브 정리

깃허브란

분산 버전 관리 툴인 깃을 사용하는 프로젝트를 지원하는 웹호스팅 서비스

 

깃이란

컴퓨터파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산버전관리시스템. 

소프트웨어 개발에서 소스코드 관리에 주로 사용되지만, 어떠한 집합의 파일의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다.

 

commit

자주 남겨주는 게 좋음

이제까지 어떤 코드를 짜왔는지 알 수 있다.

커밋메세지 잘 써주는 것이 중요

 

push

push를 하면 로컬에 있는 코드가 원격으로 올라간다.

 

pull

내가 push한 상태에서 동료 개발자가 pull하면 내 코드를 가져올 수 있다.

 

브랜치

한 레파지토리에 브랜치로 다양한 버전을 관리할 수 있다.

 

깃플로우

깃플로우 전략은 소프트웨어의 소스코드를 관리하고 출시하기 위한 브랜치 관리 전략

flow에서 사용하는 브랜치의 종류는 5가지이며, 메인브랜치와 보조브랜치로 나뉜다.

• Master : 제품으로 출시되는 브랜치
• Develop : 다음 출시 버전을 개발하는 브랜치
• Feature : 기능을 개발하는 브랜치
• Release : 이번 출시 버전을 준비하는 브랜치
• Hotfix : 출시버전에서 발생한 버그를 수정하는 브랜치

master과 develop를 제외한 나머지 브랜치들은 필요에 따라 만들어지고 삭제된다.

 

master에 기본 코드가 있고, 이를 develop에서 개발한다. 이 때 특정 기능만 개발해야하면 충돌의 귀찮음이 있을 수 있으므로 이를 위한 브랜치를 따로 판다.

 

Pull Request

따로 만든 브랜치에서 작업하고, 다시 develop에 추가하기 위해서 pr을 날린다.

이때 관리자가 merge해주면 해당 코드가 develop에 반영된다.

 

이슈

new issue 하면 해당 개발자에게 이메일이 간다.

이에 대한 답장을 해도 이메일이 간다.

이런식으로 할 일/ 완료한 일을 실시간으로 보여줄 수도 있다.

 

Local과 Remote

Local은 내 노트북 내에 있는 레파지토리이고, remote는 github상에 존재하는 repository이다.

local과 remote의 작업 내용을 변경하기 위해서 push와 pull을 사용한다.

 

Upstream과 Downstream, Origin

내가 정말정말정말 헷갈렸던 부분이다.

clone 했을 때 내 깃허브에 있는 레포가 origin으로 자동으로 설정된다.

upstream과 downstream은 상대적인 것이다. 따라서 origin과 로컬로 따지면 origin이 upstream이고, local이 downstream이다.

 

Fork

의문이었던 부분! 내가 fork 해온 레포에 있는 코드를 가져오려면 어떻게 해야하는가? 로컬에서 그 레포에 어떻게 닿을 수 있지? 에 대한 고민을 했었는데 답을 찾았다.

fork는 다른 사람의 레포를 내 소유의 레포로 복사해오는 것이다.

이 때 원래 소유자의 remote는 upstream, 내 remote는 origin이라고 한다고 한다.

 

그래서 기본 프로세스는 local에서 origin으로 push한 후 

PR을 등록하기 전 upstream에 바뀐 내용이 있으면 upstream을 local로 pull한 후 local에서 origin으로 push 하고 pr을 날리면 되고, 아니면, 그냥 upstream에 pr을 날려야한다.

 

HEAD

협업을 하면서 head라는 용어를 많이 봤는데 의미를 잘 모르겠었다.

HEAD란 해당 브랜치의 마지막 커밋을 뜻한다고 한다.

참고로 HEAD~n은 HEAD로부터 n개 이전 커밋을 참조하는 것이다.

 

Pull vs Fetch

이 둘의 차이도 궁금해서 찾아봤다. 

pull와 fetch 모두 원격에 있는 코드를 로컬에 다운받아온다. 이 때 pull은 현재 로컬에 있는 코드에 merge까지 하고, fetch는 merge하지 않아 개발자가 수동으로 병합해야한다.

fetch가 더 신중하게 merge할 수 있어서, 로컬과 원격 모두 코드 변동사항이 있을 때에는 fetch를 추천한다고 한다.

fetch를 하면 FETCH_HEAD라는 브랜치에 들어간다고한다. 예전부터 이 브랜치가 뭐지 했는데 이제야 알겠다.]

 

Merge vs Rebase

merge와 rebase 둘 다 두 브랜치를 병합할 때 사용된다. 

 

수작업ㅎㅎ

이런 브랜치 두개가 있다고 하자!

파란색이 master branch이다.

Merge

 

master 브랜치에서 merge를 하면 그림과 같이 두 브랜치의 commit 이력이 그대로 있고, c/1의 새로운 merge 이력으로 합쳐지게 된다.

 

rebase

위 그림은 모두 rebase 한 것이다. 

위 그림은 master 브랜치에서 rebase한 것이고, 아래 그림은 새로운 branch에서 merge한 것이다. 

그림에서 볼 수 있듯이 rebase하면 커밋이력에 이전과 다른 해쉬id가 부여된다. 즉 내용만 같고, 다른 커밋을 생성하는 것이다.

따라서 원격에 있는 코드를 rebase로 로컬에 가져오고 다시 push해서 merge 하면 코드가 엉망이 된다.

 

rebase는 커밋 이력을 보다 깔끔하게 보이도록 하지만, 병렬로 처리한 일들을 차례대로 수행한 것처럼 보이도록 할수도 있고, 위에서 언급한 위험성도 있어서 선호되지는 않는다.

 

https://www.youtube.com/watch?v=-27WScuoKQs

https://pers0n4.io/github-remote-repository-and-upstream/

GitHub에서 협업을 위한 remote repository와 upstream 이해하기

https://velog.io/@msung99/push-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EA%B9%83%ED%94%8C%EB%A1%9C%EC%9A%B0-pull

[Git] fetch 와 Pull 의 차이점은?

https://dongminyoon.tistory.com/9

[GIT] Merge vs Rebase 차이