터미널 기본 명령어
ls : 폴더 내용을 확인
mv : 파일명 변경 또는 파일 이동
cd : (change directory) 폴더 이동
pwd : (print working directory) 현재 경로 출력
Git/GitHub 공부를 어떻게 하고 있는가?
오픈 소스 프로젝트 pytorch에 개발참여를 한다는 컨셉으로 진행하고 있다.
- 개발환경 구축 (컨테이너)
- fork : 프로젝트 복사
- clone : 소스 다운로드
- 프로젝트 개발 현황 파악/분석 (Reading Skill)
- 소스 수정 ⇒ commit : 히스토리 저장
- 수정내용 제출 ⇒ Pull-Request (PR)
clone ⇒ commit 504개 ⇒ base commits
- 다른 사람들이 이전에 한 commit들은 base commits이 된다
- commit 505번째, 506번째를 만든다 ⇒ 2개 commit 제출
- base commit 위에 commit하여 쌓는 형식
Commit
- commit ID
- commit message : 소스 수정의 이유 작성
- Fix : 잘못된 것을 고친 것
- Improve : 원래는 잘 되던건데 개선한 것
- 예) 10초 → 5초
- Add : 함수, 클래스 추가할 때가 아닌 없는 기능, 없는 옵션을 추가할 때
- Implement : 구현하다
- Support : 윈도우 → 리눅스에서도 가능하게
- ARM ⇒ x86
Commit 메시지 분석 요령
- Add, Implement, Support… : 기능 추가가 되고 있다.
- Fix, Improve, Refactor… : 유지 보수가 되고 있다.
Git 브랜치란?
- “작업의 단위”
- 프로젝트 운영자 vs 프로젝트 참여자
- “참여자 관점”에서 브랜치를 언제 만들까?
- (예: Fix mnist) “작업을 시작할 때”
- 브랜치명을 뭐로 하지? : “fix-mnist-v2”
- “참여자 관점”에서 브랜치를 언제 만들까?
- 프로젝트 운영자 vs 프로젝트 참여자
- 브랜치 효과/기능
- “같은 폴더인데 다른 세상”
Push와 Pull-Request
push : 나의 프로젝트에 commit 업로드 하는 용도
Pull-Request : 팀 프로젝트에 내가 만든 commit 제출
토큰 생성하기 (push 할 때 ID/PW 대신 사용하기 위해)
- github.com/settings/tokens
- Generate new token 버튼 클릭
- 토큰명 적기 (예: test)
- workflow 체크 박스
- (아래 있는) Generate token 버튼 클릭
- 생성된 토큰 복사 : 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
- Username 대신에 토큰 붙여넣기 ⇒ push
- Password는 그냥 Enter 키
- fork 프로젝트 github 사이트 들어가기
- 브랜치 ‘fix-mnist’ 선택하기
- (가운데쯤 있는) Contribute 버튼으로 PR
diff 사용 시나리오
- clone ⇒ 504개 ⇒ base commits
- commit 생성하기 전에 내가 수정한 사항을 체크하고 싶다?
수정 내용 잠시 저장(statsh) 해두기
- 수정 사항 체크는 했는데
- 예) 버그 수정을 했다
- diff → 수정 결과 체크 → before/after
- stash ⇒ 수정한 사항을 잠시 저장
Checkout이 뭐야?
- -b는 브랜치 생성이였는데...
- checkout 뜻 : “히스토리 창고(.git)에서 가져온다”
- 비유 : “도서관 책을 대출 받을 때”
- git checkout -- mnist/main.py
- 히스토리 창고에서 가장 최근의 해당 파일을 가져온다(원상 복구한다)
- git checkout -- ./
- stash : 잠시 저장
- checkout : 덮어써버림
git reset
- git reset : git add 취소
- git reset --hard HEAD~1 : git commit 삭제
Commit -s 옵션
- commit을 만들 때 -s 옵션을 넣으면 Signed-off-by가 메시지에 추가 된다.
- 이유 : 라이센스 서명 절차, CLA 절차
- 전례로 “프로젝트 → 기여 50% → 소송”가 있음
git commit --amend
소스를 수정했다 ⇒ add 준비 ⇒ commit 생성
- 수정사항이 생김
- 새로운 commit을 그냥 위에 올린다.
- 기존의 commit을 수정할 수는 없을까?
- --amend 옵션으로 최신 commit을 수정할 수 있다.
- 중간에 있는 commit은 불가능 (단 다른 명령어와 조합하여 가능은 함)
- --amend 옵션으로 최신 commit을 수정할 수 있다.
- 파일 수정부터 한다.
- git add로 준비 시킨다
- git commit --amend ⇒ 최신 commit에 흡수시킨다.
Window Git
- git bash 설치 ⇒ git 설정
- 오픈소스 프로젝트 commit 추가됨
- 추가된 최신 commit들을 로컬로 가져온다
- git fetch upstream master
- (pull = fetch + merge)
- pull로 해도 가져올 수는 있지만 merge를 하길 원하지 않을 경우
- “upstream/master” 브랜치명이 자동 생성됨
- 현재 Base를 최신으로 갱신한다
- git rebase upstream/master
Rebase에서 충돌이 일어나는 경우
- 같은 파일을 수정했을 경우
병합 : Merge와 Rebase
- merge : commit id가 변경되지 않을 수 있음
- rebase : commit id가 변경됨
commit이 2개가 있었던 과거로 rewind 실습
- git rebase -i --root
- 두번째 commit 위치에 “pick” → “edit” (되감기)
- git log --oneline
- git rebase --continue (풀기)
rebase -i, --interactive 기능을 사용하는 상황
- “내가 만든 commit들을 기준으로 작업하는 경우가 보통이다”
- 예시
- PR ⇒ 12 commits ⇒ 리뷰/토론 ⇒ 수정사항 생김
- “두번째 commit은 지우고, 세번째 커밋은 3개로 나누고 네번째 커밋은 메시지 수정하고 8번째, 9번째 커밋은 하나로 합쳐라”
- PR ⇒ 12 commits ⇒ 리뷰/토론 ⇒ 수정사항 생김
--root와 -i 차이
- --root 는 최초 커밋부터 리베이스하기 위해 붙이는 옵션
- -i 는 rebase를 할 때, interactive 기능을 사용하기 위해 사용하는 옵션
rebase 취소하는 방법
- git rebase --abort
히스토리 전체 원상 복구 하는 방법
- git reset --hard origin/master
reset --hard와 --soft
- hard : 추가된 commit과 파일 제거
- soft : 추가된 commit만 제거되고 파일은 남아있음
blame 기능을 사용하는 이유
- 특정 소스 라인을 수정해야 하는 상황
- 760 라인 ⇒ 문제가 있다고 판단했다 ⇒ 760라인을 만든 commit을 찾아내서 이해한 다음 ⇒ Bug fix commit 생성 ⇒ 제출
- 소스 분석 / 리딩
- Parser 클래스를 파악하고 싶다?
- 클래스를 새롭게 추가해야 하는데 다른 사람들은 어떻게 했을까?
- 클래스, 함수 추가 ⇒ 역추적
오픈 소스 개발 참여 도중 새로운 파일을 추가해야하는 상황
- 다른 사람은 새로운 파일을 추가할 때 어떻게 했을까?
- 역추적
