[OSS] Git/GitHub 고급 실습

2020. 7. 18. 18:09Git

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

https://git-scm.com/downloads

 

Git - Downloads

Downloads Mac OS X Windows Linux/Unix Older releases are available and the Git source repository is on GitHub. GUI Clients Git comes with built-in GUI tools (git-gui, gitk), but there are several third-party tools for users looking for a platform-specific

git-scm.com

 

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는 최신 히스토리 기준이죠.

 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

GitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects.

github.com

 

빈 ! 프로젝트 : 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-scm.com

 

'Git' 카테고리의 다른 글

[OSS] Git/GitHub 고급 실습  (0) 2020.07.18
[OSS] Git/GitHub 기본  (0) 2020.07.18