git 정리

외부 저장소에 저장했을때의 이점

1. 로컬컴퓨터에 문제 발생 시 프로젝트 복구 가능
2. 협업 및 버전관리 가능

외부 저장소를 제공하는 서비스에는 깃허브, 깃랩, 비트버킷 등이 있음.

 

 

---

 

• git log : 커밋 내용 확인
• git reflog : 모든 commit 내역 및 head 확인 가능(ex. HEAD@{0})

git log는 head가 가리키는 커밋부터 그 이전의 커밋들만 보여줌 -> head이후의 커밋은 볼 수 없음
이때 git reflog를 사용하면 커밋 head를 변경한 내역을 확인 가능: head숫자가 작을수록 최근 기록을 나타냄
git reset --hard HEAD@{number} 같은 형식으로도 쓸 수 있음!

 

• git status : 더 자세하게 git의 상태를 확인할 수 있음. 
                새로 생성했거나 내용을 수정한 파일이 Staging Area에 잘 올라갔는지 확인하기 위해 사용.
• git reset : 원하는 커밋으로 head 이동. HEAD가 가리키는 commit의 모습으로 working directory의 모습이 바뀜.                    이 명령어를 통해 커밋을 남기지 않고 이전 커밋으로 돌아갈 수 있음.

[옵션]

1. --hard : 로컬의 working 디렉토리 자체를 바꿈.
2. --mixed : 로컬의 working 디렉토리는 변화 없음. working 디렉토리를 바꾸지 않음. staging area를 바꿈.
3. --soft : working 디렉토리를 바꾸지 않음. staging area를 바꾸지 않음.

 

• git revert : 이전 커밋을 취소함. 취소 내역을 커밋으로 남김.
• branch: 특정 커밋을 가리키는 포인터
  하나의 프로젝트에서 서로 다른 프로젝트의 흐름을 병렬적으로 가져가기 위해 사용.
  가지를 나누어 개발하다가 하나의 프로젝트로 합칠 수 있음.
  git branch branch_name을 통해 새로운 브랜치 생성 가능.
  git checkout branch_name을 통해 head가 가리키는 브랜치를 변경할 수 있음.
• git pull : 다른 개발자가 commit한 내역들을 자신의 로컬저장소로 끌어와 로컬 저장소와 동기화함. 원격 저장소의 브랜치 내역들은 끌오지 않음.
• git remote update : 원격 저장소의 브랜치 내역을 끌어옴.
• git fetch : 원격 저장소의 커밋 내역을 끌어오기만 하고 워킹 디렉토리는 바꾸지 않음.

 

'git remote add 별명(보통 origin) 원격저장소주소' 를 통해 원격저장소에 접근 가능

 

• 'git push -u 별명 master' : '-u'명령어를 포함하여 push하고 나면 그 다음부터는 git push, git pull만 하더라도 자동으로 로컬 컴퓨터의 mater 브랜치에 대해 깃랩 서버의 master 브랜치를 대상으로 작업을 수행함. 원격 저장소의 master 브랜치에 로컬파일 저장.

깃허브 등에 관리되는 프로젝트는 로컬프로젝트의 .git 디렉토리 내부에서 관리되는 repository영역을 업로드하는 것이기 때문에 커밋 내용까지 함께 관리 가능함.

 

*주의할 점*

1. 원격 저장소의 커밋 내역과 로컬 저장소의 커밋 내역이 다르면 즉, 원격 저장소의 새로운 커밋 내역을 로컬 저장소에 반영하지 않은채 로컬 프로젝트를 수정한 후 커밋하여 push하려하면 오류가 생김 -> 원격저장소와 로컬 저장소 커밋 히스토리가 다르면 충돌이 발생하여 업로드 불가(fail 발생)
2. 원격 저장소의 프로젝트가 항상 기준 프로젝트이기 때문에 로컬 프로젝트로 원격저장소 프로젝트를 덮어쓰는 것은 보통 허용되지 않음. 이를 위해 새로운 작업을 시작하기 전, git pull을 하여 원격 저장소의 새로운 커밋들을 로컬 프로젝트에 반영해야함.
3. 반드시 commit, push를 하기 전 git pull을 해야함.

 

