[Wiki] Git의 모든 것

🚨 글의 모든 내용은 코딩애플의 강의를 듣고 작성하였습니다. 이미지의 일부는 직접 찍은 이미지이지만, 대부분 코딩애플에서 가져온 이미지입니다. 이 글의 목적은 스스로 정리하고, 추후 문제가 발생할 때 제가 정리한 글에서 찾아보기 위한 용도입니다.
자세한 내용 및 출처는 모두 코딩애플의 [(무료) 매우쉽게 알려주는 git & github] 강의에 있음을 다시한번 알려드립니다. 🚨

1. git 설치

git을 왜 사용할까?
- 프로젝트를 진행하다보면, 파일 변경내역을 보존하고 관리하는 과정이 필요하다.
- 코드 짜다가 실수해서 이전 코드로 되돌아가려면?
  - 매일 파일의 복사본을 만들거나, 버전관리 소프트웨어를 사용한다!
  - 보통 git이라는 버전관리 소프트웨어를 사용한다.
git (버전관리 소프트웨어)를 사용하면?
- 과거 코드로 돌아갈 수 있다.
- 과거 작업 내용 열람할 수 있다.
- 등 안정적인 개발이 가능하다.

git 설치
- 윈도우 : git window검색한 후 설치
- 맥북 : Homebrew설치 후, brew install git
- 우분투 : pip install git

2. 파일 기록하기 - `git add, commit`

git init

현재 상태를 기록해두려면?

git add 파일명
# git add . : 전체파일 추가
# git add app.txt

git commit -m "메모"
# git commit -m "첫파일만들었음"

→ 이런 과정을 기록이라고도 하지만, “버전생성”이라고도 한다.

기록의 과정: git add→ git commit 순서

작업폴더 중에서 내가 기록을 하고 싶은 폴더/파일들은 git add 명령을 통해 기록을 한다.
그 후 git commit 명령어를 통해 저장소에 옮긴다.

용어정리

staging area: 여기서 가운데 부분. commit 하기 전에 commit 할 파일들을 골라놓는 곳.
- staging: 작업폴더에서 staging area로 파일을 고르는 행위
- git add → staging
repository: 저장소. commit된 파일의 버전들을 모아놓는 곳
- repository의 실체를 구경하고 싶다면 작업폴더 안에 있는 .git파일을 열어보면 됨

명령어 총정리

git add 파일명1 파일명2

여러 파일을 동시에 스테이징

git add .

모든 파일을 전부 스테이징

git status

상태창. 어떤 파일들을 staging했는지 등을 볼 수 있음

git restore --staged 파일명

스테이징된 파일을 취소하고 싶을 때 사용

git commit -m “메시지”

코드에 어떤 기능을 추가했는지 커밋메시지 작성

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

commit 기록을 한 눈에 볼 수 있다.
--graph 옵션을 넣으면 그래프로 그려준다.

얼마나 자주 commit하면 좋은가?

5초마다 습관적으로 할 필요는 없다.
간단한 기능을 추가하거나 수정할 때마다 커밋해주면 된다.

3. git add, commit, diff 쉽게 하는 법 (VSCode)

터미널에 git add, commit 할 수 있지만, 요새는 웬만한 에디터에 다 git이 내장되어 있다.

in VSCode

+ 버튼을 누르면 git add .
위의 체크표시를 누르면 git commit

(1) git diff

commit 하기 전에 이전과 현재 코드가 어떤 차이가 있는지 알고 싶을 땐? git diff 명령어를 사용

git diff

최근 commit과 현재 파일의 차이점을 보여준다.

조작
- j/k : 크롤바
- q : 종료
단점
- 터미널 한계로 가시성 좋지 않음.
- 스페이스바/엔터키 변동사항도 다 알려줌
결론 >> git diff 쌩으로 사용하진 않음

유용한 git diff 명령어

git diff 커밋id

git diff 커밋id1 커밋id2

(2) git difftool

