Remote

clone vs. pull

Remote repository

remote | Local => Remote 

local repository에서 commit한 내용들을 서버에 업로드 하기 위해서, 먼저 github에 repo를 만들어야 한다. 

 

원격 저장소의 주소 확인하기

 

git remote add origin 주소 | 현재 local에 기록되어 있는 내용을 remote 저장소에 연결(add)한다. 저장소의 주소는 "origin" 이라는 이름(변수)에 할당된다. 

• 여러 개의 원격 저장소 주소를 연결할 수도 있다. 
• 로컬과 동기화하는 원격 저장소의 이름은 주로 "origin"으로 설정한다. 
• 이제 로컬에서 history를 확인할 때, origin/master를 볼 수 있는데, 이것은 서버(origin)에 등록되어 있는 master 브랜치라는 뜻이다.  

 

git remote remove 이름 | 이름에 해당하는 원격 저장소와의 연결을 제거한다

 

git remote | 서버와 관련된 정보 확인 => 저장소 이름(origin)

git remote -v | 저장소 이름이 가리키고 있는 http 주소 확인 가능

git remote show 이름 | 이름에 해당하는 원격 저장소의 자세한 정보 확인 가능 

 

clone | Remote => Local 

git clone 주소 폴더이름 | 서버에 이미 업로드된 repository를 로컬로 가져오기

• 깃 프로젝트 폴더가 생성된다
• git remote -v를 확인해 보면, 나의 local과 주소에 해당하는 remote repo가 저절로 연결되어 있음을 확인할 수 있다. 

 

origin/main

origin/main, origin/HEAD가 가리키는 것은 Remote repo에 저장되어 있는 커밋이고, HEAD->main이 가리키고 있는 것은 서버에 아직 업로드 되지 않은, 나의 local에서 등록한 커밋이다. push명령어를 이용하면 local => server로 커밋을 등록하는 것이 가능하다. 

 

push & pull, fetch

 

push & pull

 

 

push

git push -u origin master | 로컬에서 작업한 현재 브랜치를 원격 저장소(origin)의 master에 동기화

• -u 옵션은 local의 브랜치와 remote의 master 브랜치를 연결하는 옵션으로, 최초에 한번만 사용한 뒤에는 git push만 작성하면 된다.
• username과 pw를 입력하면 remote repo에 push된다. 

 

git push error 

rejected push

• 내가 local에서 작업한 내용을 push할 때, remote repo에 새로운 커밋이 추가로 등록되어서 local과 remote의 동기화가 이루어 지지 않았다면, reject가 발생한다. 
• git push -f | force, 서버의 커밋 내용을 모두 삭제하고, local에 있는 커밋을 등록한다.
  • pull / fetch => rebase => push를 하는 것이 알맞은 방법이다.

 

아이디와 비밀번호를 입력하지 않고 Push 이용하기

 

SSH | Secure Shell Protocol

깃허브에 push할 때 마다 아이디와 비밀번호를 입력해야 하는 번거로움이 있는데, terminal에서 server의 아이디와 비밀번호를 안전하게 유지하는 방법이 있다. 

+) SSH 추가한 다음에 push할 때 wincred 옵션 선택했더니 알아서 push해 줌

 

GCM | Git Credential Manager 나는 push 하니까 credential helper selector라는 게 뜨고, manager-core를 선택하니까 로그인 안해도 바로 커밋을 push하는 게 됐다.

 

pull & fetch

fetch와 pull은 server에서 업데이트 된 commit을 나의 local에 불러온다는 점에서 같다.

 

git fetch | 서버에 업데이트 된 내용을 나의 로컬로 가져온다. 

• local의 현재 브랜치(master)가 가리키고 있는 커밋과, server의 브랜치(origin/master)가 가리키고 있는 커밋이 다르다. 즉 현재 브랜치는 여전히 local에서 작업 중이었던 최신 커밋을 가리킨다. 
• git fetch origin 처럼 등록한 remote 주소에 따라 fetch할 수도 있다. 

 

git pull => git merge => git mergetool

 

git pull | 서버에 업데이트 된 내용을 나의 로컬로 가져온 뒤에 merge한다( pull = fetch + merge ). 

• local의 현재 브랜치(master)가 가리키고 있는 커밋과, server의 브랜치(origin/master)가 가리키고 있는 커밋이 같다. 서버에서 업데이트 된 내용에 local에서 작업한 commit을 자동으로 merge하기 때문이다. 즉 나의 현재 브랜치와 서버의 브랜치가 똑같은 커밋을 가지고 있는 브랜치(===동기화)로 만든다. 
• 이 때, 내가 작업하는 파일과 동일한 파일을 수정한 내용이 포함되어 있으면, merge conflict이 발생할 수 있다.
  • 나는 이런 상황에서 pull 명령어를 이용했을 때 auto merge가 안되면, branch로 갈라지기만 하고, merge는 일어나지 않았다.
  • pull을 한 다음에 merge를 입력하면 그 때 merge conflict이 발생했고, 수동으로 충돌을 해결했다. 
  • 3 ways merge 되므로 rebase를 이용할 수 있다. 

 

git pull --rebase | 현재 브랜치에서 등록한 베이스 커밋을, 서버의 최신 커밋으로 rebase한다. 

 

• 우선 reflog와 reset을 이용해서 HEAD를 local update 커밋으로 되돌린다(즉, merge 이전으로 되돌린다).
• 그런 다음 현재 내가 작업 중인 브랜치에서 git pull --rebase를 이용한다. 내가 작업한 커밋만 다른 커밋으로 바뀌고, 서버에 등록된 커밋은 바꾸지 않는다(그대로 유지된다).
• rebase는 base를 바꾼 뒤에 ff merge를 하는 명령어이므로, merge conflict이 발생할 수 있다.
• 충돌을 해결한 다음 git rebase --continue를 작성한다. 
• git push 명령어를 입력해서 로컬과 서버를 동기화한다. 

 

??? 이 때 중간에 HEAD Detached 상태가 되는데 멀쩡하게 잘 merge 된다. 

 

pull --rebase