git/github 실전편

victorydntmd.tistory.com/91

*해당 링크의 내용을 그대로 학습하고 표현하였습니다. 개인 공부를 위해서 업로드합니다.

 

A,B,C가 프로젝트를 한다고 가정하자.

 

편의상 소문자로 적자면

1. a가 깃헙에 레포지토리를 생성하고 b,c를 초대한다.

(collaborator로 등록)

 

2.a가 프로젝트 파일을 받아올 수 있도록 깃헙에 올린다.

git init 로컬레포지터리 만들기
git add . staging area로 옮기기
git commit -m "initial project" 커밋하기
git remote add origin github-url 원격레포지터리와 연결하기
git push origin master 연결된 원격레포지토리로 로컬레포지토리의 내용을 전달하기
 

 

3.b,c가 깃헙의 프로젝트 파일을 로컬레포지토리로 가져온다.

git clone github-url

 

4.a,b,c는 자신이 맡은 기능 구현을 하기 위한 브랜치를 만든다.

git branch addA
git branch minusB
git branch mulC

 

[*branch]

victorydntmd.tistory.com/75 참고.

1)master branch는 git init시 자동으로 생기는 기본 브랜치다.

1-1)master branch를 a,b,c의 작업 내용을 하나로 합칠 때 사용하는 뼈대 브랜치로 사용할 수 있다.

 

2)새로운 branch는 "기능 구현을 위한 독립적인 작업 공간"이다.

2-1) 작업을 진행하면서 테스트가 필요하거나 여러 버전으로 구현해보고 싶을 때 사용한다.

 

3)명령어 연습

git branch 브랜치 목록 확인

git branch branchName 새로운 브랜치 생성(부모 브랜치를 그대로 복사한다)

git checkout branchName 브랜치를 이동한다.

git branch -a 로컬/원격 모든 브랜치를 확인할 수 있다.

 

예시.

git branch foo 브랜치foo 생성
git checkout foo 브랜치foo로 이동

 

5. 현재 a,b,c는 깃헙을 공유하고 있고, 각자 독립적인 레포지토리를 가지고 있다.

각자의 로컬 레포지토리에 새로운 기능구현을 위한 브랜치를 가지고 있는데, 여기서 각자 맡은 기능 구현을 마칠 수 있다.

각 기능을 끝낼 때마다 깃헙에 자신의 브랜치 작업본을 push한다.

 

실제로 기능 구현을 끝낸 브랜치를 master branch에 병합해보자.

현재 b브랜치에 있다고 가정.
git add .
git commit -m "complete b function"

git checkout master
git merge b
git push origin master 병합된 마스터 브랜치를 원격으로 push해준다.

깃헙의 마스터 브랜치에 push하기 전에, 자신의 로컬 레포지터리에 있는 마스터 브랜치에 비 브랜치를 병합하였다.

그리고 병합된 로컬 레포지터리의 마스터 브랜치를 깃헙의 마스터 브랜치로 push하였다.

 

6.a,c는 b가 올린 최신 프로젝트 파일을 가져와서 작업진행한다.

git checkout master
git pull origin master
마스터로 이동하여 최신 프로젝트 파일을 가져오고

다시 작업중인 브랜치 a로 이동해서 최신 프로젝트 파일을 반영한다.
git checkout branchA
git merge master

 

[*merge & conflicts]

victorydntmd.tistory.com/78 참고.

merge시 주의해야할 점은 conflit다.

기존의 코드와 병합되는 코드가 같은 위치의 코드라면, 사용자가 선택할 수 있게 conflit를 발생시켜준다.

 

1)merge하는 방법

git merge (대상브랜치) 현재 브랜치에서 대상 브랜치를 병합시킨다.

 

master branch, test branch가 존재하고, test branch에 추가된 코드가 있다고 가정하자.

test branch는 한번 더 커밋을 한 상태이다.

마스터 브랜치에 테스트 브랜치를 merge하기 위해서 마스터 브랜치로 이동한다.

git checkout master
git merge test

이때 fast-forward 주의!

(fast- forward : 기존 브랜치보다 병합할 대상 브랜치의 커밋이 앞서 있어서 기준 브랜치의 커밋을 대상 브랜치의 커밋으로 이동하겠다는 소리다. 마스터 브랜치는 커밋이 1이지만, 테스트 브랜치는 수정을 가하고 커밋을 한번 더 했기때문에 커밋이 2인 상태다. 따라서 merge하면 마스터 브랜치의 커밋도 2가 된다.)

 

 

2)conflict를 해결하는 방법

같은 파일의 같은 부분을 수정하면 충돌이 발생한다.

 

마스터 브랜치와 테스트 브랜치의 커밋 횟수가 같고, 같은 부분을 수정하여 충돌이 발생했다고 가정하자.

이때, 동료들과 충돌을 해결하도록 하자. 수동으로 작업해주면 된다.

 

<<<<<<< HEAD 부분은 기존 브랜치의 영역을 의미한다.

 

*유용한 팁

1) --squash

git merge --squash child

자식 브랜치를 5번 커밋했다고 했을 때, squash를 이용하여 병합하면 자식 브랜치의 커밋이 무시되고 

파일 수정 이력만 받게 된다.

-> git log --oneline --graph 로 확인 가능하다.

 

 

7.버그가 발생하여 이전 버전으로 돌아가야 하는 경우

victorydntmd.tistory.com/79#diff 참고

a,b,c가 작업을 잘하고 있는데 버그가 발생하여 한참 전으로 돌아가야 하는 상황이 발생한 경우

 

1)로컬에서만 작업 중 발생한 경우

reset : 되돌아가는데 커밋이력이 사라진다.

revert : 되돌아가는데 커밋이력이 남아있다.

 

git reset --hard 버전명

해당 버전으로 전부 돌아간다. 그리고, 그 위의 버전은 전부 사라진다.

 

git revert 버전명

(이해 x)

 

2)깃헙에서 작업 중 발생한 경우

revert만 사용할 수 있다. reset을 사용하면 커밋 이력이 삭제돼서 원격저장소와 싱크가 맞지 않아서 push할 수 없다.

 

3)working directory 비우기 - add 명령어를 하지 않은 상태에서 가장 최근의 커밋상태로 되돌리고 싶은 경우

 

저장했다고 가정해보자

git add 
git commit -m "inital commit"

이제 수정을 가했다면 add를 해야하는데 하지 않았다고 해보자

git status

add해야한다고 분명 나올 것이다.

이때, 수정 전으로 되돌리고 싶다면??

파일만 되돌리고 싶다면, git checkout -- 파일이름
전체를 돌리고 싶다면, git checkout .

 

4) add를 무력화하기 그러니깐 staging area를 버리고 최근 버전으로 돌아가는 방법

git reset 파일이름

예를 들어서 git reset .