git difftool을 이용하면 git diff보다는 조금 더 보기 좋다.
vim에디터가 뜨면서 비교하기 쉽다!

git difftool

→ 현재 파일과 최근 commit의 차이점을 비교할 수 있다.

조작
- h j k l : 방향키
- :q / :qa : 종료

git difftool 커밋id

git difftool 커밋id1 커밋id2

(3) 에디터 부가기능

에디터가 잘 되어 있기 때문에 git difftool입력할 필요 없이 VSCode 에디터 Extensions메뉴에서 git 관련 부가기능 설치한다.
이렇게 하면 편리하게 git diff 사용할 수 있다.
git history, git lens 등 아무거나 설치해도 git diff를 편리하게 사용할 수 있다.

git graph

git graph 버튼 누르면

commit한 내역을 한 눈에 살펴볼 수 있음

파일명 우클릭하면 git diff도 가능

💡 결론 : 이 중에서 본인에게 편한 거 사용하면 된다.

4. git에서 branch만들기

커밋하다보면 새로운 기능을 추가하는 경우가 있다. 원본 파일에다가 바로 추가해도 되겠지만, 혹여나 잘못 짰다면..!?지금껏 짰던 프로그램이 망가질 수도 있다..!
이런 걱정 없이 안전하게 새로운 기능을 추가하고 싶다면, 프로젝트의 복사본을 만들면 된다.

이를 git branch 기능을 통해 쉽게 복사본을 만들 수 있다.

(1) branch

브랜치 생성

git branch 브랜치명
# git branch coupon

해당 브랜치로 이동

git switch 브랜치명

확인

git status

원래 짜던 곳을 main branch 또는 master branch라고 함
새로 만든 branch에서 작업하면 원래 브랜치인 main branch에는 아무 영향이 없음

branch와 commit내역을 한 눈에 그래프로 보고 싶다면?

git log --graph --oneline --all

git log하면 나오는 HEAD는 무엇?

⇒ 현재 위치

(2) branch 합치기 : merge

branch에 짰던 코드가 완성되면, 원본코드가 있는 master(또는 main)브랜치에 합친다.
⇒ 이는 merge를 이용한다.

git switch main
git merge 브랜치명

main/master 브랜치로 이동
내가 작업하던 브랜치명을 입력! git merge 브랜치명

주의..!! CONFLICT

master브랜치와 coupon 브랜치에서 같은 파일, 같은 줄을 수정했을 경우 merge conflict 발생한다.

에디터로 해당 파일을 열어보면 충돌사항이 적혀있다.

이런 경우, 둘 중 어떤 코드를 적용할지 고르면 된다. 고르고 나면

git add 파일명
git commit -m “메시지”

로 입력하면 새로운 commit을 생성해주고, merge conflict해결, 브랜치 합치기가 완료된다!

(3) 협업 시 branch의 유용함

branch는 복사본을 만드는 것이라고 위에서 얘기했다. 이는 여러 개발자들과 협업할 때도 사용하면 편리하다. 10명이 하나의 프로그램을 만든다고 할 때, 모두 다 같은 코드를 수정하지는 않을 것이다. 각자 자기가 맡은 파트나 기능이 있을 것이다. 그런데 하나의 main브랜치에서 모두가 작업하면 여러 사람이 어려움을 겪을 것이다.

즉 branch로 프로젝트 사본을 만들어 본인 개발 진행한 후,
테스트해봤는데 잘 되면 main branch에 합친다!
그러면 협업 시에도 안정적으로 개발할 수 있게 된다.

(4) Summary

브랜치 생성: git branch 브랜치명
브랜치 이동 : git switch 브랜치명
브랜치 합치기: main/master로 이동한 후에 git merge 브랜치명
브랜치마다 commit 내역 그래프 보고 싶을 때 : git log --graph --online --all
브랜치 합칠 때 conflict 발생할 때 : 파일열어서 수정하고 git add, git commit

5. 다양한 merge방법

