GIT 협업하기

Revert

File Rename

$ git mv origin.md rename.md	##파일의 history를 남김

## 물리량의 변화가 생긴 것이 아니므로 스스로 git add 되어 바로 commit을 수행할 수 있음.

git mv 대신 mv 명령어를 이용하면 안될까?

mv 명령어를 사용할 경우 origin.md 파일을 삭제한 후, rename.md를 생성하는 것과 같으므로 2개의 작업단위가 발생하여 git mv 명령어를 사용하는 것이 적절하다.

commit 취소하기

$ git restore (file_name)

$ git checkout -- (file_name)

##현재 위치 아래에 모든 변화량을 취소하고 최신 commit으로 돌려 놓기
$ git restore .		

서로 다른 작업 단위의 commit 취소

$ vi README.md		## docs 작업

$ vi function.md	## 기능 작업

$ git add . 		## 2개의 작업단위가 한 번에 staging area에 올라감

## 다른 작업단위가 발생했기 때문에 2개의 commit을 수행해야 함
$ git reset HEAD README.md		##README.md파일만 내림

Revert로 commit 취소하기

## 파일 3개를 생성하고 각각 commit
## 잘못된 commit을 하기 전으로 되돌려야 함.

$ git revert --no-commit HEAD~3..

$ git commit

## 어떤 문제가 발생했고 왜 그랬는지에 대한 기술이 필수적임

Git 협업하기

Collaboration

초대된 사용자가 본인인 것처럼 행동할 수 있게 초대하는 것으로 하나의 repository를 둘 이상의 사용자가 사용하기 때문에 상태가 꼬이는 상황이 발생할 수 있다.
따라서, 오픈 소스 프로젝트에서 repository 관리자를 두기 위해 사용하는 경우가 많고 협업에서 사용하기에는 적절하지 않다.

Fork & Merge

PM's TO-DO

- New organization을 생성

- 이름을 선정하고 팀원을 초대

- New Repository를 생성

- issues의 템플릿을 생성하여 백로그를 작성

- local 저장소에 clone하여 git flow를 수행

- 새로운 파일을 생성하여 remote 저장소에 push 후 팀원들에게 open

- pull request를 확인하여 code review

DT's TO-DO

- issues에 백로그 작성 후 fork

- local 저장소로 clone하여 git flow 수행

- develop branch에서 feature branch를 생성하여 안전하게 작업 수행 후
develop branch로 merge

- remote 저장소로 push하고 pull request 수행( develop branch to
develop branch )

- review에 대한 수정 후 다시 push

협업 시 주의해야 할 점

여러 사용자의 작업이 수행되기 때문에 일정 시간이 지나면 PM의 업데이트된 작업을 가져와야 함.

$ git remote -v

$ git remote add upstream (PM's_address)

$ git fetch upstream develop

$ git merge FETCH_HEAD

## 업데이트 완료

$ git pull upstream develop

pull 명령어는 다른 작업과의 충돌을 일으킬 수 있기 때문에 사용하지 않는 것이 좋다.