Day22 - git 특강2

오늘 배운 내용

- 협업을 위한 git 사용법

- git bash 사용하기

협업을 위한 git 사용법

rewind 복습

git rebase는 3단계로 구성된다 

rewind = 커밋을 되돌리는 (잠시 내려놓는) 과정이다 

rebase내에서 rewind 과정이 자동으로 이루어 지지만 과거의 커밋으로 돌아가서 수정작업이 필요할때 

rebase 명령어를 활용하여 rewind(1단계) 과정을 구현할 수 있다

rewind후 내려놓은 커밋을 다시 올리기 위해 rebase --continue를 한다 

>>> git log --oneline --reverse # 오래된 커밋부터 확인
>>> git reabse -i --root # 멈추고싶은곳의 pick을 edit으로 수정
# 여러개를 수정했다면 이하를 반복
>>> git log --oneline
>>> git rebase --continue

 

 

rewind는 언제쓰는가?

내가 base를 fork 받아 commit a,b,c,d를 만들었다 

이후 회의에서 -> commit a,c는 지우고, b,d는 합쳤으면 좋겠다 라고 하신다면 그떄 rewind로 수정

이후 검증된 상태로 base에 pull request를 한다 

base에는 회의 후 검증된 commit들만 쌓이기 때문에 절대 base에는 임의로 rewind를 하지 않는다 

 

 

실습: 두번째로 오래된 커밋에 hello.txt 빈파일을 추가 하고 commit message  수정하기 

두번쨰 오래된 커밋에 작업하기 위해 rewind

커밋 수정을 위해 commit --amend 를 해야한다

>>> git rebase -i --root 
>>> git touch hello.txt
>>> git add hello.txt 
>>> git commit --amend # 메세지 수정
>>> git rebase --continue
>>> git show 855a939 # 수정된 commit 찝어서 잘되었나 확인

 

git repo 버전별 수정사항 확인하기

버전 관리가 되고 있는 경우 해당 버전에서 진행상황을 볼 수 있다

>>> git clone # git 주소
>>> git fetch --tags # 버전 불러오기
>>> git tag # 버전 확인
>>> git reset --hard v0.8
>>> ls

이때 reset --hard로 다시 버전을 불러올 수 있다

>>> git reset --hard origin/master
>>> ls

 

Git bash 사용하기

구름에서 하던것과 똑같이 하면 된다

웹에서 하던일을 로컬 PC에서 하는 차이만 있다 

Git - Downloads

-> 다운로드 후 git bash 실행

개인정보 입력, nano 에디터 다운

 

실습: 두번째로 오래된 history에 3개의 commit추가하기

 

두번쨰 오래된 커밋에 작업하기 위해 rewind

커밋 수정을 위해 commit --amend 를 해야한다

>>> git log --oneline 

>>> git rebase -i -root
>>> touch hello_1.c && git add hello_1.c && git commit -m 'Add hello_1.c'
>>> touch hello_2.c && git add hello_2.c && git commit -m 'Add hello_2.c'
>>> touch hello_3.c && git add hello_3.c && git commit -m 'Add hello_3.c'
>>> git log --oneline

>>> git rebase --continue

위 실습과 비슷하지만 조금 더 쉬운 버전이다 

2번째 history까지 rewind하고 commit을 쌓으면 된다

 

실습: 중간에 낀 commit 세개를 한개로 합치기

 

** 혹시나 다 날아갈수 있으니 branch만들어서 따로 놓기

실험하기 - master branch에서 긁어오기 - 실험하기 - master branch에서 긁어오기 반복 할 것 

master branch에서 긁어오는 방법

>>> git reset --hard master-temp

먼저 2번째와 3번째를 합치고 첫번째 커밋과 2+3을 합친다

>>> git rebase -i --root # 3번째에 edit
>>> git reset --soft HEAD~1
>>> git status 
>>> git commit --amend # 2+3

>>> git reset --soft HEAD~1 
>>> git commit --amend # 1 +(2+3)

