Git & Github

Davina·2022년 12월 16일

git github 코딩애플

Git/Github

목록 보기

1/1

Why using git?

파일 변경 내역을 보존하고 관리하기 위해

How to install?

Homebrew 검색해서 사이트에 보이는 긴 설치명령어를
터미널에 그대로 입력
password 입력하라고 하면 맥북 비번 입력
설치 끝나면 커맨드 2개 입력하라고 나오는데 2개 각각 터미널에 입력
brew install git 하면 설치 끝
기본 브랜치 이름 master → main으로 변경
```
git config --global init.defaultBranch main 
```

이 컴퓨터에서 git 처음쓴다? ⇒ 사용자 등록

git config --global user.email "홍길동@naver.com"
git config --global user.name "홍길동"

Git 이용법

작업 폴더에서 git 이용

//터미널 -> 저장소 생성
git init

파일의 현재 상태 기록해두려면

//기록을 남길 파일 고르기
git add 파일명
//여러 파일 기록남길때
git add 파일명1 파일명2
//모든 파일 기록남길때
git add .

//내 위치: 중간에서 staging area

//선택한 파일의 기록을 스냅샷 찍기
git commit -m "메세지" 

//이후 내 위치: repository

기록 상태 확인하기

# 다음 커밋을 위해 현재 디렉토리에서 수정된 파일을 확인할 수 있습니다.
git status

commit 내역 조회

git log --all --oneline //commit 아이디도 나옴

바로 전 commit vs 현재파일 차이점 보기

# 스테이지되지 않은 변경 사항을 보여줍니다.
git diff

# 스테이지했지만 커밋하지 않은 변경 사항을 보여줍니다.
git diff --staged

git difftool
:q //종료

Git Branch 생성

= commit의 복사본 만들기

branching은 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법

처음에 Git repository를 생성하면 나오는 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성하는 경우, 기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드 추가 및 삭제 가능

branch 생성

git branch 브랜치명 //생성
git swith -c 브랜치명 //생성하고 이동
git checkout -b 브랜치명

git switch 브랜치명 //브랜치로 이동
git checkout 브랜치명

반영

git add .
git commit -m "메세지"

git switch main/master //반영하고 싶은 브랜치로 이동

//이때 HEAD=>내 현재 위치
git merge 브랜치명 //브랜치명에 있는 변경사항이 main/master 브랜치에 합쳐짐

//이때 똑같은 위치에서 변경사항이 발생 시 conflict 발생
//해결법
//1. 최종적으로 원하는 코드만 남기고
//2. git add
//3. git commit

merge 방법

기능 개발이 끝나면 브랜치를 main 브랜치와 합칠 수 있습니다.

머지된 feature 브랜치는 이미 dev 브랜치에 기록이 완벽하게 남아있기 때문에 굳이 남겨둘 이유가 없어 삭제를 권장합니다. 원격 리포지토리에서 pull request가 성공적으로 마무리되면, 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있습니다.

merge 완료된 브랜치 삭제 방법

git branch -d 브랜치명

//merge안한 브랜치 삭제
git branch -D 브랜치명

case 1. 각 브랜치에 신규 commit이 있는 경우 ⇒ 3 way merge

git switch main //메인 브랜치로 이동
git merge feat //feat 브랜치를 main브랜치로 병합

중심 브랜치로 이동해서
git merge 새로운 브랜치명
모든 변경 사항이 반영된다~

case 2. 기준 main branch에는 신규 commit이 없고 새로 생성한 브랜치에만 신규 commit이 있는 경우 ⇒ fast-forward merge

새로운 브랜치 너가 main해라!

case 3. git rebase & merge

새로운 브랜치로 이동해서
git rebase 중심 브랜치명
중심브랜치로 이동해서
git merge 새로운 브랜치명
모든 변경 사항이 반영된다~

case 4. squash & merge

모든 변경 사항이 반영되는게 아닌 최종 결과물만 깔끔하게 딱!
git merge —squash 새브랜치

내 실수 복구하기 ⇒ 과거로 쓩 💨

파일 복구하기

//바로 전 commit 시점으로 파일 복구하는 법
git restore 파일명

//특정 commit 시점으로 파일 복구하는 법
git restore --source 커밋아이디 파일명

//staging 취소하는 법
git restore --staged 파일명

commit 취소하기

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

//최근 커밋 취소
git revert HEAD

과거로 모든걸 되돌리기

git reset --hard 커밋아이디

//리셋인데 변동사항 지우지 말고 스테이징 해놓기
git reset --soft 커밋아이디

//리셋인데 변동사항 지우지 말고 unstage 해놓기
git reset --mixed 커밋아이디

🚫 팀원분이 dev/front에서 수정 중에, 내가 dev/front에서 다른 수정내역을 push해서 팀원분의 변경 내역이 push가 안됐음..

[현석, 다솜’s 에러 사진]

commit한 내역을 되돌려서 해결 (push취소)
git reset --hard [commit id]
github 원래대로 돌려놓기
git push -f origin master

Github

⭐ <개념 알고 가라>

git
⇒ 버전 관리 프로그램

