Git

Git 명령어

Dexlee 2021. 11. 5. 14:12

1. Git show 

  • 현재 브랜치의 가장 최근 커밋 정보를 확인
  • Git show head : HEAD 포인터가 가리키는 커밋 정보를 확인.
  • head == @,  ~ == ^
  • git show head(@)
    • head를 보여줌.
  • git show @~
    • 한 커밋 이전
  • git show @~3
    • 3커밋이전(숫자에 따라 그 숫자 이전으로 간다)

2. Git branch

  • 하나의 작업 공간을 만듦.(그래서 개발자 간에 작업 공간이 충돌 나지 않도록)
  • Branch들 확인
    • Git branch branch_name : 브랜치 생성
    • Git branch -d branch_name : 삭제
    • Git branch -r : remote에 있는 브랜치까지 확인
    • git checkout -b NIMDA_3ND-pub origin/NIMDA_3ND-pub
      • 라고 하면.. 원격 저장소도 바꾸면서 로컬 브랜치도 바꿀 수 있다.

 

3. Git status

  • branch가 어디에 있는지 확인
  • Untracked 인지 staged 상태인지 등을 확인

4. Git log [-5]

  • 커밋 단위로 history가 쌓임.
  • log를 볼 줄 알아야 develop, release, hotfix, branch가 난무할 때 merge 방향이나 순서를 이해할 수 있음
  • 위에 있는 것이 최신. - Desc

5. Git add .(혹은 경로와 파일명을 적어줌 그것 하나만 add 하고 싶은 경우)

  • Untracked 나 modified 상태의 파일을 staged 상태로 만들어줌.

6. Git commit -am

  • -a : add를 같이함.
    • 보통 modified 상태에서 이 -a 옵션을 줘서 git add 명령어를 건너뛰는 경우가 많다.
  • -m : message를 넣음.
  • 실무에서 한 작업(기능, 피처) 단위로 한 커밋 권장.
  • 파일을 unmodified 상태로 만듬.
  • Git 시스템에 영구적으로 변경을 저장.
  • SHA-1 알고리즘을 적용한 해쉬값을 키로 생성.

7. Git checkout branch_name

  • 다른 브랜치로 이동
  • -b : git checkout -b branch_name : 브랜치를 생성하고 그 브랜치로 이동
  • Tips
    • 커밋의 hash 값을 알면 시간 여행이 가능하다.(즉, 이전에 커밋해둔 상태 값으로 이동이 가능함)
    • Git log로 hash 값을 확인.
    • Git checkout hash_value를 입력하면 그 브랜치에서 전에 커밋한 내용으로 접근할 수 있음.
    • 그리고 돌아가는 명령어는 git checkout the_branch_name  그 브랜치를 입력하면 최신 상태로 돌아갈 수 있음.

8. Git push origin [remote저장소 이름] [branch_name]

  • 로컬 브랜치의 정보를 원격 저장소로 업로드
  • Clone 한 리모트 저장소에 쓰기 권한이 있어야 한다.
  • 같은 브랜치로 여러 명이 받아서 누군가 push를 했다면 나는 push가 안됨.
  • 다른 사람이 작업한 것을 가져와서 합친 후에 (merge or rebase) push 할 수 있음
  • Git remote : remote 저장소 이름을 확인 가능. 보통 origin
  • -f (혼자 작업할 때만 사용. 굉장히 신중히)
    • 내 로컬 브랜치로 원격 브랜치를 덮어 씌운다.
    • 내가 혼자 작업하던 feature 브랜치에서만 사용해야 함.
    • 누군가 악의적으로 망칠 수도 있으니 보통 마스터에 push 할 수 있는 권한은 주지 않음.

9. Git pull origin [branch_name]

  • Clone 한 서버에서 데이터를 가지고 오고 그 데이터를 자동으로 현재 작업하는 코드와 merge(변경된 코드를 합쳐줌)
  • 그래서 만약 내가 작업하고 있는 부분이 있다면 git fetch부터 해줘야 한다.**

10. Git fetch

  • 서버에서 데이터만 가져오고 자동으로 코드를 합치지는 않음.(merge는 안 함)
  • 즉, 변경점은 합쳐지지 않고 있어서 fetch 후 pull도 꼭 해줘야 한다.

11. Git diff

  • 파일 변경 내용 보기.

12. Git stash [option] [stash@{num}]

  • 모든 옵션에 특정 stash의 값을 가져올 수 있다.
  • 작업하던 내용을 스택에 임시 저장
  • 브랜치에서 작업을 하다가 다른 브랜치로 변경해야 하는데 커밋은 하고 싶지 않은 경우
  • stack처럼 작동한다.
  • Stash, pop(stack에 있는 내용을 꺼내옴)의 명령어를 많이 사용
  • Git stash list : stash stack 안에 몇 개가 쌓였는지 확인.
  • Git stash pop : stack에 있는 내용을 꺼내와 적용함.
  • stack안에 있는 내용이 여러 개인 경우, commit을 한 후 다시 가져와야 modified로 적용이 된다.
  • 그리고 최종 commit을 해서 push를 하면 된다.
  • git stash pop stash@{1}
    • 이렇게 각 stash 번호로 특정 값을 가져올 수 있다.
  • git stash branch branch_name stash@{0}
    • stash에 있는 내용을 새로운 브랜치를 만들어서 거기에 놓는다.
  • git stash apply
    • 가장 최근에 저장한 stash를 복원한다.
  • git stash drop
    • 가장 최근에 저장한 stash를 삭제한다.
  • https://www.popit.kr/git-stash/

