[GIT] 깃 사용법, 깃 명령어 모음 (2024.06.26 수정)

0. 발단 

---

1. 서론

[코딩애플]

https://codingapple.com/course-status/

갓딩애플님 감사드리며,..

[유데미 : Git&Github를 이용하여 가상의 오픈소스 전설의 레시피를 만드는 과정! ]

---

 

2. 본론

 

- 1. 깃 사용자 설정

git config --global user.email "~~~@gmail.com"
git config --global user.name "~~~"

git init

git add 파일이름

git commit -m "어쩌구~~"

 

-2. 두 개 이상의 파일 스테이징 하기

git add 파일이름 파일이름

(파일 전체 스테이징)

git add .

 

 

-3. 상태창 열기

git status

 

-4. 스테이징 취소

git restore --staged 파일명

 

-5. commit 조회

git log --all --oneline
git log --all --oneline --graph

 

-6. commit 전 후 차이점 출력

git diff
git difftool

됐고, git graph 설치하면 더 간편~
 

+++) git graph 어떻게 설치하는데..?

https://noeyxos.tistory.com/382

 

 

-7. 대망의 branch 

git branch 브랜치이름

(branch 바꾸기는 이렇게) 

git switch 브랜치이름

git switch main
git merge 브랜치명

(main (기준) 에 브랜치가 합병 되는 것 )

 

 

> 다양한 merge 방법 < 
 
브랜치에 각각 신규 commit이 1회 이상 있는 경우
merge 명령을 내리면 두 브랜치의 코드를 합쳐서 새로운 commit을 자동으로 생성해주는데 이걸 3-way merge 라고  함.
 
fast-forward merge

강제로 3-way merge 

git merge --no-ff 브랜치명

 
브랜치를 삭제

git branch -d 브랜치이름
git branch -D 브랜치이름

 
rebase and merge

git switch 새로운브랜치
git rebase main

git switch main
git merge 새로운브랜치

 
 
 
squash and merge

git switch main
git merge --squash 브랜치명
git commit -m '메세지'

 
-8. 파일 되돌리기

git restore 파일명

이러면 최근 commit 된 상태로 현재 파일의 수정내역을 되돌릴 수 있습니다. 
 
 

git restore --source 커밋아이디 파일명

이러면 입력한 파일이 특정 커밋아이디 시점으로 복구됩니다. 

git restore --staged 파일명

이건 복구랑 상관없지만 이러면 특정 파일을 staging 취소할 수 있습니다. 
 

 

 

git revert 커밋아이디

이거 입력하면 그 커밋아이디에서 일어난 일만 취소해줍니다.
실행하면 아마 에디터가 뜰 텐데 맘대로 커밋메세지 수정하고 닫으면 끝입니다.

+ ) 그리고 revert 했던 기록이 log에 남는다!  
만약 어떤 commit을 삭제했을 때 reset을 해버리면 협업하던 동료들에게 폐를 끼칠 수 있으니 
(revert는 없앴다고 알려줌 vs reset은 쥐도새도 모르게 없애는 느낌 )
revert를 권장한다고 하셨다.....

 

 

git reset --hard 커밋아이디

커밋 아이디 시점으로 싹 돌아감 * commit 내용 뿐만 아니라 내가 파일에서 변경했던 부분이 모두 삭제됨 

git reset --soft 커밋아이디

 삭제 안되고 staging area에 남아있습니다. 

git reset --mixed

 

 

git branch -M main

git push -u 원격저장소주소 main

git remote add origin https://github.com/codingapple1/lesson.git

(참고) 실은 -u는 방금 입력한 주소를 기억하라는 뜻이라
-u 붙여서 1번 했었으면 나중엔 git push 까지만 입력해도 알아서 잘됩니다. 
진짜로 git push만 해보셈 
 
(참고) 변수목록을 살펴보고 싶으면 git remote -v 입력해보십쇼 
 

 
-9. 원격저장소에 있던거 그대로 내려받기

git clone https://원격저장소주소

 
 
 

저장소에 올리지 않는 파일들은 .gitignore

 
원격저장소를 효율적으로 쓰고 싶으면 쓸데없는 파일은 commit 해서 올리지 않는게 좋습니다.
.gitignore 파일을 하나 만들면 저장소에 올리지 않을 파일들을 쉽게 명시가능합니다.
거기 명시한 파일들은 git add . 해도 스테이징이 되지 않아서 편리합니다.
 
웹개발을 제일 많이 하니까 웹개발을 예로 들면 
node_modules 이런 폴더, 개인정보들이 들어있는 .env 파일 이런 것들은 안올립니다. 
(어짜피 package.json 파일만 잘 있으면 터미널에서 npm install 입력하면 자동으로 node_modules 폴더가 생성됩니다.)
 
그래서 .gitignore 파일에 명시해주면 됩니다.
작성하는 법은 필요할 때 구글찾아보십쇼 
 

-10. git pull 이용하면 현재 원격저장소 내용 가져올 수 있음 

git pull 원격저장소주소

(참고)

- git pull 원격저장소주소 브랜치명 입력하면 특정 브랜치만 가져올 수 있습니다. 

- origin이라는 변수명을 등록해놨으면 당연히 사용가능

- 예전에 -u 했었으면 git pull, git push까지만 입력해도 잘됩니다.

 

-11. 

git push 원격저장소주소 로컬브랜치명

 

- 12. 안정적인 운영이 필요하면 [git flow] 전략 

git flow 전략은 크게 5개 브랜치를 운영하는데

- main 브랜치

- develop 브랜치 (개발용)

