git과 github를 이용한 협업
-
개인 repository에 collaborator 추가
-
하나의 repository를 여러 사람이 나눠서 사용하기 때문에 상태가 꼬일 여지가 많다.
보통 오픈소스 프로젝트를 공동관리할 사람을 두기 위해서 사용하는 방법이기 때문에 추천하는 방법은 아니다.
-
-
Team organization 생성
repository 생성 후, Issues에 해결해야 될 문제, 어떤 걸 진행할지에 대해서 작성한다.
해야 할 일에 대한 Issue를 생성하고, 그 Issue에 맞게 작업을 진행하는 것이 좋다.
기본 세팅
- 모두가 같은 양식으로 작성할 수 있도록 template을 생성
- git flow를 사용하기 위한 준비 → git flow init
- 프로젝트 셋업 → touch fizzbuzz.py
- 불완전한 코드를 commit하면 안 된다!!
- 첫 push를 할 때엔 -u 플래그와 함께 한다.
위와 같이 모든 세팅을 마친 후에 팀원에게 알린다.
invite된 멤버들이 organization의 repository에 직접적으로 기여(commit, push)를 하게 되면 안전하지 않다.
이를 방지하기 위해 fork&merge 방식을 사용하여 간접적으로 기여할 수 있도록 한다.
- fork : repository의 사본을 만드는 것
fork&merge
organization의 repository를 자신의 repository로 fork해온 뒤에, git flow 방식으로 작업을 진행한다.
-
로컬의 develop 브랜치에서 작업
- develop 브랜치에서 feature 브랜치를 만들고 작업한다.
- 개발을 한 뒤엔 develop 브랜치에 feature 브랜치를 merge한다.
- 위와 같이 develop 브랜치와 feature 브랜치를 왔다갔다 하며 작업한다.
-
organization의 develop 브랜치에 반영하기 위해 pull request
- base repository에 head repository를 merge한다.
즉, base = organization / head = 로컬
사본을 가져와서 작업한 것이기 때문에 merge하려는 브랜치와 상태가 같아야 된다
→ 브랜치 체크 필수!! - pull request message를 남길 때, resolve/fix/close 를 통해서 base repository의 issue와 연결할 수 있다.
- resolve/fix/close 모두 현재형, 복수형, 과거형으로 작성할 수 있다.
ex) resolves / resolved / fixed ~
- resolve/fix/close 모두 현재형, 복수형, 과거형으로 작성할 수 있다.
- base repository에 head repository를 merge한다.
-
(organization 팀장)merge된 코드에 대해서 리뷰
- comment : 의견
- approve : pull request 수락
- request changes : review 내용 추가 작업할 때까지 request 안 받아주겠다
-
리뷰 내용에 대해서 수정(수정할 내용이 있어서 리뷰 결과가 request changes라는 가정)
로컬의 develop branch에서 작업 후 push한다.
- Pull Request가 Open 상태일 때, 로컬의 develop branch에 push를 하면 변경사항이 pull request에도 바로 적용된다.
- pull request가 계속 open 되어 있으면, pull request와 상관 없는 작업 단위가 적용될 수도 있다는 것을 주의해야 된다.
-
수정 사항에 문제 없다면 merge를 받는다.
merge 잘못 됐다면, revert 가능
organization의 변경 사항을 update하고 싶다면?
- 로컬에서 organization의 repository 주소를 원격 저장소로 추가한다.
git remote add upstream <repository 주소>
- organization을 통상적으로 upstream이라고 한다. - 변경사항을 땡겨온다.
git pull origin develop git pull upstream develop- fetch&merge → upstream의 develop 브랜치를 FETCH_HEAD라는 임시 헤드를 만들어서 넣어놓은 뒤에, HEAD와 merge 한다.
git fetch upstream develop
git merge FETCH_HEAD
git mv
리눅스의 mv 명령어를 통해 파일명을 revert.md에서 reverted.md로 바꿨을 때, git status 명령어를 사용해서 상태를 확인해보면 revert.md가 삭제되고, reverted.md가 새로 생성된 것으로 인식한다.
이를 방지하기 위해서는 명령어의 앞에 git을 붙여줌으로써 git이 이를 탐지할 때, 삭제 후 생성이 아니라 rename으로 인지할 수 있도록 한다.
- reverted.md의 파일명을 다시 revert.md로 바꾸면 git은 변경 사항이 없는 것으로 인식한다.
기존에는 add를 하여 stage에 올린 뒤에 commit을 했는데, rename을 했을 때는 이미 정의된 것에 대해서만 변화를 주는 것이기 때문에 add를 하지 않아도 stage에 올라가있다.
undo
git restore reverted.md : reverted.md 파일의 변화 내용을 되돌린다.
unstaging
git reset HEAD reverted.md : add 명령어를 통해 staging 했던 reverted.md 파일을 stage에서 내린다.
- HEAD : git에서 HEAD란 최신의 상태를 뜻한다.
edit commit
commit은 blob과 tree로 구성되는데, blob은 add를 올리면서 정해지고, tree에 대해서 변경할 수 있다.
git log : commit message, commit id를 확인할 수 있다.
- 모든 커밋은 고유값(id)을 가지고 있다.
직전의 commit message를 수정하고 싶다면? git commit --amend
push를 한 순간부터는 수정하기 쉽지 않기 때문에 push를 많이 하지 않는 습관을 들이자. commit을 쌓아놓다가 누군가에게 보여줘도 된다는 생각이 될 때만 push 하자.
- 잦은 push는 인터넷 낭비!
Reset vs Revert
Reset : 과거 이력을 깔끔히 없애버린다 → commit log tracking이 힘들어진다.
- solution : 잘못한 이력도 commit으로 박제하고, 수정한 이력을 남기자! → revert
Revert : 잘못하기 전 과거로 돌아가 최신을 유지하면서 되돌렸다는 이력을 commit으로 남긴다.
- 실수를 없던 일로 만들기보다는 실수를 남겨두고, 정상적으로 되돌려놓자. → 모든 팀원이 이 사항을 공유하고 주지시킬 수 있다.