브랜치는 다양한 방법으로 합칠 수 있다.

(1) 3-way-merge (기본 동작방식)

브랜치에 새로운 commit이 1회이상있을 때 merge를 내리면 두 브랜치의 코드를 합쳐서 새로운 commit을 자동으로 생성해준다.
이를 3-way-merge라 하며 merge의 기본 동작방식이다.

(2) fast-forward merge

새로운 브랜치에만 commit이 있고, 기준이 되는 브랜치에는 신규 commit이 없는 경우가 있다.

이때 merge하게 되면 “fast-forward merge되었다”고 알려준다.
fast-forward merge란, 합칠게 없어서 신규 브랜치가 main브랜치가 되는 것이다.
- 즉, “기준이 되는 브랜치에 신규 commit”이 없으면, 자동으로 fast-forward merge가 발생한다.
- 이 과정이 싫으면 아래 명령어를 입력해 3-way-merge할 수 있다.

git merge --no--ff 브랜치명

(3) 브랜치 삭제

브랜치를 merge하고 나면 브랜치가 자동으로 삭제되지는 않는다.

즉 필요없어진 브랜치는 직접 삭제하면 된다

git branch -d 브랜치이름 #병합 완료된 브랜치 삭제
git branch -D 브랜치이름 # 병합하지 않은 브랜치 삭제

-d : 병합 완료된 브랜치 삭제인 경우
-D : 병합하지 않은 브랜치 삭제인 경우

(4) rebase and merge

브랜치를 rebase하고 나서 merge할 수 있다.

**rebase란, 브랜치의 시작점을 다른 commit으로 옮겨주는 행위**이다.

rebase를 이용해서 신규 브랜치의 시작점을 main브랜치 최근 commit으로 옮긴다음,
fast-foward merge한다.

이를 간단히 쉽게 말하면 강제 fast-foward merge이다.

이렇게 하는 이유?

3-way-merge말고 강제로 fast-foward하고 싶은 경우
브랜치 없이도 코드 잘 짜는 고수느낌을 주고 싶을 경우

이런 경우에 일반 3-way-merge대신 rebase&merge를 해도 된다.

rebase & merge를 할 경우

새로운 브랜치로 먼저 이동
git rebase main
브랜치가 main 브랜치 끝으로 이동하는데 그것을 fast-foward merge

git switch 새로운브랜치
git rebase main

git switch main
git merge 새로운브랜치

⇒ 단점: branch끼리 차이가 너무 많은 경우, rebase하면 충돌이 많이 발생할 수 잇는데 하나하나 해결하기 어렵다.

(5) squash and merge

모든 브랜치를 3-way-merge해버리면 나중에 참사가 일어난다!!

이유:

3-way-merge는 매우 복잡하다.
main 브랜치 git log 출력해보면 3-way merge된 브랜치들의 commit 내역도 다 같이 출력되어서 더러워진다.

따라서 위의 이유가 싫다면, rebase 또는 squash and merge하면 된다.

squash and merge하면 새로운 브랜치에 있던 commit들을 연결해주는 것이 아니라 main 브랜치에 붙여주기 때문에 위의 이유들을 걱정하지 않아도 된다.

여기서 squash and merge는 3-way merge처럼 선으로 이어주지 않고 새 브랜치에 있던 코드변경사항들이 main 브랜치로 텔레포트한다.

main 브랜치의 git log를 출력할 때 merge 완료된 브랜치의 commit 같은 것들은 출력되지 않는다!!
이게 왜 좋은 것인지에 대해서는 직접 해봐야 체감이 된다! 3-way-merge를 많이 하면 겪게 되는 불편함인가보다..

squash and merge하는 법은 merge할 때 옵션 값으로 --squash만 추가해주면 된다!

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

그냥 merge했을 경우,

merge --squash했을 경우

📌결론
브랜치를 여러 개 만들어놨는데, merge를 잔뜩 해놓으면 나중에 git log 그래프가 매우 복잡해질 수 있다. 이게 싫으면 squash나 rebase로 해결하면 된다.

