* 풀 리퀘스트(Pull Requests, PR)

피처 브랜치에서 작업한 내용은 언젠가는 누군가에 의해 main 브랜치로 병합이 될 것이다.

다만 여기서 누구나 main 브랜치에 푸시 및 병합을 하게 된다면 문제가 발생하기 때문에 작업물 검토를 요청해서 병합을 승인하거나 반려해달라고 할 수 있다.

브랜치를 병합할 때, 빨리 감기 또는 충돌에 의한 병합 커밋이 만들어 지는것을 알고있다.

PR 역시 병합이기 때문에 충돌 발생시 처리를 해주어야 한다.

파일이나 수정사항이 몇개 되지 않는다면 깃허브의 웹상에서 처리할 수 있지만 작업량이 많다면 깃허브에서 처리하는것은 불편하므로 로컬에서 처리하는것이 편할것이다.

기본적인 처리 과정은 로컬에서 빨리 감기 여부와 관계 없이 병합 커밋을 만들어서 main 브랜치에 푸시하는 것이다.

추가로 PR은 깃의 기능이 아니라 깃허브같은 원격 저장소의 기능이다.

* 브랜치 보호 규칙 설정

main 브랜치같이 엄격하게 관리되어야 하는 브랜치에 규칙을 설정하여 엄격하게 관리할 수 있다.

* Fork란?

다른 원격 저장소를 나의 원격 저장소로 복사한다.

클론이 원격 저장소를 나의 로컬 저장소에 복사하는 것이라면 포크는 원격 저장소를 나의 원격 저장소에 복사하는 것이다. 둘의 차이는 클론은 공동 작업자로 등록되지 않는이상 푸시 권한이 없다는 것이지만 포크는 나의 원격 저장소이기 때문에 권한이 있다.

마치 로컬-원격의 관계처럼 원격-원격 관계가 성립한다. 정확히는 로컬-원격-원격일 것이다.

그렇기 때문에 포크해온 나의 원격 저장소에 변경된 작업을 푸시하고 해당 브랜치를 원래 프로젝트에 PR할 수도 있다.

기본적으로 원격 저장소에 참여해서 푸시할 권한을 가지려면 공동 작업자로 등록하는 절차가 반드시 필요하다.

하지만 규모가 매우 큰 오픈 프로젝트의 경우라면 매번 공동 작업자로 등록하는 절차가 번거로울것이다. 이 때 원격 저장소를 포크해서 변경사항을 PR한다면 기여자로써 등록이 된다.

Fork 역시 PR과 마찬가지로 깃의 기능이 아니다.

마크다운이란?

형식화된 텍스트를 만드는 간결하고 편리한 구문이다.

텍스트를 HTML로 변환시켜준다.

구문을 매우 간결하고 쉽게 작성할 수 있다는 장점이 있다.

https://markdown-it.github.io 

이곳에서 데모를 작성해 볼 수 있다.

* Fetching

내가 로컬에서 작업하는 동안 다른 인원들이 작업한 것들이 원격 저장소에 올라간 경우가 있을 수 있다. 협업 과정에서는 매우 흔한 일일 것이다.

이 때, 내 작업 영역을 망치지 않으면서 변경 사항에 접근할 수 있도록 하는 명령어가 fetch이다.

원격 저장소에서 변경 사항을 가져오지만 작업 파일에 통합하지는 않는다.

* Pulling

Fetching과 다르게 HEAD 브랜치를 업데이트 한다. 작업 영역이 업데이트 된다는 얘기이다.

간단하게 정리하자면 fetch+merge 이다.

매우 중요한 점이 있는데, 현재 HEAD가 위치한 브랜치에 풀링이 적용 된다.

$ git pull origin movies

원격 저장소의 movies 브랜치를 풀링한다는 의미이다. 의도하는 것은 로컬 저장소의 movies 브랜치에 풀링하는 것인데 만약 HEAD가 main이라면 main 브랜치에 풀링이 되어버리므로 조심해야한다.

fetch와 다르게 origin/movies와 movies브랜치가 병합되었다. 위와 같은 경우는 충돌이 발생하지 않았으므로 빨리 감기 병합이 이뤄졌다.

