[Git] 기초와 명령어

GIT

버전관리 시스템으로 가장 많이 사용되는것이 GIT

lifecycle - status

git에서 파일은 정해진 status에 따라 분류, 관리된다.

1. untracked
   아직 파일은 생성되어있지만, Git에서는 상관없는 상태.
   add 전까지는 Git에서 관리할 수 없음.
   add를해서 Staged 된 파일을 제거하려면 restore --staged <파읾명> 으로 untracked 상태로 전활 할 수 있음.
2. unmodified
   코드 저장이 완료된 상태. (Staged에서 commit시 Unmodified)
   status 명령상에서 눈에 보이진 않고 git으로 관리되는 파일이 잇지만 아직 변화되지 않은 상태이다.
3. Modified
   Git 으로 관리되고있는 파일을 수정하여 변경이 일어난 상태.
   Unmodified 상태인 파일을 수정하면 Modified가 된다.
   이 상태로는 commit할 수 없으며, 변경사항을 add시켜 Staged상태로 만들어야 한다.
4. Staged
   변경사항이 모두 git에 적용되었고 commit 가능한 상태.
   untracked, Modifed 파일을 add 하면 staged상태가 됨.
   한마디로 저장할 준비가 된 상태이다.

Commit

파일을 커밋할때 'git commit -m "메세지" ' 형태로 간단하게 커밋 메세지를 작성할 수 있지만, 정해진 커밋컨벤션을 활용하면 체계적으로 관리할 수 있다. (컨벤션은 회사에따라 다를 수 있다)

1. 제목열
   맨 윗부분인 제목열에는 작업의 종류를 적는다.

• feature : 기능의 생성작업
• refactor: 리팩토링
• bugfix: 버그픽스
• env: 환경설정 변경
• remove: 제거
• 등등 이외의 정해진 네이밍

2. 본문
   보통 전체 요약을 72자 이내로 정리하고, 추가적인 세부사항은 리스트형태로 나열하여 기록한다. 무엇을 왜 변경하였는지 설명하는것이 best.
3. 꼬리말(footer)
   잘 사용하진 않지만 Githun Issue ID를 적음으로써 이슈트랙킹을 할 수 있다.

Git log

커밋 히스토리를 조회하는 명령어
커밋 단위로 히스토리가 쌓이고 브랜치를 병합할때 머지방향과 순서를 이해하기위해 반드시 로그를 읽을 줄 알아야 한다. 최신정보가 상단에 위치한다.
로그에서 나갈땐 'q'를 입력한다.
tig 를 사용하는것도 찾아보면 좋다.

reset

상태를 이전커밋으로 리셋하는 명렁어
옵션에 따라 이전 어느단계까지 리셋할지 (Staged, Modified, Unmodified) 까지 정할 수 있다.

• --soft : 커밋 명령만 되돌려 staged상태로 리셋 (HEAD만 해당 커밋으로 돌림)
• --mixed : 커밋과 add 를 되돌려 Modified상태로 리셋
• --hard : 커밋,add,워킹 디렉토리까지 모두 리셋하여 Unmodified상태로 리셋

show

Git에서 커밋 정보를 보여주는 명령어
Git에는 시점을 가리키는 단축 기호가 있다. 현재시점을 나타내는 HEAD,@ 와 이전시점을 나타내는 ~,^ 를 이용하여 정보를 확인할 수 있다.
'HEAD~, HEAD^, @~, @^ ' 모두 바로 한 커밋이전을 뜻한다.

revert

되돌릴 커밋을 찾아 명령어 뒤에 hash 값을 전달하는 명령어( Git revert "hash" )
Revert 커밋이 기록되며 --no-commit 옵션으로 커밋 직전상태에서 추가작업을 진행하고 커밋할 수 있다.
Reset은 HEAD를 바꿔 시점을 이동하지만, revert는 되돌리려는 커밋에대해 revert하는 커밋을 남기고 제외시킨다는 차이가 있으며 주로 배포되어 공유된 커밋을 되돌릴때 사용한다.

branch

브랜치는 메인코드에서 뻗어나온 가지를 의미하며 특정 시점에 여러개의 브랜치를 만들 수 있다.

-m : 브랜치 이름변경
-d : 브랜치를 삭제하지만, 만약 커밋 내역이 존재하고 원격저장소에 머지되지않으면 실패
-D : 커밋 머지와 상관없이 강제 삭제
-v : 브랜치의 상세정보 확인
--merged : 현재 브랜치기준 이미 머지한 브랜치 목록 확인
--no-merged : 머지하지 않은 브랜치를 확인
- checkout "브랜치명" : 브랜치 이동
- checkout-b "브랜치명" : 브랜치를 생성하고 이동
- switch "브랜치명" : 브랜치를 이동(checkout이 역할이 많아 혼동을 피하기위해 사용)
- switch-c "브랭치명" : 브랜치를 생성하고 이동

merge

브랜치간 병합하는 명령어
병합하려는 브랜치의 commit을 모두 마쳤다면 기준 브랜치로 이동가능.
기준 브랜치에서 git merge <대상브랜치> 로 사용한다.

단, 브랜치를 병합하는 과정에서 conflict 가 생길 수 있다.
파일의 같은위치에 다른내용을 입력할 경우 발생하며 병합 전 파일을 잘 확인해야 한다.

push

로컬에서 진행한 작업을 원격 저장소로 업로드하는 명령어
저장할 원격 저장소에 쓰기 권한이 있어야 하며, 같은 브랜치로 여러명이 작업하는 경우 누군가 push 했다면 이후 작업자는 push 불가능.
다른 사람이 push한 내용을 가져와 merge 한 후에 변경하여 다시 push 해야한다.

git push origin main : 일반적인 push 커맨드

--force(-f) 옵션을 push 뒤에 붙이면 강제로 push 가능
로컬 브랜치에 내용을 덮어씌우기 때문에 main 브랜치에 적용시 치명적일 수 있음
만약 한사람이라도 main의 원본파일을 가지고있다면 force push로 다시 복구!

pull, fetch

pull 로 원격저장소의 데이터를 가져오고, 대상 브랜치에 자동으로 merge 가능.
fetch 는 원격저장소에서 데이터를 가져오지만, merge는 하지 않음( 원격 저장소의 변경내역을 확인할 때 사용)