💡 Q. merge 할 때 어떤 방법 쓰는게 좋은가?
기록을 남겨야하는 중요한 브랜치를 merge할 땐 3-way merge
기록을 남길 필요없는 쓸데없는 브랜치를 merge할 땐 squash, rebase
취향일 뿐이다!

6. 코드 짜다가 실수했을 경우

git은 버전관리 소프트웨어 프로그램이기 때문에 언제든지 이전 commit으로 되돌아가거나 문제가 되는 commit의 내역을 취소할 수 있다.

git restore / git revert / git reset 명령어를 써서 파일을 복구한다.

git restore : 복구
git revert : commit 복구
git reset : 시간 되돌리기

(1) 파일을 되돌리려면? git restore

수정사항이 너무 많다면 명령어 하나로 되돌릴 수 있다.

git restore 파일명

→ 최근 commit된 상태로 현재 파일의 수정내역을 되돌림

git resotre --source 커밋id 파일명

→ 입력한 파일이 특정 커밋 아이디 시점으로 복구

git restore --staged 파일명

→ 특정 파일을 staging 취소

(2) Commit을 되돌리려면? git revert

커밋아이디에 일어난 일만 취소해주는 명령어

git revert 커밋id

⇒ 나중에 git log로 보면, revert해줬다는 commit이 자동으로 생성되고, revert한 파일은 삭제된다.

revert명령어를 쓰면? 특정 커밋에서 있던 일을 지울 수 있다.

revert 특징

revert할 때 동시에 여러 개의 commit id 입력할 수 있다.
신규 commit 1개만 revert하고 싶다면, git revert HEAD 하면 편리하다. (HEAD가 현재위치이자 가장 최근 commit)
merge로 만들어진 commit도 revert할 수 있다. ⇒ 다시말해, merge 취소 가능!

(3) 전부 되돌리고 싶다면? git reset

git reset --hard 커밋아이디

→ 커밋이 생성될 때로 시간을 되돌려준다. 작업 폴더 내의 파일도 돌아감

위 그림처럼 아에 커밋이 삭제된다!

참고!

여러 명이서 협업하는 repository에서는 보통 reset 쓰면 갑자기 코드가 사라지기 때문에, 권장하지 않음. (혼란이 올 수도!)
untrack 파일들(git add 안해놓은 파일들)은 사라지지 않고 유지된다.
git clean 명령어 쓰면 untracked 파일들도 다 지울 수 있다!

7. Github 사용법1. 내 코드 올릴 땐? git push

(1) repository

repository란?
- git이 파일 버전을 저장해두는 저장소
- 로컬 작업 폴더에 있는 .git 폴더
온라인 repository
- 실제로 개발할 땐 온라인으로 저장하는 온라인 repository를 많이 사용함
- 이렇게 하면, 1) 컴퓨터 랜섬웨어 걸려도 안심 가능 2) 다른 사람과 협업 가능

(2) 실습

내 컴퓨터에 만든 로컬 저장소를 github(원격저장소)로 백업
방법
1. 로컬리포지토리 생성 : 작업 폴더 하나 만든 다음, 터미널 열어서 git init
2. github.com은 기본 브랜치 이름을 master가 아닌 main으로 사용하라고 함→ 이렇게 입력하면 기본 브랜치 이름 변경 완료!
3. git branch -M main
4. 늘 하던대로 commit 하면 됨
5. 로컬 저장소 → 원격 저장소에 업로드
  - git push -u 원격저장주소 main → 로컬 저장소의 main브랜치를 원격 저장소에 올리라는 뜻 (다른 브랜치도 올릴 수 있음)
  - github 로그인하라고 뜨면 로그인하면 됨
  - -u 옵션은 방금 입력한 주소를 기억해두라는 뜻! 다음부터는 주소 입력하지 않고 git push만 입력해도 잘 뜰거임
  - 원격 repository 주소: git clone할 때 버튼 누르면 http://로 시작해서 .git으로 끝나는 주소
  - 모르겠으면 주소창에 있는 url을 그대로 복사해와서 .git만 붙이면 원격 repository 접속 url이 됨

