작업 공간
Git의 4가지 작업공간
위 그림과 같은 구분되는 작업 공간에서 git을 통해 형상을 편리하게 관리할 수 있음
workspace
본인이 직접 작성하고 있는 작업 공간
index
git에서 추가, 삭제 등 형상 수정을 추적하는 공간
local repository
git commit으로 staging된 파일들을 형상으로써 관리하는 공간
remote repository
인터넷 연결 환경에서 local repository에 있는 형상을 업로드를 통해 다른 사람과 공유하는 공간
여러 사람들의 협업에 자주 사용되는 공간
브랜치
1. 깃 호스팅 서버를 쓰지 않는 경우(코드 리뷰 X)
- 작업 완료 후 작업한 브랜치를 메인 브랜치에 머지
- local 에서 remote로 푸시
- 깃 호스팅 서버를 쓰는 경우(코드 리뷰O)
- 작업 완료 후 remote repository의 자신이 작업한 브랜치를 푸시
- 메인 브랜치로 Pull Request
- 코드 리뷰를 통해 합의 후, 메인 브랜치에 머지
로그
git log
git log --oneline --decorate --graph
git log -n 10
Sourcetree 및 GitHub Desktop의 GUI 툴을 사용하는 것도 좋음
git show
git show HEAD^^
git reflog
해당 브랜치에서 어떤 명령으로 형상이 변경되었는 지 확인할 수 있고 복구 또한 가능
git reset --hard를 취소하고 싶다면?
git reflog에서 해당 명령 직전의 커밋 해시 값을 참조하여
git reset c7591af --hard
위의 명령처럼 특정 해시를 통해 형상의 추적 시점으로 복구할 수 있음
리셋 그리고 복구
git reset --hard {커밋 ID}
특정 커밋 시점으로 돌아감, 변경사항은 전부 삭제 및 되돌림
또한 시점 변경으로 발생한 변경 사항 추적하지 않음!
git reset --mixed {커밋 ID}
특정 커밋 시점으로 돌아감, 해당 커밋 이후 변경 사항을 unstaged로 추적
git reset {커밋 해시} --soft {커밋 ID}
커밋 해시 또는 커밋 ID를 포함해야 하나 둘다 포함하지 않음
특정 커밋 시점으로 돌아감, 해당 커밋 이후 변경 사항을 staged로 추적
git restore {파일 경로}
특정 파일의 변경사항을 제거하고 HEAD로 돌아감
git reset --hard head
위 명령어와 비슷한 결과로 HEAD로 복구가 되지만
위에서 언급한 것과 같이 reset --hard의 경우 변경 사항을 추적하지는 않음
되돌리기
git revert {커밋 ID}
특정 커밋에 문제가 발견된 경우, 중간에 존재하는 커밋에 존재하는 내용만을 변경할 수 있다.
그러면 문제 커밋과 현재 커밋 사이에 있는 내용에 대해서는 보존할 수 있다.
임시저장
git stash
수정 내용을 임시 저장하는 명령어
커밋으로 남기기에는 작업 단위가 너무 작거나 진행 중인 경우 stash를 통해 임시 저장을 수행하고 다른 브랜치로 전환하여 다른 작업을 수행하고 돌아오면 된다.
git stash list
현재 브랜치에서 stash로 임시 저장된 내역을 모두 확인
git stash pop
가장 최근에 임시 저장한 stash를 불러옴, list에서 제거함
git stash apply
가장 최근에 임시 저장한 stash를 불러오지만 pop처럼 list에서 제거하지 않고 유지
커밋 수정
git commit --amend
이전 커밋의 내용을 보충하게 되거나 약간의 수정 내용이 있을 경우 사용
git push origin main -f
-f 옵션을 통해 강제로 push를 수행해야 remote에 덮어씌울 수 있음
git rebase --interactive {커밋 ID}
- pick
- edit
- reword
- drop
vi 에디터 내에서 커밋에 대한 변경을 가할 수 있음
스쿼시 그리고 머지
git merge {브랜치 이름}
- fast-forward merge: 브랜치 생성 이후 병합할 때까지 별다른 커밋이 없다면 머지 커밋 없이 바로 병합이 수행됨
git merge {브랜치 이름} --squash
브랜치 내에 있던 모든 커밋 내용들을 하나로 압축한 하나의 커밋으로 저장
git rebase {브랜치 이름}
Rebase & Merge: merge할 때, merge 커밋을 남기지 않으면서, merge 되는 브랜치의 모든 커밋 내역을 그대로 가져오는 머지
커밋 내용이 깔끔하게 정리되지만 브랜치 병합 히스토리가 잘 남지않아 추적하기 어려울 수 있음
다른 브랜치 커밋 내 브랜치로 가져오기
git cherry-pick {커밋 ID}
해당 커밋이 다른 브랜치의 커밋 내용을 포함하고 있더라도 가져올 수 있게 됨!
Gitflow
다양한 목적의 팀이 모여서 remote repository를 관리하게 되면 동기화를 위해 pull을 하는 횟수도 늘어나고 conflict가 나더라도 reset도 어려움
개개인이 작업할 브랜치를 지속적으로 만들어서 작업하는 방법
개인의 작업만 브랜치에 남기고 충돌 및 갱신의 부담이 덜함
변경사항에 대한 리뷰 후 merge 하면 됨
대표적인 개발 사이클
- 필요한 기능을 분석, 정의하고 개발합니다.
- 개발이 완료되면 테스트 환경에 배포합니다.
- 통합 테스트를 진행하며 버그 등 문제가 없는지 확인합니다.
- 문제가 있으면 이를 수정하고 2~3의 과정을 거칩니다.
- 테스트 완료 후에 최종적으로 운영 환경에 배포합니다.
- 최종 배포 후 며칠 뒤 심각한 버그를 발견하면 빠르게 수정하여 업데이트된 프로젝트를 배포합니다.
Gitflow 브랜치 전략
- master는 최종 배포를 위한 브랜치이며 develop 브랜치를 통해 개발 용 레포지토리가 관리되며 개개인의 기능 개발은 Feature 브랜치에서 이루어지게 된다.
- 따라서 Feature 브랜치의 경우 하나 이상의 브랜치가 존재하게 된다.
- 거의 모든 merge의 경우 feature에서 develop 방향으로 이루어지게 된다.
- develop에서 release 브랜치로 배포가 이루어지게 된다.
- 일반적으로 release 브랜치 위에서 통합 테스트가 이루어진다.
