GitHub 사용하기

git 설치법 (for 윈도우)

git이란?

• 버전관리 서비스.
• 작업한 코드들 기록하고 보관 가능, 과거로 빠꾸 가능, 과거 작업 내용 열람 가능 등 안정적인 개발가능

git 설치하기

1. git windows 검색
2. 버전에 맞는 파일 다운 받아서 설치하면 끝
3. 체크 잘 하기
   • Choosing the default editor used by Git: Use Visual Studio Code as Git's default editor 선택
   • Adjusting the name of the initial branch in new repositories: Override the default branch name for new repositories > main (or master)

컴퓨터에 git 이름 등록하기

아래 두 명령어를 차례로 입력한다.

git config --global user.email "이메일"

git config --global user.name "이름"

작업 폴더에서 git 쓰고 싶으면

git 소프트웨어가 폴더를 감시한다

git init

파일 기록하기(add, commit)

공간

작업 폴더 -> (gitadd) staging area -> (gitcommit) repository(저장소)

특정 파일 현재 상태 기록하기

1. git add로 기록할 파일부터 고르고

git add 파일명

1. 고른 파일 기록 명령하기

git commit -m '메모'

여러 파일 스테이징하기

git add 파일1 파일2 ...

모든 파일 스테이징하기

git add .

상태창 열기

git status

commit 내역 조회

git log --all --oneline

git add, commit, diff 쉽게 하는 법(VS Code)

터미널에서 직접 입력하기보다, 요즘은 웬만한 에디터에는 깃이 내장되어 있어서 이걸 이용하면 된다.

git diff

• 최근 commit vs 현재 파일 차이점 보여줌
• commit하기 전에 현재파일 vs 최근 commit 차이점 확인하는 습관을 들이자.

git diff

• j / k 키로 스크롤바 조작
• q는 종료

근데 git diff 기능은 쓰레기같다. 코드가 길고 복잡해지면 이걸로만 보기는 너무 힘들다.

시각적으로 git diff 보기

git difftool

• vim 에디터가 뜬다
• h, j, k, l로 방향키
• q로 종료

현재파일 vs 특정파일 비교하기

• git log --oneline --all 를 입력해서 커밋아이디를 보고 과거 커밋과 현재 파일을 비교하여 볼 수 있다.

git difftool 커밋아이디

특정커밋 vs 특정커밋 비교하기

git difftool 커밋아이디1 커밋아이디2

근데 요새 에디터가 너무 잘 되어 있어서 difftool도 쓰레기임.

vs code의 경우 extensions에서 git 검색하고 관련 앱들 다운받아서 활용하면 된다.

• Git Graph: git log가 필요없는 정도.

git branch 만들기

파일 복사본 만들어서 거기에 먼저 코드짜보면 훨씬 안정적으로 코드를 짤 수 있다.

branch 기능 이용하면 복사본을 만들기 쉽다.(commit의 복사본)

브랜치 생성하기

git branch 브랜치명

브랜치로 이동

git switch 브랜치명

혹은

git checkout 브랜치명

브랜치에 합치기

1. 기준 브랜치로 이동
2. 명령어 입력

git merge 합칠브랜치명

1. 동일 파일을 모두 수정한 경우 충돌(conflict) 발생 -> 수정해야 함
   1. 원하는 코드만 남기고
   2. git add
   3. git commit

다양한 merge 방법

case 1) 3-way

각 브랜치에 신규 commit이 있는 경우 (일반적으로 발동되는 merge option)

case 2) fast-forward

기준 브랜치에 신규 commit이 없는 경우, 새로 생성한 브랜치를 main 브랜치로 지칭하여 두 브랜치를 합친다.

이런 상태에서 merge하면 git이 자동으로 이렇게 해준다.

근데 만약 fast-forward를 하기 싫다면 아래 명령어를 입력하여 merge 한다.

git merge --no-ff 브랜치명

(+) 브랜치 삭제

브랜치가 합쳐져도 브랜치는 남아있다.

merge 완료된 브랜치 삭제

git branch -d 브랜치명

merge 안한 브랜치 삭제

git branch -D 브랜치명

case 3) rebase & merge

rebase를 하면 브랜치 시작점을 옮길 수 있다.

rebase해서 브랜치 시작점을 main 브랜치의 최근 커밋으로 옮기고 fast-forward merge를 해서 브랜치를 합칠 수 있다.

일반 fast-forwawrd는 메인 브랜치에 신규 커밋이 있으면 못한다. 근데 rebase를 이용하면 가능하다.

rebase 쓰는 이유

• 브랜치 없이도 코드 잘 짜는 고수 같음
• 3-way-merge는 나중에 git log 출력할 때 복잡해보임. 간단한 짧은 브랜치들은 이거 쓰면 깔끔해보임.