참고
- github에서도 파일 수정/삭제, commit 등 자유롭게 가능
- github원격 저장소는 비공개로 돌릴 수 있음

(3) 원격저장주소를 길게 입력하기 귀찮다면?

매번 주소를 길게 입력하기 귀찮다면? 주소를 변수에 저장해서 사용할 수 있다.

변수에 저장하려면 터미널에 git remote add 변수명 저장소주소를 입력하면 된다.

git remote add origin 변수명 저장소주소
# git remote add origin https://github.com/codingapple1/lesson.git

→ 이렇게 하면 “http://~~” 주소가 필요할 때마다 origin이라는 변수명을 쓸 수 있다!

참고로, -u 명령어는 방금 입력한 주소를 기억하라는 뜻이므로 1번 -u붙여서 했다면 git push까지만 입력해도 잘된다!
변수 목록을 살펴보고 싶다면? git remote -v

(4) 원격저장소에 있던거 그대로 내려받기 git clone

새로운 컴퓨터로 내가 하던 프로젝트 개발을 이어서 한다면? 또는 새로운 소스 코드를 공유 받아야 한다면?

귀찮게 컴퓨터간 소스 코드를 공유할 필요 없이 원격 저장소에 있던 내용을 그대로 내려받는다.

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

(5) 저장소에 올리지 않는 파일들은? .gitignore

원격 저장소를 효율적으로 쓰고자 한다면, 쓸데없는 파일은 굳이 commit하지 않는다.
이는 .gitignore파일을 하나 만들어 저장소에 올리지 않는 파일을 쉽게 명시할 수 있다.
- 이렇게 명시한 파일들은 git add . 해도 스테이징이 되지 않아 편리하다.
예시) 웹개발
- node_modules 폴더, 개인정보들이 있는 .env 파일은 올리지 않는다. (왜냐?! 어차피 package.json파일만 있다면 터미널에서 npm install 입력하면 자동으로 node_modules 폴더가 생성된다.)
작성방법은 찾아보기!

8. Github 사용법 2. 타인과 협업하기 (git clone, pull)

(1) 협업의 첫 단계, git clone

git clone은 위의 방법처럼 하면 되고, 다른 팀원이 함께 협업하려면 아래 조건이 있다.

그 팀원도 github 아이디가 있어야 함
그 팀원의 github 아이디를 collaborators 메뉴에 등록해놔야 함

(2) 팀원이 commit 하려는데 문제가 생겨요!

막 팀원이 된 사람이 바로 git push하려면 문제가 발생한다.

→ 원격 vs 로컬의 내용이 다르다면 로컬 저장소에서 바로 git push가 안된다. 이는 대충 git push해버리면 코드가 나중에 꼬일 수 있기 때문에 미리 예방하는 것이다.

즉, 이를 해결하려면?! git pull을 이용해야 한다.

💡 `git pull` 이용하면 현재 원격저장소 내용 가져올 수 있다.

git pull 원격저장소주소

→ 원격저장소에 있던 모든 브랜치 내용을 가져와 로컬 저장소에 합치라는 뜻이다.

→ 이렇게 하고나면 로컬이 최신상태가 되었기 때문에 git push가 가능하다.

⇒ 결론: 변동사항이 생겼다면, git pull하고나서 git push해주기!

참고

git pull 원격저장소 브랜치명 : 특정 브랜치만 가져올 수 있음
origin이라는 변수명 등록해놨다면? 당연히 사용가능함
이전에 -u 해놨다면? git pull, git push까지만 입력해도 잘됨
git pull 명령어는 git fetch + git merge 축약어임
- git fetch: 원격저장소에 있는 commit 중에 로컬에 없는 신규 commit을 가져오라는 뜻
- git merge : 그것을 merge
- 따라서 git pull할 때 팀원 2명이서 같은 파일을 건드릴 경우, merge conflict가 발생할 수 있다!! merge conflict는 branch 내용에서 다루었으니 참고

