[GIT] 찾기 귀찮아서 내가 정리한 GIT 사용법

Jae_0·2023년 5월 13일

git github 깃 깃허브

[GIT] 찾기 귀찮아서 내가 정리한 GIT 사용법

(추후에 추가 되거나 삭제 되는 것이 있을 수 있다.)

1. GIT

GIT(깃)은 형상 관리 도구 중 하나이다. (형상 관리 도구 = 버전 관리 시스템)

소스코드를 직접 주고 받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 즉, 병렬 개발이 가능하다.
브랜치를 통해 개발한 뒤, 본 프로그램(master)에 합치는 방식(Merge)으로 개발을 진행할 수 있다.
새로운 인원이 추가 되어도 클론을 통해 바로 작업이 가능하다.

(http://pismute.github.io/whygitisbetter/images/local-remote.png)

2. GIT 활용

💡 기본

git add (파일명)			// 특정 파일을 Staging area에 추가
git add .				// 현재 및 하위 디렉토리 모든 파일을 Staging area에 추가
git commit -m "(text)"  // 의미 있는 수정 작업이 끝났음을 알리는 작업, local repository에 추가
git push origin master	// remote repository에 추가

💡 버전확인

git --version

💡 커밋 로그

git log					// 이후에 git checkout으로 시점을 변경하거나 reset 등으로 되돌릴 수 있다.
git reflog
git reset HEAD@{index} 	// index 시점으로 돌아간다.

💡 원경저장소 확인 / 연결

깃에서 remote는 외부 깃허브 저장소가 있는 url에 대한 alias(별칭)을 만들어 관리하기 위한 명령어이다. (origin이 alias의 기본 이름이다)

git remote								// alias 목록을 가져온다.
git remote -v							// alias와 alias가 연결된 url도 같이 가져온다.
git remote add [alias] [url]			// 특정 url을 alias로 다루도록 할 수 있다.
git remote add origin [깃허브 저장소 url]	// 과 같이 사용 하면 된다.

💡 브랜치

브랜치를 통해 분리된 작업 영역을 나누고, 해당 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 새로운 버전으로 만들어 낼 수 있다. 저장소를 만들면 기본으로 master 브랜치가 생성된다.

git fetch				// 정보 업데이트
git branch				// 현재 내가 위치한 branch 확인
git branch -v			// 브랜치의 마지막 커밋 메시지 확인
git branch (name)		// 브랜치 생성
git switch (name)		// 해당 브랜치로 이동
git switch -c (name)	// 브랜치를 만들며 해당 브랜치로 이동
git restore				// 작업중인 파일(변경 내역이 있는)을 복원
git resotre --staged	// stage된 파일도 복구가 가능
git branch -d (name)	// 브랜치 삭제 (D는 강제 삭제)

다른 브랜치를 merge 하는 방법

merge 하기 전, 해당 브랜치로 스위치 후 git pull
다시 내 브랜치로 돌아와서 git merge (name)

💡 상태확인

git status

stage 영역에 없으면 🟥빨간색 = add 안된 상태
stage 영역에 있으면 🟩초록색 = add 된 상태

💡 .gitignore

Repository에 넣기 싫은 파일이 있을 때 .gitignore 파일에 제외하고 싶은 폴더, 파일을 적으면 된다.

파일명.확장자		// 특정 파일 제외하기
/파일명.확장자	// 현재 경로에 있는 파일 제외
폴더/			// 특정 폴더 안의 파일 모두 제외하기
*.확장자			// 특정 확장자 파일 모두 제외
!파일명.확장자	// 예외처리 하고 싶은 파일

3. 커밋 규칙

# <타입>: <제목>
# 본문
# 꼬리말
# 필요한 경우 주석 처리(#)를 지우고 사용. 이슈 트래킹을 위함
# Issues: #이슈번호
# Resolves: #이슈번호
# See also: #이슈번호
# ------------------
# <타입> 리스트
#   feat    : 기능 (새로운 기능)
#   fix     : 버그 (버그 수정)
#   design  : CSS 등 사용자 UI 디자인 변경
#   style   : 스타일 (코드 형식, 세미콜론 추가: 비즈니스 로직에 변경 없음)
#   refactor: 리팩토링
#   comment : 필요한 주석 추가 및 변경
#   docs    : 문서 (문서 추가, 수정, 삭제)
#   test    : 테스트 (테스트 코드 추가, 수정, 삭제: 비즈니스 로직에 변경 없음)
#   chore   : 기타 변경사항 (빌드 스크립트, 패키지 매니저 설정 수정 등)
#   rename  : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
#   remove  : 파일을 삭제하는 작업만 수행한 경우
#   !HOTFIX : 급하게 치명적인 버그를 고쳐야하는 경우
#   !BREAKING CHANGE : CHANGE 커다란 API 변경의 경우
# ------------------
#     제목과 본문을 한 줄 띄워 분리하기
#     제목 첫 글자를 대문자로
#     제목은 영어 50자 이내 (한글은 25자 이내)
#     제목은 명령문으로 (적용 시, 이 커밋은 <커밋 메시지> 합니다)
#     제목 끝에 마침표(.) 금지
#     본문은 영어 72자 마다 개행 (한글은 36자 마다)
#     본문은 “어떻게” 보다 “무엇을“, “왜”를 설명한다.
#     본문에 여러줄의 메시지를 작성할 땐 “-”로 구분
# ------------------
#     꼬리말은 optional이고 이슈 트래커 ID를 작성합니다.
#     꼬리말은 “유형: #이슈 번호” 형식으로 사용합니다.
#     여러 개의 이슈 번호를 적을 때는 쉼표로 구분합니다.
#     이슈 트래커 유형은 다음 중 하나를 사용합니다.
#       - Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
#       - Resolves: 이슈를 해결했을 때 사용
#       - Ref: 참고할 이슈가 있을 때 사용
#       - Related to: 해당 커밋에 관련된 이슈번호 (아직 해결되지 않은 경우)
#     ex) Fixes: #45 Related to: #34, #23
#-------------------