- feature 브랜치 (develop에 기능추가용)

- hotfix 브랜치 (main 브랜치 버그해결용)

- 가끔 release 브랜치 (develop 브랜치를 main 브랜치에 합치기 전에 최종 테스트용)

를 운영합니다

(1) develop 브랜치부터 생성합니다. 

(2) 신기능개발은 feature 브랜치에서 진행

(3) 신버전 출시 준비는 release 브랜치

- 여기서 테스트나 QA같은거 진행하면 됩니다.

- 버그를 발견하면 알아서 임시 브랜치 만들어서 수정하거나 합니다.

- release/1.0 이런 식으로 이쁘게 브랜치 이름을 짓는 경우가 많습니다.

(4) hotfix 브랜치

1.0 버전에서 갑자기 골드 무한복사 버그를 발견했습니다. 

그런 급한 것들은 main 브랜치에서 hotfix 이런 브랜치 하나 만들어서 바로바로 버그수정하면 됩니다. 

 

- 수정이 완료되면 main 브랜치에 직접 merge 하면 됩니다. 

- 당연히 develop 브랜치에도 merge 해줘야합니다.

 

 

[Trunk-based 전략] 

1. 기능추가, 버그픽스가 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어서 코드짭니다.

브랜치마다 작명 잘하는게 중요합니다. 

2. 기능이 완성되었으면 main 브랜치에 합칩니다.

이제 브랜치 쓸데없으니 삭제합니다.

3. main 브랜치에 있는 코드를 필요할 때 마다 유저들에게 배포합니다.

- trunk-based 개발의 장점은 코드를 한 브랜치에서만 관리하기 때문에 편리합니다. 

- 크게 개발해서 한 번에 merge 하는 것 보다 작은 단위로 merge 하는 것이 더 안전합니다. 

- 하지만 main 브랜치에 있는 코드가 뻑이나면 큰일나기 때문에 테스트나 코드리뷰를 자주해야합니다.

그래서 테스트를 자주하고 자동화해놓는 곳들이 제대로 사용가능합니다. 

 

 

Q. merge 할 때 어떤 방법 쓰는게 좋은가요?

기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge

기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase 쓰면 됩니다. 

취향일 뿐이고 알아서합시다. 

 

 

 

-13. 임시 보관

여러 버전을 시도해보고 싶을 때 굳이 브랜치를 생성하지 않아도 됨 

git stash

git stash push -m "이거 추가해본다?"

하면 방금 추가한 것이 파일에서 삭제되고 stash 에 저장됨 

가장 최근 stash 한 파일이 0번  -> 숫자가 클수록 가장 먼저 stash 해놓은 파일

git stash show [stashID] -p

git stash save "bbb 코드짰는데 망함"

git stash list

보관했던 코드 다시 불러오기

git stash pop

git stash drop 삭제할id
git stash clear

위에건 특정 stash 삭제, 

밑에건 모든 stash 삭제하는 명령어입니다.

삭제할 id는 git stash list 하면 보이는 0, 1, 2 이런 숫자 넣으면 됩니다. 

 

git stash -p 

전체 말고 일부 코드만 git stash 하고싶으면 이거 씁시다.

그럼 파일을 훑어주면서 stash 할 지 의견을 물어보는데 y/n 으로 잘 대답하면 됩니다. 

 

git stash apply [stashID]

해당 값이 현재 파일에 적용됨 ㄷ ㄷ

 

 

 

---

3. 결론

 

Q1.  효율적인 깃 사용법

A. 저장소에 올리지 않는 파일들은 .gitignore
 
원격저장소를 효율적으로 쓰고 싶으면 쓸데없는 파일은 commit 해서 올리지 않는게 좋습니다.
.gitignore 파일을 하나 만들면 저장소에 올리지 않을 파일들을 쉽게 명시가능합니다.
거기 명시한 파일들은 git add . 해도 스테이징이 되지 않아서 편리합니다.
 
웹개발을 제일 많이 하니까 웹개발을 예로 들면 
node_modules 이런 폴더, 개인정보들이 들어있는 .env 파일 이런 것들은 안올립니다. 
(어짜피 package.json 파일만 잘 있으면 터미널에서 npm install 입력하면 자동으로 node_modules 폴더가 생성됩니다.)
 
그래서 .gitignore 파일에 명시해주면 됩니다.
작성하는 법은 필요할 때 구글찾아보십쇼 

 

 

 

Q2. merge 할 때 어떤 방법 쓰는게 좋은가요?

A2. 기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge

기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase 쓰면 됩니다. 

취향일 뿐이고 알아서합시다. 

 

 

 

Q3. 지켜야 할 몇 가지의 약속들

1. 한 단위의 커밋은 한 커밋에 작성하기
2. 한 커밋에 2개 이상의 작업을 넣지 않기
3. 커밋의 성격에 따라 특징 표시해두기

 

참고하면 좋을 사이트

https://udacity.github.io/git-styleguide/

Udacity Nanodegree Style Guide

1. 커밋 메시지는
type: subject
body
footer
로 구성해야한다.

2. type의 종류는 다음과 같다.

위의 type의 큰 가지들

3. subject는 최대 50자를 넘지 않도록하기, 대문자로 시작하는 것이 좋고 마침표는 쓰지 않는다.
과거 시제보다는 현재시제로 써라

 

예시 _

feat: Summarize changes in around 50 characters or less

4. 커밋 메시지가 너무 딱딱하게 느껴진다면

https://gitmoji.dev/

gitmoji

를 이용해서 자신의 존재감을 뽐내보자