💡 결론
협업 시 git push하기 전에 뭐라 그러면 git pull을 많이 하면 된다.

9. Github 사용법3. 브랜치로 협업하기. pull request

(1) 브랜치 생성

1. Github 사이트에서 직접 브랜치 생성 가능

2. 아니면 로컬 repository 에서도 브랜치생성가능

git branch 브랜치명
git switch 브랜치명
git add .
git commit -m "~~기능"

예시)

로컬 브랜치를 원격에 올리고 싶다면?

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

git push 원격저장소주소 로컬브랜치명 : 특정 로컬저장소 브랜치 → 원격저장소
git push 원격저장소주소 : 모든 로컬 저장소 브랜치 → 원격저장소

(2) git hub 브랜치 합치는 건? pull request

브랜치에 올리고 나서, 기능이 완성되거나 만족스럽다면? 이제 기준이 되는 브랜치(main)와 합쳐야 한다.

이때 합치는 명령어는 위에서 살펴보았듯이 git merge로 합칠 수 있다.

이때 팀끼리 일하는 경우, merge 전 토론하거나 검토해야 하는 경우가 있다. 그래서 github에서는 pull request라는 기능이 있다.

이는 merge할지 말지 request를 보내는 기능이다.

이를 통해 내 브랜치를 merge해달라고 요청할 수도 있고, merge전 코드 검토도 할 수 있다.

[Pull requests] 메뉴에서 [New pull request] 파란색 버튼을 누르면 pull request생성이 가능하다.

그 다음 어떤 브랜치를 어디에 합칠 것인지 선택하고, 하단에 commit 내역, 변경내역을 잘 보고, 파란색 버튼을 누르면 pull request가 열린다.

이렇게 pull requests 메뉴에서도 확인할 수 있다. 이를 누르면 코드 리뷰도 할 수 있고, 토론도 할 수 있다.

잘 된 것 같으면 위의 merge pull request 버튼을 누른다.

merge하고나서의 모습

코딩애플에서 그림으로 정리해준 것을 보자.

create a merge commit:

3-way-merge실행
main브랜치 조회시 합쳐진 브랜치의 commit 내역도 전부 나옴
터미널에 git log --online --graph 하면 합쳐진 브랜치 그림도 나옴
⇒ 때문에 commit 내역 많으면 복잡하고 더러워질 수 있음

squash and merge:

합쳐질 브랜치의 commit 내역을 하나로 합쳐 main 브랜치에 신규 commit 생성
터미널에 git log --online --graph 하면 합쳐진 브랜치 안 나옴
commit을 하나로 합쳐서 main 브랜치로 순간이동 시켜주기 때문에, 사람들이 깔끔하다고 좋아한다고 함

rebase and merge:

합쳐질 브랜치를 main 브랜치 최신 commit으로 rebase하고나서 fast-foward merge
결과적 모습은 squash and merge와 비슷하지만, 합쳐질 브랜치의 commit내역이 전부 보존됨
터미널에 git log --online --graph 하면 합쳐진 브랜치 안 나옴

💡 결론
github등 원격저장소에서도 브랜치 만들 수 있음 Pull request (merge)할 땐 3개 중 마음대로 하면 됨!

💡 참고
원격저장소의 commit 내역을 과거로 되돌리고 싶은 경우, 로컬에서 `git reset --hard` 한 후, `git push -f`하면 됨. 근데 공동작업중인 사람들이 모두 영향을 받기 때문에 가능한 자제하기! github사이트에 있는 revert버튼을 쓰면 예전 코드로 되돌려주는 commit을 만들어줌

10. git flow / trunk-based 브랜치 전략

