git 기본기_백과사전 (1)

git workflow 구성

1. working directory: 작업중인 로컬 환경, untracked/tracked으로 구분됨
2. staging area: git add를 통해 작업 내역이 올라가는 장소
3. git directory: git commit하면 작업 내역이 git directory에 위치됨
4. server(github/gitlab): git push하여 서버에 업로드, git pull하여 내려받음

commit 뜻

1. 스냅샷된 정보를 담음
2. ID로 고유한 hash코드가 부여됨
3. 누가 작성했는지, 언제 했는지가 기록됨

git add

# 1개 파일 add
git add <file>

# 2개 파일 add
git add <file1> <file2>

# 전체 수정 파일 add
git add .

# 전체 수정 파일 add
git add -A

# 디렉토리 내 전체 파일 add
git add *

working directory의 수정된 사항들을
staging area로 옮기는 행위

git rm --cached <file> 명령어로
staging area의 파일을 working directory로 다시 옮기는것도 가능

.gitignore

git에 포함하고 싶지 않은 파일들을 지정
지정된 파일들은 track되지 않아 git 명령의 대상이 아니게됨

git status

git의 상태를 보여줌

# 짧게보기
git status -s

# 풀버전 (기본)
git status
git status --long

 

git diff

이전 버전과 현재의 수정사항을 비교하여 보여줌
-는 이전 버전을 의미
+는 현재 버전, 수정된 사항을 의미

# 이전 버전과 현재버전을 비교
git diff

# staging area만 확인
git diff --staged

 

git commit

staging area의 변경 사항들은 git repository로 이동시킴

# 메시지와 함께 commit
git commit -m "some message"

# 전체 수정사항을 add 후, commit
git add .
git commit -m "some message"

# 전체 수정사항 add와 commit을 동시에
git commit -am "some message"

commit이야 말로 개발의 history가 됨
기능별, 의미있는 수정/기능 단위로 commit을 진행
커밋의 메시지는 현재형, 동사로 작성하는게 일반적 (init/add/fix)

git log

간단하게 commit 히스토리를 볼 수 있음
위에 있을수록 최신 commit

# 커밋 히스토리 보기
git log

# 간단하게 보기 (해시번호 + 커밋 메시지)
git log --oneline

# 수정사항 함께보기
git log -p

# 텍스트 GUI로 브랜치 함께 보기
git log --oneline --graph all

 

git alias

나만의 명령어를 만들 수 있음

git config --global alias.<이름> "<수행할 액션>"

 

HEAD

각 커밋은 이전 커밋을 가리킨다.
HEAD는 내가 현재 위치한 버전을 가리킨다.
즉, 현재 내가 보고있는 커밋을 가리킨다.

HEAD~1은 직전 버전
HEAD~2은 이전이전 버전
HEAD~3은 이전이전이전 버전
을 의미한다.

git tag

특정한 커밋을 북마크해두고 싶을때 쓰는것
제품을 릴리즈할떄 제품의 버전명을 tag해두는게 일반적

# 버전관리 - semantic versioning
major.minor.fix

# 예시
1.0.1

# 태그 추가
git tag <태그명>

# 특정 커밋 해시코드에 태그 추가
git tag <태그명> <해시코드>

# 특정 커밋 해시코드에 태그를 메시지와 함께 추가
git tag <태그명> <해시코드> -am "메시지"

# 태그 내용 조회
git show <해시코드>

# 태그 찾기, 와일드 카드 사용가능
git tag -l "v1.*" 

# 태그 삭제
git tag -d <태그명>

 

git branch

기능개발 / 버그픽스 등 업무를 진행함에 있어
개발자들 간에 병렬적으로 개발하기 위해
각자의 작업 공간을 나누어 개발을 진행한다.

이때 필요한게 나만의 작업공간 "branch"
특정 기능을 위한 작업공간 "branch"


특정 브랜치에서 git commit을 해나가다가
개발이 완료되면 기준 브랜치 혹은 마스터 브랜치로 병합을 하게되는데,(merge)

이때 그냥 병합하게 되면 브랜치가 지저분해져서
커밋 내역을 합쳐서 새로운 하나의 커밋을 만든 다음 병합하는 경우가 많다. (rebase & merge)

# 로컬의 브랜치 확인
git branch

# 로컬 & 서버 브랜치 확인
git branch --all

# 브랜치 이동 방법, 2가지
git switch <브랜치 이름>
git checkout <브랜치 이름>

# 브랜치 생성 & 이동 방법, 2가지
git switch -C <브랜치 이름>
git checkout -b <브랜치 이름>

# 해시코드를 이용해 브랜치 이동
git checkout <해시코드>

# 현재 브랜치에 merge된 브랜치 확인
git branch --merged

# 현재 브랜치에 merge얀된 브랜치 확인
git branch --no-merged

# 브랜치 삭제
git branch -d <브랜치 이름>

# 브랜치 삭제 & 원격저장소에 브랜치 삭제 반영
git branch -d <브랜치 이름>
git push origin --delete <브랜치 이름>