• git --all --grahp : --all은 head가 가리키는 브랜치 뿐만 아니라 모든 branch를 표시해달라는 명령어.
                         --graph는 브랜치와 커밋의 관계를 그래프 형식으로 표시해달라는 뜻
• git merge branch_name: 현재 브랜치에 branch_name브랜치 합치기

fast forward merge: 합병을 할 때 새로운 커밋을 만들지 않고 head브랜치가 합병하려는 target 브랜치로 당겨오는 것
-merge를 시도할때 새로생긴 commit과 충돌이 생기면 해당 파일을 열어 내용을 수정 후
 git add, git commit을 수행해주면 됨 -> 이 경우에 새로운 커밋이 생기면서 합병을 함.
-git push -u origin master에서 "-u"옵션은 로컬 컴퓨터의 master 브랜치가 항상 깃랩 서버의 master 브랜치를 바라보게 하라는 뜻


*실제 협업 과정*
1. git fork를 통해 원본 프로젝트를 자신의 깃랩 영역에 복제
2. git clone을 통해 자신의 깃랩 영역의 프로젝트를 로컬 프로젝트로 옮겨 작업함
3. 작업 완료 후 자신의 깃랩 영역에 git push한 후 merge리퀘스트를 보내야 함
sesttings -> General -> Merge Request에서 merge에 관한 정책을 관리할 수 있음

1. Merge Commit: fast-forward merge가 가능할 때도 새로운 커밋을 만듦. 항상 새로운 커밋을 만들어 merge함
2. Merge commit with semi-linear history: merge request를 요청했을 때 fast-forward merge가 가능한
경우에만 merge를 허용 -> but 항상 새로운 commit을 만들면서 merge함.
3. Fast-forward: fast-forward merge가 가능하다면 fast-forward merge를 수행

정책 1과 2의 차이: fast-forward merge를 할 수 없는 상황에서 정책 1은 어떤 상황에서든 새로운 commit을
만들며 merge를 수행하여 딱히 문제가 생기지 않지만 정책 2는 rebase작업을 해야만 merge가 허용되는 경우가 생김.
        *rebase: 새로운 터를 잡다, 출발점을 재설정하다 라는 뜻. commit history의 구조를 좀 더 보기좋게 변경시킴.
정책 2는 rebase작업이 필요하다는 단점이 있지만 commit history를 보기좋게 관리할 수 있다는 장점이 있음.
정책 2와 3의 차이: 정책 3도 rebase가 사용되지만 새로운 commit을 반드지 만들게 되는 것이 아님.
but 정책 3은 branch가 갈라지고 합쳐지는 흐름을 정확히 파악하기 힘듦.


Fast-forward merge를 선택하면 fast-forward merge가 가능할 땐 fast-forward를 함.
이미 지나간 commit로그를 바꾸려면?
git push --force를 하여 원격저장소의 프로젝트를 현재 커밋으로 덮어쓸 수 있음(실무에서 절대 사용하지 않음)

처음 브랜치를 push할 땐 git push --set -upstream origin branch_name 형식의 명령어를 입력해주어야 함
보통 깃에서 원본프로젝트를 가리키는 별명은 upstream이라고 함
ex) git remote add upstream 저장소주소
git remote -v : 프로젝트가 인식하고 있는 깃랩 프로젝트를 확인 가능
git pull upstream develop: 원본 프로젝트의 develop 브랜치에 있는 신규 커밋들을 가져옴
git merge develop: develop브랜치의 최신 커밋을 merge함.
head가 브랜치로부터 분리되어 직접 커밋을 가리키는 상태를 detached 상태라고 함

git log --all --graph --online : 커밋 내역을 좀 더 깔끔하게 볼 수 있음
rebase 명령어 수행 후 충돌로 파일 수정한 다음
git add .
git rebase --continue : 충돌로 인해 프로젝트를 최신 모습으로 수정 한 후 리베이스를 다시 수행하라는 명령어
vim창이 나오면 :wq입력 후 나오기
git push --force를 통해 원본 프로젝트를 복제한 자신의 깃 저장소를 덮어써주어
rebase 내용을 반영해주어야함.
그 다음 git push를 해야 성공적으로 push가 가능.