단점

• conflict 엔딩 많이 남

일반 merge 하고 싶으면

1. 중심 브랜치로 이동해서

2. git merge 새로운 브랜치명

rebase & merge 하고 싶으면

1. 새로운 브랜치로 이동해서

2. git rebase 중심브랜치명

3. 중심 브랜치로 이동해서

4. git merge 새로운브랜치명

case 4) squash and merge

3-way merge 많이 하면 나중에 커밋 내용들이 더러워질 수가 있다.

그리고 github에서 봐도 3-way merge를 다 하면, 메인 브랜치의 commit 내역을 출력하면 합쳐진 브랜치의 commit 내역들이 모두 쓸데없이 메시지가 보여준다. 왜냐하면 선으로 이어진건 모두 출력이 되기 때문이다.

main 브랜치 로그만 보고 싶어도 쓸데없이 합쳐진 브랜치의 로그들도 다 보인다.

이게 싫으면 선을 끊어주면 된다. 선으로 이어져있으면 로그가 다 보이니까. rebase 해도 되고, squash and merge를 해도 된다.

git merge --squash 새브랜치

메인 브랜치로 이동해서 merge를 할 때, 새로운 브랜치에 있던 커밋들을 다 합쳐서 메인 브랜치의 새로운 커밋 '하나'를 생성한다.

Recap

초보일 때는 어떤 방식으로 merge할지는 자유다.

근데 나중에 입사하면 팀마다 branching/merge 가이드가 있을거다. 거기에 따라서 merge 하자!

코드 짜다가 실수했다 되돌아가기

restore ➡️ 파일복구가능

최근 commit 상태로 되돌아가는 법

git restore 파일명

특정 commit 시점으로 파일 복구하는 법

1. git log --oneline

2. 돌아가고 싶은 커밋아이디를 본다.

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

특정 파일 staging 취소하는 법

git restore --staged 파일명

revert ➡️ commit 복구가능

commit 취소하는 법

이전 커밋을 삭제해주세요 이런 명령어는 없다. 과거조작은 불가능하다.

특정 부분에서 작업한 걸 제거하는 commit은 생성 가능하다.

git revert 커밋아이디

commit 여러개 취소 가능

git revert 커밋아이디1 커밋아이디2

최근 commit 취소 가능

git revert HEAD

merge commit도 취소 가능

reset ➡️ 과거로 이동가능

과거로 모든걸 되돌리기

특정 커밋이 생성된 시점으로 모든 걸 아예 돌릴 수 있다. (타임머신타고 과거로~!)

git reset --hard 커밋아이디

리셋인데 변동사항 지우지 말고 스테이징 해놓기

git reset --soft 커밋아이디

리셋인데 변동사항 지우지 말고 unstage 해놓기

git reset --mixed 커밋아이디

⚠️주의: 협업시엔 사용 금지!

Github 사용법

1) 내 코드 올릴 때: git push

2) 타인과 협업하기: git clone & pull

원격저장소 복제

git clone 저장소주소

팀원과 협업하려면

Settings > Access - Collaborators > Manage access > Add people 버튼 눌러서 초대하기

원격저장소 -> 로컬저장소

원격저장소에 변동사항이 생기면 git push를 못한다. 원격저장소 최신내용이 로컬저장소에 있을 때만 git push 가능하기 때문이다.

git pull 원격저장소주소 브랜치명

-u 로 기억을 잘 해놨다면 그냥 git pull 만 입력해도 된다.

특징

1. git pull 할 때 브랜치명시가능
2. git pull은 git fetch + git merge를 동시 처리해줌
   • git fetch: 원격저장소 신규 commit 가져오기
   • git merge: 내 브랜치에 merge
   • 그래서 conflict 발생 가능 -> 대처: 두 코드를 compare하고 가져옴

Recap

git push하기 전에 git pull 부터 해야 한다.

3) 브랜치로 협업하기: pull request

많은 동료들이 한꺼번에 동시에 git push를 하면 대참사 일어난다. 그래서 개발자마다 브랜치 만들어서 개발하고 merge 하는게 안정적인 협업방법이다.

브랜치 만들기

1. github.com에서 브랜치 생성가능

브랜치명 드롭다운 누르기 > 브랜치명 입력 > Create branch: '브랜치명' 클릭

브랜치 관리하기

브랜치명 드롭다운 옆에 'n branch' 버튼 누르기

2. 로컬저장소에서 브랜치 만들고 push해도 똑같음

브랜치 만들기

git branch 브랜치명

생성한 브랜치로 이동

git switch 브랜치명

코드 작성 및 푸시