git branch를 깔끔하게 만드는 여러 방법들(git flow, github flow, gitlab flow, trunk_based …)이 있다.

이렇게 git branch를 깔끔하게 만든다면,

브랜치 관리가 쉬워진다.
팀원이 아무리 많아도 개발 절차가 매끄러워진다.

⇒ 따라서 프로젝트 리드하는 사람들이 알면 좋다!

(1) 안정적인 운영이 필요하다면? git flow

만들고 있는 프로그램이 항상 안정적인 release를 해야 한다면? git flow를 사용
git flow 전략(5가지)은 아래와 같이 운영
- main 브랜치
- develop 브랜치(개발용)
- feature 브랜치(develop에 기능 추가용)
- hotfix 브랜치 (main 브랜치 버그 해결용)
- 가끔 release 브랜치 (develop 브랜치를 main브랜치에 합치기 전에 최종 테스트용)
예시

1. develop 브랜치부터 생성

늘 그랬듯이, 기존 프로젝트를 그대로 사용하지 않고, 따로 복사한 develop 브랜치를 사용한다.

2. 신기능 개발은 feature 브랜치에 작성

신기능을 만들고 싶으면 develop 브랜치를 복사한 후, feature 브랜치에 각각 개발한다.
- ex) feacture/guild에는 길드 기능, feacture/friend에는 친구기능
- 참고) 브랜치 작명 시 여러 단어가 필요하면 보통 대시(-)나 슬래시(/) 사용
완료되면, develop브랜치에 merge
중요한 내용이 아니라면 squash and merge

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

바로 main브랜치에 합치기에는 불안할 수 있기 때문에 develop → release 브랜치에 이렇게 프로젝트 복사한 후 출시 준비
활용방식
- 이 곳에서 테스트나 QA 진행
- 버그를 발견하면 알아서 임시 브랜치 만들어 수정
- 작명방식은 release/1.0이런 식으로 지으면 예쁨
완성되면, main브랜치로 merge하고 유저에게 배포
개발도 계속 진행되어야 하니까 develop브랜치에도 merge해주기

4. 급한 버그픽스는 hotfix 브랜치

급한 버그를 발견했다면? main브랜치에서 hotfix와 같은 브랜치를 만들어 버그를 바로바로 수정
수정 완료하면 main 브랜치에 직접 merge
당연히 develop 브랜치에도 merge

5. 다 합치면?

💡 꼭 이렇게 해야만 하는가?
노노!! 한 때는 유행이었지만, 적합하지 않을 수 있다. 무조건 따라하지 말고, 이런 방식도 있구나 참고하여, 본인 마음대로 변형하여 사용하기~~

(2) Trunk-based 전략

Trunk-based? main 브랜치랑 기능 추가용 feature브랜치만 운영하는 전략
Why?
- 코드짠 걸 바로 대중에 배포를 해도 상관없는 프로그램이거나, 크게 바뀌는 업데이트가 없는 프로그램이라면, 굳이 브랜치를 많이 만들 필요가 없음!!
- 이럴 땐, 그냥 main 브랜치랑 기능 추가용 feature브랜치만 운영(=Trunk-based)하면 됨.
예시
1. 기능 추가, 버그 픽스가 필요하면 main 브랜치에서 새로운 브랜치를 하나 만들어 짠다. (브랜치마다 이름 잘 지어줘야 한다!)
2. 기능이 완성되면 main브랜치에 합친다.
3. main브랜치에 있는 코드를 필요할 때마다 배포한다!

특징
- 장점
  - 코드를 한 브랜치에서만 관리하기 때문에 편리함
  - 크게 개발해서 한번에 merge하는 것보다 작은 단위로 merge하기 때문에 더 안전함
- 단점
  - main브랜치에 있는 코드가 잘못되면 큰일난다.
  - 따라서 테스트나 코드 리뷰를 자주해야 한다.

💡 무슨 방식을 사용해야 할까 고민이라면?

