[OSS] Git/GitHub 고급 실습

실습준비 : git 설치하기 (git bash)

https://git-scm.com/downloads

Git - Downloads

 

1. Rebase 실습 할 GitHub 저장소 Clone 하기

# Rebase 실습할 GitHub 저장소 소스폴더 다운받기
$ git clone https://github.com/taeung/git-training  

 

-i 옵션을 주면 되감기를 할 수 가 있어요. (interactive : 반응형으로 진행 하겠다.)

 

2. Rebase 를 하여 과거의 commit 이후에 새로운 커밋 끼워넣기

Head 가 가장 최신 로그에요.

#rebase 취소하는 방법
$ git rebase --abort

gitk

3. 끼워넣은 Commit을 1개로 합치기

* reset --soft HEAD~1 설명: : 가장 위에서 ~ 첫번째 꺼 까지

--soft 는 --hard와는 다르게 commit 정보만 삭제하고 파일 변경분은 남겨둔다. (파일 내용은 남김)

git reset --hard HEAD~1 은최신커밋삭제 뿐만아니라파일의 변경분도 완전히 삭제한다. 
(완전히 파일을 날려버림. 커밋도 날리고 파일도 날리고)
날리는 걸 원했던걸 아니니까, rebase --abort로 취소 할 수 있다.

--ammend는 최신 히스토리 기준이죠.

# 실수로 너무 많이 --soft 했을 때는
$ git reflog

c9a53ba (HEAD -> master) HEAD@{0}: commit (amend): Merge pull request #14 from lkeonwoo94/TSW_SPI_IPRDLM03
5e1dfad (origin/master, origin/HEAD) HEAD@{1}: reset: moving to HEAD~4
6cc4d46 HEAD@{2}: rebase -i (finish): returning to refs/heads/master
6cc4d46 HEAD@{3}: rebase -i (start): checkout HEAD~4

이런식으로 이전까지했던 작업들 reflog를 확인해 몇번째 HEAD로 이동할지 확인한다.

 

만약 HEAD@{1}로 이동할꺼라면

git reset --hard HEAD@{1}

 

 ammend 편집

4. 커밋 삭제하기

git reset --hard HEAD ~ 하면 될듯 ..?

 

 

5. 커밋 초기화

git reset --hard origin/master

---

Git Blame 명령 : 소스라인별로 commit ID를 추적(누가 마지막으로 수정 했는지)

• 언제쓸까? 내가 이상하다고 생각했는데, 만든사람의 history를 보고 의도를 파악할 수 있다.

# Node.js 소스폴더(node)에서 node_http_parser.cc 가 있는 해당 경로로 이동하자
$ cd src/;

# blame 을 통해서 Parser 클래스 소스구현 라인중에 최초 commit 을 찾아보자
$ git blame node_http_parser.cc;

# 찾은 commit이 Parser 클래스 최초구현 commit인지 확인
$ git show <commit ID>

# 힌트: 특정 commit 이전 역사로 되돌리기
$ git reset --hard <commit ID>~1

 

• 최초커밋을 찾는 방법 :
  git reset --hard [id]~1 
  물결 1표시로 이전으로 돌릴수 있다. 근데 이렇게 하면 노가다임.
  
  blame 은 line by line 디텍팅이니까. {} 같은 것이 수정 잘 안되어서 엄청 옛날 시간인것으로 최초를 가늠할 수 있음.
• 로그를 --reverse로 보는 것도 방법이죠.
• 역사에서 폴더가 변경되었을 수도 있다. [ 진짜 최초 커밋 실습 ]

git show -q

 

---

< 오픈 소스 협업 개발 과정 - 미시적 관점>

• 기능을 어떻게 사용하는가?
• uf trace 사례. : -pg를 넣으면 mcount로 tracing을 할 수 있다. (후킹)
• Pull-request / Review  과정 예시
• 보내기전에 Contributing . md 를 반드시 보세요. 여기에 코딩 스타일이 다 적혀있습니다.
• 지원이 안됐는데, 지원이 되면 Support
• 개선이 되면 Enhance
• 고쳤다 fix
• before/after : 이전에는 이랬는데, 이 코드를 넣고나면 이렇게 변한다.
• 커밋을 나눠서 할때 기준 ?
• 오픈 소스의 핵심은 리뷰/디스커션 --> 리뷰와 디스커션 단위로 나누어서 커밋 하는게 중요함. 만 라인이 중요한게 아님. 만 라인 올리면 다 읽으란 거잖아. 싸가지 없는거죠. 리뷰하기 좋고, 논의하고 좋고, 테스트의 단위가 되고.

 

이슈/ 디스커션 차이점

이슈 : 코드 수정의 내용이 없음. 이슈글을 올림

---

GitHub 팀계정

https://github.com/organizations/plan

Build software better, together

 

빈 ! 프로젝트 : Readme 들어가면 안돼요.

 

 

---

1. 버그 수정 커밋 메시지

제목은 이렇게 fs ext4: fix B problem
제목은 이렇게 [카테고리prefix] : 수정 내용

내용은 사람들이 이렇게 쓰려해
how : 80%  
why : 
==> 근데 코드 보면 알아

그러니까 내용은 이렇게
how : 20%
why : 80%
왜 했는지에 더 중점을 둔다.

샘플.
e.g.
when ~~~(어떤 상황에서), the B error can occur. (이 에러가 발생할 수 있고)
thre reason is that ~~ (그 이유는 뭐뭐뭐다). So fix it.
이런식으로 대충 적을 수 있는 거에요.

중요한거는 상황에서 발생한거를 구체적으로 적는 것.

근데 이러면 끝이 아니에요.

그래서 여기 적힐 수 있는게 before/after

여기에 logging 정보 적을 수 있어요

Before: 에는 코드가 이렇고

After : 에는 코드가 이래서 에러가 안난다. 굉장히 직관적이죠


근데 여기서 또 끝이 아니에요.
it it related with the [commit_id], [commit_tilte] , [Add b feature]
커밋 아이디, 타이틀.
이거를 왜 이렇게 적었냐면요
어떤 커밋하고 관련있는지, 어떤 side-effect를 몰라서 이런 문제가 생겼고 이렇게 해결 했는지 쓴다.

여기서 끝이 아니에요.

Fixes #91 이러면 이슈 넘버
여기서 누가 리뷰 해주면
reviewd-by : 누구누구누구
supported-by
suggested-by
뭐 이런거.

 

References

https://git-scm.com/book/ko/v2

Git - Book

---

• git merge <<브랜치명>> : master에서 branch 병합할 때
• git merge --abort : 병합 취소 할 때 

---

• git stash : 일부만 반영하고 싶어서, commit 을 한거 안한거로 나누니까, checkout으로 branch를 switch 할 수 가 없었다. 이럴 때 stash 로 다 저장해놓고 사용한다.

 

https://jupiny.com/2019/03/19/revert-commits-in-remote-repository/

원격 저장소에 올라간 커밋 되돌리기

upstream으로 지정한 origin/master 에서 merge 를 잘못 했을때

--> push force로 해결햇엇음 (나혼자 쓰는 레포여서)