로컬 브랜치와 원격 브랜치가 추적되도록 설정되었다면 명령어를 간소화 시킬 수 있다.

$ git pull

main 브랜치에서 실행했다면 원격의 main 브랜치를 풀링한다.

추가로 원격 저장소에 푸시하기 전에 풀다운 하여 변경 사항을 확인하는 습관을 들이는것이 좋다.

git clone <url>

로컬에 없는 저장소를 가져온다.

깃허브의 공개 저장소에 있는 것들은 모두 클론이 가능하다. 단, 푸시는 불가능하다.

그리고 거의 대부분의 경우에 깃허브가 쓰일 뿐이지 깃허브만 가능한것이 아니다. git clone 명령어도 github와 관계가 없다.

* SSH키 설정 및 깃허브에 등록하기 (Windows 기준)

깃허브 가입이 완료된다면 SSH키를 설정해야한다. 그래야 매번 로그인을 하지 않고도 인증할 수 있기 때문이다.

SSH키가 있으면 그걸 사용하면 되고 없다면 터미널 명령어로 생성시켜 주어야 한다.

$ ssh-keygen -t ed25519 -C <email>
> Generating public/private ALGORITHM key pair.

암호 설정까지 끝내고 생성을 완료했다면 SSH 에이전트를 실행시켜서 키를 추가시켜 준다.

$ eval "$(ssh-agent -s)"
> Agent pid ****

$ ssh-add ~/.ssh/id_ed25519
> Identity added: /c/User/../.ssh/id_ed25519 (email)

깃허브에서 SSH키를 등록하기 위해 공개키를 복사 한다.

$ clip < ~/.ssh/id_ed25519.pub

깃허브의 Setting - [Access] 의 SSH and GPG keys 페이지로 이동해서 "New SSH key" 를 클릭해서 복사한 키를 입력하고 제목을 정해주면 완료된다.

과정이 번거롭지만 디바이스별로 딱 한번만 등록해두면 다시는 할 필요가 없다.

* 로컬에 기존 저장소가 있는 경우

1. 깃허브에서 새 저장소를 만든다.
2. 로컬 저장소에서 원격을 만든다.
3. 푸시한다.

* 아직 작업을 시작하지 않은 경우

1. 깃허브에서 새 저장소를 만든다.
2. 클론한다.
3. 푸시한다.

remote는 깃에게 알려줄 url에 이름을 붙인것이다.

git push <remote> <branch>

깃에게 대상 저장소 및 푸시할 브랜치를 알려준다.

git push origin main 은 정말 흔하게 사용하는 명령어이다.

원격 유무를 포함한 정보를 확인한 후에 push를 실행하면 아무것도 없던 저장소에 파일들이 추가된다.

로컬에서 작업하던것을 깃허브에 올린것이기 때문에 로컬에서 작업했던 브랜치의 이력들이 모두 올라간다.

현재는 main 브랜치만 푸시했기 때문에 main 브랜치만 존재한다.

git push <remote> <local-branch>:<remote-branch>

기본적인 푸시는 로컬 브랜치가 원격 저장소에 존재하지 않으면 새로 생성하고 그 이후에는 같은 브랜치에 푸시되는 방식이다. 즉, 로컬 A브랜치를 원격 저장소의 A브랜치로 푸시하는 것이다.

여기서 로컬 브랜치와 원격 저장소의 브랜치를 다르게 설정할 수 있다. 로컬 A브랜치를 원격 저장소의 B브랜치로 푸시할 수 있다는 것이다.

일반적으로 자주 사용되는 명령어는 아니다.

git push -u <remote> <branch>

upstream의 약어이다. 로컬 브랜치를 원격 브랜치에 연결시킨다.

# local의 main을 origin의 main에 연결한다
$ git push -u origin main

연결시키고 난 뒤에는 git push 명령어 만으로도 푸시가 가능해진다.

보통은 main 브랜치를 처음 푸시할 때 사용한다.

로컬 브랜치와 깃허브의 브랜치는 다르다는 것을 인지해야한다.