Git
깃허브 꿀팁 찾아보기
Git(로컬)
사용자 등록
git config --global user.name "[이름]" git config --global user.email "[이메일]"인증정보 캐시
깃허브 인증이 비밀번호에서 토큰형식으로 바뀜
git config --global credentail.helper cache
-
일반적인 폴더와 깃 저장소로 쓰이는 폴더 구조 다름
깃 저장소 폴더는 숨겨진 영역이 있다.(ls -a로 숨겨진 .git폴더 확인 가능) -
깃 저장소 폴더의 저장공간 => 워킹 디렉토리 영역(working) + 임시 저장 공간(stage) + 실제 저장 공간(repository)
git add로 워킹 디렉토리 영역의 코드를 tracking해서 스테이지로 등록 -
워킹 디렉토리와 스테이지 구분
1. stage
unstage 상태의 파일들은 커밋할 수 없음(git add . 하면 전체 스테이지 등록)
커밋? 변경된 부분만 시간순서에 따라 저장(부모 커밋 기반으로 새로운 커밋 만듬)
2. unstage
스테이지(스테이지 영역을 캐시라고 봐도 됨, 임시 저장 장소 = 캐시)
캐시 목록에서 삭제법
git rm --cached [파일]한 번이라도 커밋을 했다?! rm --cached 대신 reset 명령어 사용
! 짤막 상식 => -나 --은 옵션 표기
3. commit
HEAD(최근 커밋 위치 포인터)가 가리키는 커밋을 기반으로 스냅샷하는 것
등록 커밋 동시에
git commit -am "[커밋메시지]"! -a옵션은 새 파일에는 적용불가
!! --allow-empty-message 메시지 없는 커밋, --amend 메시지 수정
- .gitignore 안에 나열한 파일들은 untracking함
!최상위 디렉토리에 둘 것
상태확인
git status로그확인
git log(명령어도 다양한 옵션이 있다는 걸 생각하자...)
브랜치
브랜치는 개발 분기점, 가상의 폴더로 작업(눈에 안보임)
git init하면 디폴트 브랜치는 master
git status로 현재 브랜치 확인 가능
git brnach -r 리모트브랜치 확인
! 리모트랑 로컬브랜치 이름 달라도 됨. 이름으로 연결파악보다는 트래킹되있는 걸 확인
!! 브랜치가 같은지 생각
브랜치 생성(HEAD 포인터 생성, 실제 브랜치는 커밋할때 생성됨)
git branch [브랜치이름] [커밋ID]마지막 커밋id 기준으로 브랜치 생성
(브랜치 해시 값 = 브랜치를 생성한 기준 커밋의 해시값)브랜치 삭제
git branch -D [브랜치이름] git push origin --delete [리모트브랜치]현재 브랜치 및 목록 확인
git branch
#브랜치 이동(HEAD 포인터 이동)
git checkout [브랜치이름]브랜치 작업 후 항상 커밋하기, 아니면 브랜치 이동 제한됨(워킹디렉토리에 작업이 남아있어 충돌 방지)
업스트림 트래킹 = 브랜치 추적
로컬 브랜치와 서버의 리모트 브랜치를 매칭
브랜치 매칭 확인
git branch -vv브랜치 매핑 작업(수작업)
-u옵션은 --set-upstream-to의 약자: 기존 브랜치를 특정 원격 브랜치로 추적
git branch -u origin/[리모트브랜치] [로컬브랜치]
Head
AHEAD 서버로 전송되지 않은 로컬 커밋 존재 = 로컬 브랜치의 커밋이 서버 커밋 개수보다 많은 경우
BHEAD 로컬 저장소로 내려받지 않은 커밋 존재 = 서버 커밋이 로컬보다 최신
.git/ref/ 폴더 안에 포인터 정보 있음
Github(서버)와 연결
- 협업이 아닌 개인 백업용으로도 많이 사용
- http 방식이 기본이지만 ssh는 인증서(공개키, 개인키) 만들어야 됨
서버 생성 및 삭제
git remote add [서버이름(origin 많이 씀)] [서버URL] git remote rm [서버이름]
서버 이름 변경
git remote rename [변경전] [변경후]원격저장소 목록 확인
git remote -v상세정보 출력
git remote show [서버이름]
푸시
git push [서버이름] [브랜치이름] git push [서버이름] [브랜치이름]:[새로운브랜치]원격저장소 복제
git clone [원격저장소URL]풀
git pull (최신 커밋을 현재 브랜치로 자동병합) git fetch (자동병합 x, 그냥 말그대로 커밋들만 가져온 것)
권장순서(충돌 방지)
- pull -> coding -> commit -> pull -> push
순서
로컬 저장소 생성(로컬)
- mkdir 새 디렉토리 만들기
- cd 저장소로 이용할 디렉토리로 이동
- git init 저장소 초기화
- (예시) echo "# [디렉토리이름]" >> README.md 소개파일 생성
- git commit -am "first commit" 등록 및 커
원격 저장소 생성(서버)
- 깃허브에서 새 repository 만들기
- 토큰 생성
저장소 연결
git remote add [서버이름] [서버URL]
잡기술
스태시(스테이시 걸~)
임시 저장
스태시
git stash save "WIP: 메시지":불러와 워킹 공간이랑 자동병합(스택 삭제 x)
git stash pop불러와 워킹 공간이랑 자동병합(스택 구조 상관 x, 삭제 x)
git stash apply stash@{0}스태시 복원 시 충동 예방 브랜치 만들기
git stash branch [브랜치이름]스태시 삭제
git stash drop스테이지 영역 언스테이지 영역 구분해서 스태시하는 옵션 있음
기본적으로 등록된(tracked,git add당한) 파일만 스태시함.
스택 구조
스태시 복원 할때 워킹공간은 깨끗해야 함.
워킹 공간 청소
git clean
병합
- Fast-Foward 병합: 현재 브랜치 기준으로 다른 브랜치의 모든 커밋을 병합
git merge [브랜치이름]
2. 3-way 병합: 부모 커밋이 2개(기준 브랜치에서도 커밋을 이어간 경우, 병합메시지 필요)git merge [브랜치이름] --edit
병합 명령 취소
git merge --abort병합 여부 확인
git branch --merged! 병합한 브랜치는 삭제하기
!! 그림 그려가면서 브랜치 파악하자
리베이스
베이스(부모 커밋) 변경, 일렬로 순차적으로 커밋 병합 시도
병합되는 브랜치 방향이 "병합"과 반대 => 브랜치가 바뀐다
HEAD 포인터까지 옮겨 주지 않는다 => 병합해줘야 함(Fast-forward)git rebase [브랜치이름]
리베이스 명령 취소
git rebase --abort! 그림 그려가면서 브랜치 파악하자
복귀
- 리셋(기존 커밋 삭제)
커밋은 없어졌지만 파일에는 내용 남아있음. 헷갈리지 말 것
- --soft: HEAD 포인터 위치 이동, 스테이지 상태 남겨둬서 바로 커밋 가능
- --mixed: 디폴트, 스테이지 상태 안 남겨둬서 바로 커밋 불가능
- --hard: 그냥 복원하면 하던거 삭제
! 로컬에서만 실행 추천git reset [옵션] [커밋ID(HEAD~ ,~2,~3...으로도 가능)]
- 리버트(기존 커밋 놔두고 새 커밋 생성)
git revert [커밋ID]
배포
태그 생성
git tag -a [버전] -m "[메시지]"git tag -a [버전] [커밋ID] -m "[메시지]"태그 삭제
git tag -d [버전]태그 동기화(Github releases 확인)
git push [버전]git push origin [버전]:[서버에 다르게 올릴 이름의 버전]태그 동기화 삭제
git push --delete [서버이름] [버전]
서브모듈
! 메인 저장소에서 이동해서 작업할 것
!! 실제 서브모듈 작업 -> 서브모듈 커밋, 푸시 -> 메인 저장소 풀, 커밋
!!! 하위저장소(복제 서브모듈) 작업 -> 하위저장소 커밋,푸시 -> 메인저장소 커밋, 푸시
git submodule add [서버URL][폴더이름]서브모듈 복제(메인도 같이 복제해야 함,관계성)
git submodule init git submodule update
Garbage 정리
git gc --auto
충돌이 일어나는 경우
- 서로 다른 브랜치에서 같은 위치에서 다른 작업을 커밋하고 병합할 때
충돌한 파일집합 확인
git ls-files -u충돌기록 확인
git config rerere.enabled.true
git rerere status출처
[Git 교과서][저자:이호진][출판사:길벗]