>>> git rebase --comtinue

reset --soft 는 그 곳의 commit 기록은 지우지만 add 기록은 지우지 않는 것이다 

reset --hard는 그 곳의 commit 기록과 add 기록을 모두 지운다

 

실습: 2번째로 오래된 커밋 지우기

- 그냥 삭제하면 되기 때문에 hard로 지움

>>> git log --oneline
>>> git rebase -i -root # 그 위치가 head가 되게 돌아감
>>> git reset --hard HEAD~1
>>> git log --oneline
>>> git rebase --continue

실습: 팀을 이루어 각자 README.md를 수정하고 한명것만 merge한다 -> 이후 각자 rebase 해보기

팀repo를 내 깃에 fork

# clone
>>> git clone https://github.com/gymin97/test.git
>>> cd test
>>> nano README.md #파일 수정 
# or echo Gyeongmin Kim >> README.md 해도 됨
>>> git add README.md
>>> git commit -m 'Add name'
>>> git remote -v
>>> git push origin master

이후 깃허브 들어가서 contribute -> Open Pull request 

 

팀장이 강사님의 readme.md만 merge 

-> 이때 팀 repo가 업데이트 되어 내 로컬 pc repo는 old 버전이 된다 = rebase가 필요하다

>>> git remote add upstream https://github.com/kdigital-E-team/test.git
>>> git fetch upstream master
>>> git rebase upstream/master

이때 같은 README.md를 수정했기 때문에 rebase가 안됨

Rebase가 다 완성되지 못하는 단계 3단계를 하다가 충돌 -> 충돌나는 부분을 수정해주어야 한다

# 오류 내용 수정
>>> nano README.md
>>> git add README.md
# rebase 도중에 멈춘것이기 때문에 rebase를 continue하면 됨
>>> git rebase --continue
# 갱신하기 
>>> git push origin master -f

-> Open Pull Request 

 

이후 commit을 수정하고 push하는 경우 

>>> nano README.md # 수정할거 수정
>>> git add README.md
>>> git commit --amend
>>> git push origin master -f

-> Open Pull Request 

 

git blame

git blame - 소스코드를 시간대별로 어떤 수정을 했는지 조회가능

git blame src/node.cc # 보고자하는 파일

언제 쓰는가?

소스리딩하다가 이유를 모르겠을때 

버그가 발생했을때 그 버그가 탄생된 commit을 찾아 고쳐야 할 때 

 

blame 은 해당 소스코드가 refactoring 되거나 생성되거나, 수정된것이다

- 누가 처음에 만든건지 알수 있을수도있고 없을 수도 있다

# 키워드 검색
/키워드 입력 Enter
/class Parser

 

누가 만들었는지 알기위해서는?

1. 첫번째 방법

>>> git reset --hard 7c4b09b24bb~1 # 7c4b09b24bb이전으로 돌아가겠다는 뜻

    여기서 다시 blame 해서 /class parser 검색

    제일 처음나오는 아이디 copy -> git show 

    이걸 반복

 

2. 두번쨰 방법 

    해당 github에 들어가서 해당 파일 열기 

    blame view -> ctrl F

    최초의 commit이 나올때까지 타고 들어가 확인한다

 

3. 세번쨰 방법

    file 이름으로 유추하기 

    node_http_parser -> parcer가 제일 중요한 기능 -> 커밋 초반에서 생성되었을 수도 있다 

    git log --reverse -- src/node_http_parser.cc

>>> git log --reverse -- src/node_http_parser.cc

처음 생성된 커밋 맞음

 

오늘의 회고

• 오늘 아침에는 머리가 리셋된 기분이었다 .. 앞으로 git desktop보다 bash를 사용해서 git 명령어를 까먹지 않도록 해야겠다  
• 오늘 강의내용 외에 커밋 메세지 작성 팁, 깃허브 issue 탭 보는 방법, 사용법 등 협업와 앞으로 개발자로서 github에 대해 알아야할 부분을 짚고 넘어가주셔서 너무 좋았다