repository
⇒ git이 파일 기록해두는 장소

원격 저장소 = 온라인 repository

컴퓨터 고장나도 안심

협업이 가능

ex) github

내 코드 올릴 땐 git push

//local 환경에서 repository 생성
git init

//기본브랜치 이름을 main으로 바꾸기
git branch -M main

//로컬 -> 원격으로 보내기
git push -u 원격저장소주소 올릴로컬브랜치명

//원격저장소주소 넘 길어서 -> 변수 문법 사용하기
git remote add 변수명 주소
git push -u 변수명 올릴로컬브랜치명 //으로 사용 가능해짐!

//-u를 사용하면 그 이후부터 주소가 기억되기 때문에 
git push //만 해도 자동으로 보내진다!

타인과 협업하기 (git clone, pull)

//소스코드 내 로컬에 다운받아오기
git clone 저장소주소

//원격저장소에 다른 팀원이 push한 새로운 변경사항이 생기면 난 push를 못하게 된다. 
//그 원격저장소 -> 로컬저장소로 가져오기
git pull 원격저장소주소 브랜치명
//or
git pull origin(변수명) 브랜치명

//pull로 받아온 다음 내 변동 사항 push해~!
//팀원도 내꺼 다시 pull로 받아가고 다시 push해~!

git fetch = 원격저장소에 있는 commit 중에 로컬에 없는 신규 commit 가져와

git merge = 그걸 merge해

git pull = git fetch + git merge

브랜치로 협업하기 (pull request)

github에서 직접 브랜치 만들어도 되고,

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

//branch 생성
git branch 뉴브랜치명

//해당 branch로 이동
git switch 뉴브랜치명

git add .
git commit -m "메세지"
git push 저장소이름 뉴브랜치명

상기 내용까지 완료되면 Github으로 와!!

main branch로 해당 뉴브랜치를 merge하기 전 코드리뷰 필요! => pull request!

팀원 또는 팀장에게 코드 리뷰 받고 → merge 담당자가 merge 승인하면 됨~

<merge 방법>

rebase and merge - 변경 사항, 모든 사항이 밀려 올라가는 느낌으로 merge된다.

squash and merge - 변경 사항이 하나로 합쳐져서 딱 1개의 점이 merge된다.

merge commit - 변경 사항 다 가져오고, 그 위에 합쳐진 merge commit 점 1개도 딱 찍기

코드 잠깐 보관 (git stash)

주석 처리하면 되지 왜 stash써?

commit 할때 주석도 다같이 올라가기 때문에 깔끔하게 하기 위해서~

//방금 친 코드 잠깐 잘라내서 보관 좀
git stash 

//보관된 코드 목록 조회 => 최근 commit과의 차이점을 전부 보관해줌
//but staging 안해놓은 새로운 파일은 stash 안될수도 있어
git stash list

//메모도 적고 싶으면
git stash save "메모"

//stash된 코드 다시 불러오기
git stash pop //가장 최근 것부터 불러옴

//stash 1개 삭제는 
git stash drop 번호
//전부 삭제는
git stash clear

Git Flow

main (배포용)

현재 코드임 → 얜 건들지 말고 일단 안전 → 4번 과정까지 다 완성되면 merge해서 배포!
develop (개발용)

3번 feature에서 잘되면 develop 브랜치에 merge하고
feature (develop에 기능추가용)

분류를 세세하게 나누기를 원하는 회사에서는 refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 합니다.
```
hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제
```
⇒ 더 많은 사례 Conventional Commits

여기서 신기능 개발해봐~
release (출시 전 테스트)

2번과정까지 맘에 들어? 이 과정에서 테스트 해봐
hotfix (main 브랜치 버그해결용)

main에서 배포나갔는데 유저들이 버그 발견 → 급히 수정 원하면 hotfix에서 수정하고 다시 main에 merge

Trunk-based 전략 (github flow도 비슷)

잡다한 브랜치 없애~

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

브랜치마다 작명 잘하는게 중요합니다.
기능이 완성되었으면 main 브랜치에 합칩니다.

이제 브랜치 쓸데없으니 삭제합니다.
main 브랜치에 있는 코드를 필요할 때 마다 유저들에게 배포합니다.

⛔️ 에러이슈

🚫 feat/front/all branch에서 작업하고 다솜님이 로컬의 dev/front브랜치에서 pull을 받아오려고 했으나, dev/front에서 feat브랜치가 자동 병합이 되면서 가져와짐.

→ 이럴땐, 다솜님 로컬에서 동일한 브랜치를 새로 생성한 후, git pull을 받아와야 merge를 피할수있음!

🚫 에러!!!!! gitignore에 node modulues가 있기 때문에 파일이 커 push되지 않음!
그래서 git clone 받아와도 node modules 안깔림 (package.json은 존재하고, npm install 하면 uptodate이라고 뜸)

⇒ 원하는 디렉토리 ex)”front” 에서 통합 터미널을 킨 다음 npm install을 다시 해줌으로써 해결

Davina

[많을 (다) 빛날 (빈)] 빛이나는 사람이 되고 싶습니다