내가 작성한 코드와 작업물들은 현재 로컬 저장소에 저장되어 있다.
우리는 원격 저장소에 작업물을 관리하여 협업에 효율을 높일 수 있다.
이 원격 저장소 서비스를 제공하는 회사들이 여러군데 있지만 이 글은 github를 기준으로 작성한다.
원격 저장소와의 연결
github의 회원가입 후 repository를 생성한다. 이 repository가 원격저장소가 된다. 우리는 현재 작업하고 있던 로컬저장소와 원격저장소의 연결을 해야하는데 명령어는 아래와 같다.
-
git remote add <별칭> <주소> -
git remote add origin https://github.com/... -
잘 연결되었는지 확인하려면
git remote -v로 확인할 수 있다.
현재 로컬저장소의 내용을 원격저장소로 푸쉬(업로드)하기 위한 작업이 필요하다.
-
git push -
최초의 push는 원격저장소와 로컬저장소 어떤 브랜치와 연결을 할지 설정을 해주어야 하며
git push --set--upstream origin master로 설정한다.
origin/master
push후 로컬저장소에서 새로운 작업을 하고 commit을 하고 git log로 살펴보면 아래와 같다.
현재 로컬 master는 master 3의 작업을 바라보고 origin/master는 res를 바라보고 있다. 이 log의 의미는 아직 원격저장소에 push하지 않은 버전이 한가지 존재한다는 의미가 된다.
로컬저장소에서 push를 진행하게 된다면 아래와 같다.
pull(fetch+merge)/push
위에서 처럼 한 작업자가 원격저장소에 push를 했다면 다른 작업자는 pull을 사용해 로컬저장소의 내용을 원격저장소의 내용과 동일하게 만들 수 있다.
git은 같은 이름의 브랜치여도 git은 원격저장소의 브랜치와 로컬저장소의 브랜치를 다른 브랜치로 취급한다. 따라서 로컬의 master와 origin/master와는 같은 브랜치로 취급하지 않는다.
clone
-
git clone <remote address> -
git clone <remote address> .:.을 붙이면 현재 폴더에 복제가 된다. -
vscode에서는 소스컨트롤에서 GUI로 clone을 수행할 수 있다.
충돌
<상황> : 원격저장소(A)를 두명의 작업자가 clone했다. 작업자1이 one.txt를 push했다. 작업자2가 two.txt를 push하려고 할때 충돌이 일어날까 안일어날까?
<답> : 작업자2의 push는 거절된다. 현재 원격저장소는 one.txt가 추가된 commit을 바라보고 있다. 이 상태에서 작업자2가 two.txt를 push가 된다고 가정하면 원격저장소의 one.txt가 사라지고 two.txt만 있는 상황이 발생한다. 따라서 git은 이런 사고를 방지하기 위해 충돌을 일으키고 작업자2는 pull(fetch+merge)를 수행 후 push해야 한다.
-
fetch : 다운로드
-
merge : 합치기
pull은 원격저장소의 내용을 다운로드하고 현재 로컬저장소의 내용과 merge를 하는 과정을 거친다.
.gitignore vs. exclude
Tip
gitignore template 이 홈페이지를 사용하면 운영체제나 에디터별로 기본적으로 ignore하는 파일이 생성된다.
.gitignore에 등록하면 설정된 파일정보가 모두 공유가 되지만 .git/info/exclude의 파일을 수정하면 특정 파일이나 폴더를 무시할 수 있지만 공유는 하지 않을 수 있다.
Tag
HEAD나 브랜치는 언제나 이동이 가능한 동적이지만 Tag는 정적이다. 특정 버전을 표시하기 위해 사용하며 아래이 사용한다.
git tag <tag name>
commit에 이름을 붙이는 것이라고 생각하면 된다.
git checkout <tag name>으로 이동이 가능하다.
tag는 정적이기 때문에 이동시킬 수 없고 삭제하고 다시 생성하는 식으로 다뤄야한다.
fast forward
fast forward merge는 3way merge를 할필요없이 브랜치가 뻗어 나간 이후로 기존 브랜치에 어떠한 작업물이 없을때 기존의 브랜치의 위치만 옮기면 되는 병합방법을 말한다.
Pull requests(merge request)
github의 저장소에 가보거나 새로운 브랜치를 처음으로 push할때 위와 같이 pull request에 관한 메뉴나 링크가 뜬다.
그 링크로 들어가 보면 위와 같이 되어 있는데 내가 만든 브랜치를 마스터로 병합하기 전에 책임자에게 리뷰를 받는 요청서이다. 단순히 merge하지 않고 이런 절차를 거침으로 병합하려는 작업물을 확인하여 생길 수 있는 오류를 사전에 막는다.
좌측에 리뷰어와 책임자를 지정할 수 있으며 최종적으로 pull request를 요청하게 되면 아래와 같다.
실시간으로 commit현황이 반영이 되고 내 코드나 작업물에 대해 리뷰등을 확인할 수 있다.
최종적으로 책임자가 merge pull request버튼을 통해 병합을 하던가 로컬에서 병합하여 push하는 방법을 사용할 수 있다.
Pull request의 또 다른 기능은 현재 브랜치에서 작업하고 있는 파일이 master브랜치에서 수정이 되었다면 충돌이 났다는 경고를 알려준다.
따라서 master브랜치가 아닌 브랜치는 자주 업데이트를 해주어야 충돌을 방지할 수 있다.
branch 전략
github flow
github flow는 작업을 master브랜치에서 하지 않고 새로운 branch를 통해 작업하고 master와 합치는 전략을 갖는다.
git flow
github flow보다 훨씬 복잡한 방법으로 버전을 관리하게 된다.
master에서는 절대 작업하지 않고 delveop을 기준으로 작업이 이루어지게 된다.