# 브랜치 이름 변경
git branch --move <이전 브랜치 이름> <새 브랜치 이름>

# 브랜치 이름 변경 & 원격 저장소에 변경된 브랜치 반영
git branch --move <이전 브랜치 이름> <새 브랜치 이름>
git push --set-upstream origin <새 브랜치명>

 

fast forward

흔히 말하는 fast forward란 무엇일까?

과거의 히스토리인 A커밋과

현재의 히스토리인 B커밋이 있을때,

B커밋이 A커밋의 모든 이력을 가지고 있다면

두 커밋이 "fast forward" 관계에 있다고 한다.

(이미지 출처 > 링크)

 

git merge

fast forward merge?
기준 브랜치에서 새로운 브랜치가 생성된 이후에
새 브랜치에서 작업하는 동안
기준 브랜치에 변동사항이 없다면,

기준 브랜치가 가리키고 있는 포인터를
새 브랜치로 변경해준 뒤
새 브랜치를 삭제해주는 방식으로 머지하는 것을 의미한다.

merge하면서도 깔끔하게 브랜치를 관리할수 있다는 장점이 있다.

다르게 생각하면 history에 merge되었다는
이력이 남지않는다는 단점이 존재한다고 볼수도 있다.

merge했을때 기준 브랜치에 변동사항이 없다면
자동으로 fast forward merge가 진행된다.

# feature/a를 master에 merge
git switch master
git merge feature/a
git branch -d feature/a

# fast forward merge 방지
git merge --no-ff <브랜치명>

three way merge?
내가 새 브랜치에서 작업하는동안에
기준 브랜치에 수정사항이 커밋됐다면,
fast forward merge가 불가능하게 된다.

이때는 기준 브랜치와 새 브랜치의 변동 사항을 모두 합쳐서
새로운 merge commit을 만든 후
기준 브랜치에 커밋해야한다.


merge할때 두 브랜치에서 동일한 파일을 수정했을때
"conflict"가 발생한다.
이러한 경우에는 개발자가 직접 conflict를 해결해야한다.

conflict이 발생하면 관련 내용에
자동으로
<<< HEAD
충돌 BRANCH >>>
텍스트가 생성된다.

# merge를 취소하려면
git merge --abort

# merge conflict를 해결 후, 해결 했음을 알리려면
git add <충돌 해결 파일명>
git merge --continue

# merge 후 orig 파일 생성되는것 방지
git config --global mergetool.keepBackup false
git clean -fd

커밋된 사항을 묶어 새로운 하나의 커밋을 만들어
머지하는 방법도 있다.
feature 브랜치의 커밋 히스토리를 합쳐서 깔끔하게
만들기위해 사용된다.

# squash merge
git switch master
git merge --squash <머지할 브랜치>
git commit -m "<메시지>"

git rebase

기준점을 재설정 함으로써
fast forward merge가 가능한 상황을 만들어
브랜치를 깔끔하게 관리하기 위한 수단.

마치 하나의 브랜치에서 작업한듯한 히스토리를
만들 수 있다.

** 로컬레포지토리에서는
자유롭게 rebase를 이용해도 된다.

다만, remote 레포지토리에 반영된 사항에
rebase를 하다가 merge conflict이 발생할 수 있다.

# feature/b를 master에 rebase
git switch feature/b
git rebase master

git switch master
git merge feature/b

# feature/view, feature/view/logic
# logic을 먼저 올려줄것을 요청하는 다른 개발자가 있어서
# feature/view/logic을 master에 merge 해보기
git switch master
git rebase --onto master feature/view feature/view/logic
git merge feature/view/logic

rebase의 또 다른 활용법이 있다.
하나의 feature를 구현함에 있어서도
분명 세부적인 기능들이 나눠진다.

따라서, 로컬에서 개발을 진행할 때
n번에 나눠서 commit을 진행하게 되는데
이때 그냥 push하면 모든 commit기록이
remote 서버로 넘어가기 때문에 브랜치가 지저분해진다.

내 로컬 작업을 간단히 정리해서 push하기위해
아래와 같은 사전작업을 할 수 있다.

# git log로 커밋 이력 확인하기
git log

# 최근 3개의 커밋에 대해 정리하기
git rebase -i @~3

# push하기
git push origin <브랜치명>

위 rebase 작업에서는 2번의 텍스트 에디터 화면을 보게된다.
1. commit 선별하기
p (pick, 사용하기)
| r (reward, 사용하되 커밋 메시지 수정하기)
| s (squash, 사용하되 이전의 커밋에 녹이기)
등의 옵션을 이용할 수 있다.
2. commit 메시지 정리하기
dd명령어를 이용해 원하는 라인을 제외하고 모두 지우거나
새 커밋 메시지를 작성하여
커밋 메시지를 깔끔하게 할 수 있다.
(해당 내용은 다음 포스팅에서 더 상세히 다룸)

cherry pick

다른 브랜치에 작업중인 특정 커밋만,
내 브랜치에 머지하고자할때 사용

# 특정 커밋 가져오기
git cherry-pick <해시코드>