바로가기
Git
분산 버전 관리 시스템.
코드를 효율적으로 관리하고 백업하자.
깃 초기화
로컬 저장소 생성
(작업 폴더에서 git init 이후 변경사항을 추적합니다.)
git init스테이징
(변경 사항 Stage Area에 추가_ 커밋 대기 영역)
git add . //변경사항 전체 스테이징
git add 파일명1, 파일명2레포지토리에 추가
stage area에 있던 녀석들이 로컬 레포지토리에 추가됨.
git commit -m "커밋 메세지"
상태 확인
(작업 디렉토리와 스테이징 영역의 파일 상태, 현재 브랜치의 상태)
어떤 파일이 수정되었고 어떤 파일이 스테이징 되었고 어떤 파일이 커밋되지 않았나 등의 정보
git status로그 확인
git log --all --oneline //한 줄에
git log --all --graph //그래프 모양으로코드 보관하기
git stash //잘라내서 클립보드에 저장한다고 생각하자.
git stash save '메모'
git stash list (클립보드 확인)
git stash drop 번호 (특정 stash 삭제)
git stash clear (stash 전체 삭제)
git stash pop (가장 최근 stash 가져오기)
git stash apply stash@{n} (특정 번호 stash 가져오기)에디터 활용
(VSCode, intelliJ)
최근 커밋과 현재 파일 차이점 확인
(j, k키로 이동 및 q로 종료) but 완벽하지는 않음.
git diff
더 나은 Vim 에디터로 변경사항 보기
(h,j,k,l키로 이동, :q 혹은 :qa로 종료)
git difftool
git difftool 커밋아이디 //이 커밋과 변경사항 확인
git difftool 커밋아이디1 커밋아이디2 //커밋 간 변경사항 확인
더 나은 에디터로 보려면 extension 활용하기(ex. Git Graph)
복사본 만들어서 안전하게 작업하자!
브랜치 생성
(현재 브랜치에서 분기)
git branch 브랜치이름 (new)
git checkout 브랜치이름 (old)
현재 브랜치 변경
git switch 브랜치명브랜치 병합하기
1. 병합할 브랜치로 이동(target) 2. 덮어 쓸 브랜치 선택
git switch main
git merge 작업브랜치
//작업브랜치의 코드가 main에 합쳐짐Conflict (충돌)
같은 부분을 수정했을 경우 어떤 것을 남겨야 하는가?
충돌난 부분 확인 후 남길 코드를 결정하자.
MERGE 합치기
(github pr에서도 머지 방식 선택할 수 있음)
(3-way merge)
main 브랜치에서 새로운 브랜치를 파고 해당 브랜치를 main에 머지하면?
새로운 커밋이 메인 브랜치 라인에 생기며 머지가 된다.
(main 브랜치에도 새로운 커밋이 있는 경우)
(fast-forward merge)
main 브랜치에 만약 새로운 commit이 없는 경우?
그냥 새로 판 브랜치를 main으로 만들어버림
이것이 싫으면 git merge --no-ff 브랜치명 입력하면 3-way merge가 됨.
(rebase & merge)
시작지점을 옮겨서 일렬로 커밋 관리가 가능함
git log를 간결하게 확인하기 위해서 사용함.
but conflict 가능성이 높음.
git switch 새로운 브랜치
git rebase main
git switch main
git merge 새로운 브랜치
(squash and merge)
main 브랜치 커밋 이력을 깔끔하게 관리하기 위해 사용
(main 로그 확인 시 불필요한 브랜치 커밋 안 뜨도록)
git merge --squash 새브랜치브랜치 삭제
git branch -d 브랜치이름(merge 된 브랜치 삭제)
git branch -D 브랜치이름(merge 안한 브랜치 삭제)
파일 복구
git restore 파일명(가장 최근 커밋 내용으로 복구됨)
git restore --source 커밋아이디
git restore --source=<커밋ID> <파일이름>(특정 커밋으로 파일 복구)
git restore --staged 파일명(스테이징_add한거 취소)
커밋 취소
git revert 커밋아이디(여러개 가능)(revert . 변경사항을 정반대로 뒤집은 새로운 커밋이 생김)
즉 특정 커밋의 변경 사항을 취소하고, 취소한 내용을 새로운 커밋으로 만드는 것임.
가장 최근 커밋 취소
git revert HEAD특정 커밋 시점으로 모든걸 되돌리기
git reset --hard 커밋아이디(해당 커밋 이후 내역 다 사라짐_협업 시에는 위험하니까 걍 쓰지 말자)
git reset --soft 커밋아이디(해당 커밋 이후 내역을 다 지우는 대신 staging area에 넣어줌)
Github
로컬에만 저장하면 불안하고 협업하기 어려우니까 원격 저장소에도 백업하자.
초기화 및 main 브랜치 세팅(github은 master 이름 못씀)
변경사항 스테이징 및 커밋(로컬 저장소에 추가)
그리고 원격 저장소에 push
git init
git branch -M main
git add .
git commit -m "first commit"
git push -u 깃헙주소 브랜치명 (-u 사용하면 원격 저장소 이름 기억)
원격 저장소 지정 및 push
git remote add origin(변수명) github주소
//원격 저장소를 정해주는 코드다. (어디에 올릴건지? )
git push --set-upstream origin main
(처음 로컬과 원격 연결)
이후 그냥 git push 하면 됨git clone
zip 받지 말고 클론합시다.
git clone 원격저장소 주소
원격 저장소에 새로운 변동사항이 생기면 git push 못함
-> 원격 저장소의 내용을 로컬에 합쳐줘야 이후 push 가능.
git pull
원격 저장소의 새로운 커밋들을 가져와서 로컬에 merge함.
git pull //지금 브랜치 pull땡김
git pull origin 특정 브랜치
git pull은 git fetch + git merge이다.
git fetch - 원격 저장소의 신규 commit을 가져온다. 이후 내 로컬 브랜치에 merge.
작업 시작 전에 pull 땡기고 시작하자.
PR 날리기 (pull request)
(merge 요청)
협업 시 브랜치를 파서 작업하고, pr을 통해 검토하면 안전하게 브랜치를 관리할 수 있다.
(코드 리뷰 및 테스트를 통해 main 브랜치 등을 보호하자.)
아무나 main에 push하면 플젝 난리남.
GitFLow 전략
1. main
- 성역
2. develop
- main 복사본
3. feature
- 새로운 기능들(to develop) feature/chatting 같은 이름
4. release
- develop 복사해서 출시 전 여러 테스트 후 출시, main 및 develop에 머지해주면 좋음.
5. hotfix
-main에서 바로 파서 핫픽스
안정적으로 관리는 가능하나 CI/CD에 제약 있음.
플젝 규모가 작으면 오히려 부담스러움.
Trunk based 전략
브랜치 하나만 관리함. (main)
새로운 작업 생길 때마다 브랜치 파서 작업함.
-> 테스트 확실히 자주 해야함.
작은 규모의 플젝일 때 자주 사용함.
단 적극적으로 PR과 코드리뷰를 진행하는 것이 좋다고 생각함.
'General > Git, GitHub' 카테고리의 다른 글
| 1. 로컬 프로젝트를 GitHub에 푸쉬하는 방법 (Git, GitHub란?) (0) | 2023.02.08 |
|---|