13. Git merge

  • 협업의 핵심. 다른 브랜치와 현재 브랜치를 합쳐서 코드를 합침.
  • 방식
    1. Fast forward 방식
      • 커밋들이 공통이고 대상 브랜치의 커밋만 증가했을 경우 단순히 HEAD만 옮겨짐
      • 다른 분이 먼저 git commit을 했다면, git pull로 그 commit 된 파일을 받고,
      • Git merge branch(다른 사람이 commit 한 브랜치)를 통해 head를 옮기는 방법.
      • 이때, 나는 commit을 하지 않는다.(그래서 커밋이 공통이라고 말할 수 있는 것)
    2. 3-way merge 방식
      • 두 갈래로 나온 변경들을 합쳐서 새로운 커밋을 만듦.
      • 다른 사람이 commit 한 내용을 내가 pull하고 나도 commit을 했을 때, 커밋이 공통이 아니라고 말한다.
      • 그래서 Git merge branch(다른 사람이 commit한 브랜치)를 해주면,
      • 다른 사람이 commit한 내용 + 내가 commit한 내용이 merge가 되어서 새로운 commit 된 log 한개가 추가되어서 볼 수 있다.
      • 그래서 총 3개의 commit된 내용을 확인 가능.
      • conflict
        • 그런데 이때.. 만약 같은 부분을 modified 했다면,, conflict 가 일어난다. 그래서 이땐, conflict가 난 부분을 vi file_name으로 들어가서 직접 수정을 해줘야 한다.
        • 수정 후 modified가 되었으니, 그 부분을 commit 해주면 안정적으로 merge가 일어난다.
    3. Squash
      • 대상 브랜치의 커밋들을 하나의 커밋으로 합쳐서 merge

14. Git rebase

  • 기능은 merge와 같다.(코드를 합친다. 하지만 방법이 약간 다름)
  • 내 브랜치의 커밋을 대상 브랜치의 위(다음)로 생성함.
  • 깔끔한 로그를 유지할 수 있음
  • 주의
    • Push 해서 누군가 사용하고 있는 커밋을 rebase 하면 안 된다.
      • 왜냐하면 해당 commit을 기반으로 작업을 했을 텐데 그 기반을 바꿔버리므로,
  • 방식
    1. Fast forward 방식
      • merge와 같다.
    2. 두 브랜치 모두 커밋이 있지만 충돌이 나지 않음(auto merging)
      • merge와 방법은 같지만 전에 커밋한 해쉬값이 아닌 새로운 해쉬값을 만들어서 branch(다른 사람이 commit 한 브랜치) 뒤에 생긴다.
      • 그래서 총 2개의 commit 된 내용을 확인 가능.
    3. 두 브랜치 모두 commit이 있고 충돌이 난 경우(conflict)
      • Git rebase branch(다른 사람이 commit 한 브랜치)를 쳤을 때, 충돌이 났다면,
      • —abort : rebase를 중단
      • —skip : 대상 브랜치의 내용으로 적용
      • —continue : rebase를 계속 진행.
        • 충돌 난 부분으로 들어가서 직접 수정을 한 후
        • Add or rm 명령어로 추가 혹은 삭제를 해준 후 rebase —continue를 입력해준다.
        • 이때 add edited_file_name(수정된 파일)을 add 해줘야 한다.
        • 주의할 점은 rebase는 commit을 해주는 것이 아니라 add를 해주는 것이다.
    4. 커밋 여러 개 하나의 커밋으로 만들기.
      • -i : 대화형 모드
      • Git rebase -i HEAD(@로도 표현 가능)-3(보고 싶은 commit log의 개수)
      • default가 pick이다. 여기서 pick을 fixup(f)로 합치고 싶은 개수-1개만큼 바꾸어주면 하나의 커밋으로 만들 수 있다.(물론 모든 내용이 merge 된 상태로) 

15. git reset @~ (하나의 커밋만 : commit과 add까지 되돌림 modified)

  • 상대를 이전 commit으로 되돌림.
  • 옵션에 따라서 커밋 이전 or 어느 단계(staged, modified, unmodified)까지 reset
  • git show @~
    • 돌아가고 싶은 곳을 확인해봄
  • git reset —soft @~
    • commit만 되돌린다. : staged
  • git reset —mixed @~ (default)
    • commit과 add 되돌림 : modified
  • git reset —hard @~. (협업에서 사용하지 말 것)
    • commit, add, 워킹 디렉터리까지 되돌려서 복구 불가능 (unmodified)

16. git cherry-pick

  1. 다른 커밋을 가져온다(복사)
  2. 복사하고 싶은 브랜치에서
    • git cherry-pick hash(가져오고 싶은 해쉬값)
    • 그 후 같은 값이기 때문에 그 전의 값은 지워줄 것.
    • git branch -d branch_name
  3. 사용 예제
    • release 브랜치에서 feature 브랜치로 따서 작업을 해야 하는데, develop 브랜치에서 feature 브랜치로 따서 작업을 했다고 한다면,
    • 이런 경우에는 기반 브랜치가 다르기 때문에, 원래에 따려는 release 브랜치로 돌아가서 거기서 feature 브랜치를 만들어서 develop에서 작업하던 feature 브랜치의 해쉬값을 가지고 온다.

17. git remote

  1. git remote add origin [git-address]
  2. git remote rm origin
  3. git remote -v
    • remote 확인
  4. git remote update
    • origin에 만들어진 브런치를 내려받는다.