git add .
git commit -m '만들었음'
git push 저장소명 브랜치명

Q. 브랜치 이름 중복되면?

A. 알아서 중복 피해야 한다.

Q. 원격저장소 브랜치를 merge하고 싶으면?

A.

• github 안에서 하거나
• 로컬에서 해서 push 하거나

근데 혼자 할 땐 그냥 해도 되는데 협업하는 경우에는 마음대로 merge하면 안되니까 온라인으로 merge하는 경우가 잦다.

Pull Requests

git repository의 메뉴에서 Pull requests에 들어간다.

그리고 'new pull request' 버튼을 누르면 새로운 pull request를 오픈할 수 있고, merge 요청을 할 수 있다.

• base: 합칠 브랜치명 선택
• compare: base에 합쳐질 브랜치명 선택
• 아래에 커밋 내역 확인

그리고 'Create pull request' 버튼을 누른다. 이제 공동 개발자들이 이 pull request를 보고 검토할 수 있고, 여기에 댓글도 남겨서 피드백을 줄 수 있다.

취소하거나 승락(Merge pull request)할 수 있다.

근데 conflict가 나는 경우엔 해결해야 한다.

'Resolve conflicts' 버튼을 누르고 코드를 compare하여 어떤 코드를 남길지 고르고 'Mark as Resolved' > 'Commit merge' 버튼을 눌러 저장한다.

이제 승락을 하는데, 세 가지 merge 종류 중 고를 수 있다.

1. 3-way merge (=create a merge commit)
2. squash and merge
3. rebase and merge

git flow / trunk-based 브랜치 전략

프로젝트 커져도, 사람 많아도, branch와 merge를 깔끔하게 하고 싶다면 git 전략을 알아야 한다.

• GitFlow
• Github Flow
• Trunk-based
• Gitlab Flow
• ...

GitFlow 전략

가장 유명한 전략이다. 총 다섯가지 브랜치로 이뤄진다.

브랜치 종류

1. main
2. develop
3. feature
4. release
5. hotfix

순서

1. develop에 main을 복제한다.
2. feature 브랜치에 신기능 개발해보고 잘되면 develop에 merge한다.
3. 신기능이 develop에 완성되어 출시해도 된다 하면 임시 브랜치 release에 push하여 출시 전 마지막으로 여러가지 테스트를 하면서 수정한다.
4. 완성되면 release를 main에 merge한다.
5. 다음 버전도 계속 개발이 진행되어야하므로 release는 develop에도 merge 해야 한다.

출시 후 갑자기 버그를 발견했다면?

1. main 브랜치를 복제한 hotfix 브랜치를 만든다.
2. hotfix에서 코드를 수정하고 수정이 다 되면 main에서 merge한다.

단점

• CI/CD 이런거 하는 곳은 안좋아함
• release도 겁쟁이인 경우에만 쓰는 거지, 그냥 자기 식대로 하면 된다.

Trunk-based: "브랜치 하나만 잘 관리하자"

"develop 브랜치 이런거 왜 만드냐"

순서

1. main 브랜치 하나만 운영한다.
2. 새로운 기능이 필요하다면 그 때마다 feature1, feature2, ... 브랜치를 파서 바로 main에서 merge한다.

장점

• 소스코드가 한 곳에 있어서 관리할 필요가 없다.

단점

• 바로바로 유저에게 배포하기 때문에 테스트를 많이, 자주 해야 한다.

=> 주로 안정화된 프로젝트들이 잘 쓴다.

git stash로 코드 잠깐 보관하기

코드를 짜다가 코드가 맘에 안들어서 다른데 잠시 치우고 싶다, 할 때 git stash 명령어를 사용하면 임시 저장소에 코드를 저장할 수 있다.

코드 임시공간으로 이동

git stash

보관된 코드 목록 조회

git stash list

메몰도 적고 싶으면

git stash save '메모'

stash한 코드 다시 불러오려면 (가장 최근 것)

git stash pop

stash한 것 삭제

1개 삭제)

git stash drop 번호

전부 삭제)

git stash clear

➡️최근 commit과의 차이점을 전부 보관해줌

➡️ staging 안해놓은 새로운 파일은 stash 안될 수도 있음

➡️ stash 여러 번 가능

Q. 주석처리하면 되지, 왜 git stash 하냐?

A. 주석처리 코드는 commit하면 다 반영이 된다. 쓸데없는 코드를 숨기고 깨끗하고 commit하고 싶을 때 쓴다.

Q. branch 만들어서 거기 작성해도 되는 거 아니냐?

A. 똑같다. 그래서 stash하든, 브랜치 만들던지 마음에 드는 방식으로 하면 된다.