-m : vim에서 별도 메시지 작성 없이 인라인 형식으로 바로 작성 ( 이거 안하면 vim 편집기가 뜬다. 여러 줄 가능 )
-a : 별도 add 명령어 사용하지 않고 수정된 파일에 대해 add, commit 한번에 수행. (반드시 한번은 add 된 파일이어야 함)
-am : a,m 옵션 합친 상태
진짜 add 안해도 바로 됨..
git branch
git branch [생성할 branch] [상위 branch]
-a : 모든 branch (로컬 + 원격저장소) 확인
-r : 원격 저장소에 있는 branch만 확인
-d : 브랜치 삭제 (머지된 경우만)
-D : 브랜치 삭제 (머지 없어도 강제 삭제)
-c : 다른 브랜치 카피 (이건 처음 봄 싱기..)
git checkout (or switch)
-b/-B : 새로운 브랜치 만들면서 checkout
-m : 3-way 머지 수행하면서 checkout? (상위 브랜치로 checkout 하면서 커밋머징까지 해준다는 의미인 것 같음)
-f : 작업 디렉토리 인덱스가 HEAD와 다른 ( 스테이징하지 않은 변경 사항이 있어도) 강제로 전환. 로컬 변경사항은 삭제됨 (stash 좋아)
git push
-u (upstream) : 이거 하고 나면 현재 브랜치 이름으로 git push까지만 써도 계속 push 시켜줌 개편함... 변경 이력을 자동 연결하는 것
-a : 모든 로컬 브랜치 푸시
-t(--tags) : 로컬 모든 태그 푸시 ( 태그가 뭐지 ? 깃에선 특정 커밋을 태그(가르키는 링크 추가)할 수 있다. git flow에서 main에 tag 적용하는거 -> 보통 버전 릴리즈 때 사용 )
--dry-run : 실제 푸시 없이 어떤 일이 발생하는지 알 수 있는 옵션.. 신기...
--delete (ex ) git push origin --delete main) : git branch 원격 저장소에 있는거 로컬에서 삭제할 때 많이 사용했었다.
git pull : 기본 git pull은 fetch 후에 merge를 수행한다.
--rebase : merge 대신 rebase 수행
--squash : 여러 커밋을 하나의 스쿼시 커밋으로 병합. -> 이거 브랜치가 너무 많아서 커밋 로그 트리? 그거 너무 어지러울 때 사용할 수 있다.
-u : push와 동일하게 현재 브랜치와 원격 브랜치를 추적하도록 설정.
Git 작동 구조
원격 저장소 (Repository)
로컬 저장소 (Working Directory)
Staging Area
1) 원격 저장소에서 레포지토리를 만들면 2) 내 로컬에 clone 한다. 3) 로컬에서 작업된 결과물을 git add를 통해 Staging Area로 올리고, 4) git commit으로 git에 저장한다. (push 직전까지는 로컬 커밋으로 존재) 5) git push하면 원격 저장소에 올라감.
용어 정리
Repository : 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장.
원격 저장소, 로컬 저장소가 있다.
Working Tree (Working Directory) : 저장소 어느 한 시점을 바라보는 작업자의 현재 시점 -> 작업 디렉터리를 뜻함.
SnapShot : 특정 시점의 파일, 폴더 또는 워크스페이스의 상태.
커밋을 실행하면 스냅샷이 저장된다.
Head : 현재 포인터이자 Branch를 가르키고 있는 것.
명령어 정리
git stash : 아직 완료하지 않은 작업을 커밋하는 것이 껄끄러울 때 잠깐 저장했다가 다시 돌아오고 싶다면 사용... 개인적으로 브랜치를 잠깐 바꿨다 돌아와야 할 때 사용했었음.
Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소다. 아직 끝내지 않은 수정사항을 스택에 잠시 저장했다가 나중에 다시 적용할 수 있다(브랜치가 달라져도 말이다).
git stash list : 저장된 stash 확인
git stash apply {stash 이름}: Stash 재적용 (이름 없으면 가장 최근 stash 저장)
git stash drop : Stash를 제거하는 명령어 ( apply는 pop까진 해주지 않는다. 그냥 가장 최근 stash를 가져와 저장 )
git log : 커밋 기록을 확인하는 명령어
git revert {commit 이름}: commit을 되돌릴 수 있다. (오늘 실수로 파일 두개 열어놓고 저장 -> push 해버려서 사용 )
- git reset도 있는데 사용하지 않는게 좋음;;
- git reset : commit 자체를 지워버리는 거기 때문에, 다른 사람과 공유하는 레포지토리라면...;;; - git revert : 새로운 commit을 추가해서 이전 커밋 내용을 다시 커밋하는 방식이다. 다른 사람이 실수로 올린 커밋 위에서 작업하고 있어도 ㄱㅊ!
git flow 전략
Git flow 전략은 사용해보기도 했지만... 뭔가 질문 받으면 대답할 자신이 없어서 이번에 깃 하는 김에 같이 해보기로 했당.. (유지 보수까진 해본적이 없어서 hotfix나 release도 써본적이 없다)
Main
Main 브랜치는 출시 가능한 프로덕션 코드를 모아두는 브랜치. 프로젝트 시작 시 생성하며, 개발 프로세스 전반에 걸쳐 유지한다. 배포된 각 버전을 Tag를 이용해 표시해둔다.
Develop
다음 버전 개발을 위한 코드를 모아두는 브랜치. Main으로 머지된다. ( 기능 개발을 여기서 함 )
Feature
하나의 기능 개발을 위한 브랜치. Develop 브랜치에서 생성하고 기능이 개발 완료되면 다시 Develop으로 머지한다. 주의할 점은 Fast-Forward로 머지하지 않고 Merge Commit을 생성해 머지한다. 이렇게 해야 히스토리가 특정 기능 단위로 묶인다.
Fast-forward 머지? branch 간 병합 시 커밋이 생기지 않고 merge 명령어를 실행하는 브랜치의 Head Commit이 병합되는 branch의 Head Commit으로 이동되는 방식 -> 새로운 브랜치에만 commit이 있는 경우. 3-way merge? 병합할 브랜치 각각 신규 commit이 1회 이상 있는 경우 merge 명령을 내리면 ㄷ두 브랜치 코드를 합쳐 새로운 commit을 자동 생성해준다. <<<<HEAD 이런거....
git switch [현재 브랜치] git merge [대상 브랜치]
Release
소포트웨어 배포를 준비하는 브랜치 Develop 브랜치에서 생성한다. 버전 이름 등 소소한 데이터 수정이나 배포 전 사소한 버그 수정을 위해 사용한다. 배포 준비가 되었다면 Main과 Develop 둘 다 머지한다. Main에는 태그를 이용해 버전 표시.