이미 어느정도 개발이 진척되었거나 모두 코딩을 잘하는 경우? trunk-based

출시된 버전의 안정성이 중요한 프로그램들, 아직 뼈대가 확실하지 않아 연구식으로 개발하는 프로그램들: git flow

11. git stash로 잠깐 보관하기

(1) 코드를 잠깐 다른 곳에 보관하고 싶다면? git stash

예시는 적절한 게 생각나지 않아 코딩애플의 예시를 그대로 가져왔다.

aaaaa

파일 하나를 만들어 commit한다.

aaaaa
bbbbbb

이렇게 밑에 bbb어쩌고 코드를 짰는데 마음에 안든다.

이런 경우, 이 코드를 잠깐 삭제해버리고 싶으면 git stash명령어를 쓴다.

git stash

→ 방금 작성한 코드가 잠깐 다른 임시보관공간에 보관되고, 파일들은 최근 commit 상태로 되돌아감

staging이든 아니든 commit이 남겨진 파일들은 다 이동됨
새로 만든 파일인데 statging안되었다면 이동 안됨

git stash save "bbb 코드 짰는데 맘에 안듬"

이런 식으로 git stash 할 때 메모도 함께 입력할 수 있음

git stash list

git stash는 여러번 할 수 있다.
git stash된 코드 목록을 전부 출력해주는 명령어

(2) 보관했던 코드 다시 불러오려면? git stash pop

git stash pop

→ 임시 보관했던 코드를 불러온다.

pop하면 뭐가 떠오르는가? 바로 stack! stack은 LIFO! 즉, 가장 나중에 들어간 게 먼저 나온다.
마찬가지로 git stash pop하면 가장 최근에 보관했던 코드가 먼저 불려온다.

(3) stash 관련 여러 명령어들

git stash drop 삭제할id   # 특정 stash 삭제
git stash clear          # 모든 stash삭제

여기서 삭제할 id는 git stash list하면 보이는 0, 1, 2 이런 숫자들 넣으면 됨

git stash -p

전체 말고 일부 코드만 git stash할 때 사용
파일훑어주면서 stash할 지 의견 물어볼 때 y/n으로 대답하면 됨

Question

주석처리랑 무엇이 다른가?
- 거의 용도는 비슷함
- 주석처리 코드는 commit할 때 반영이 됨. 그렇게 되면 주석도 commit기록에 남기 때문에 더 더러워짐. 주석 처리 코드도 commit 하기 싫을 때 git stash사용하면 ㅇ용함
- 또는 A, B기능 만들어야 하는데 A는 완성됐고, B는 반쯤 완성된 경우, A는 빨리 commit하고 merge해야 할 때 B기능만 일단 git stash해놔도 좋음
브랜치 새로 만들어서 거기다 코드 짜는거랑 뭐가 다름?
- 같음. git stash 싫으면 간단한 브랜치 만들어서 거기 보관해도 됨

개인적 후기

진짜 175일 걸린 건 아님! 듣고 정리하고 또는 실습하는데 약 3시간 정도 걸림
git add, git push, git push origin, git clone 등 대표적인 건 알고 있었지만, git 취소하고 싶을 때 계속 인터넷을 찾아봐야 했고, git에 대해 너무 좁은 범위만 알고 있는 것 같아 강의 수강함
내가 생각한 것보다 훨씬 더 많은 정보를 체계적으로 배울 수 있었음. 나랑 같이 프로젝트 하는 친구들도 보면 도움이 많이 될 것 같음
예전엔 정말 그냥 막 git push하고 merge했는데 이제는 어느정도 알고 있으니까 나에게 필요한 것에 맞게 활용할 수 있을 것 같다는 생각이 듬

읽어주셔서 감사합니다!

저작자표시 비영리 변경금지

'📓Wiki' 카테고리의 다른 글

[Wiki] 유스케이스 & 테스트케이스에 대해 내 맘대로 쉽게 요약 (4)	2023.08.08