[2022 OSSCA] Git / GitHub 특강

 

오늘 아카데미에서 git / github 특강이 있었다.

 

 평소 페어로 과제를 진행할 때 git을 이용하고 있었고, 개인적으로 알고리즘 문제를 풀고서도 github에 항상 commit을 남겼기 때문에 기본적인 사용법은 익숙했다.

 

 하지만 오늘 특강은 오픈소스 아카데미 특성에 맞게 오픈소스 개발에 직접 참여할 때 필요한 기능들을 위주로 진행됐다. 오전 9시부터 오후 1시까지는 기본 실습을, 오후 2시부터 오후 5시까지 고급 실습, 오후 6시까지는 3~4명이 팀이 되어 팀별 실습이 진행됐다. 실시간 온라인으로 진행됐지만 조교님들이 상주하셔서 필요할 때마다 바로 도움을 받을 수 있었고 질문도 바로 할 수 있어서 학습하기 굉장히 편한 환경이었다. 또한 강사님이 오픈소스 개발 경험이 많으셔서 본인이 직접 겪은 상황을 토대로 어떤 식으로 해결하면 되는지가 강의에 녹아있어서 생생함과 유익함이 강의 내내 느껴졌다. 긴 시간 진행됐지만 팀 실습에서 시간이 부족해 더 많은 내용을 실습하지 못해서 조금 아쉬웠다. 

 

 현재까지는 git / github을 나의 history를 남기는 용도로만 주로 사용했다(add / commit / push). 실제로 오픈소스의 가장 중요한 본질은 "협업"이기 때문에, 협업을 하면서 일어나는 다양한 상황을 해결할 수 있는 기능들을 배울 수 있어서 좋았다. 특히 rebase와 관련된 내용이 아주 인상 깊었다. branch와 관련된 내용도 듣기만 하다 직접 실습해볼 수 있어서 좋았다.

 본격적으로 Zeppelin 프로젝트를 컨트리뷰트할 때에도 굉장히 도움이 많이 될 것 같다. 또한 부트캠프에서 곧 프로젝트를 진행할 텐데 오늘 배웠던 내용을 활용하면 팀원들과 더 효율적으로 같이 작업할 수 있을 것 같다. 결론적으로 굉장히 유익한 시간이었다. 발대식 때에도 이 git / github 강의가 예전부터 호평이 많았다고 들었는데 이유를 알겠다 

 

 

아래는 강의 내용을 간략하게만 기록한 내용이다. 

 

---

 

오픈소스 개발에 참여한다는 컨셉

1. fork

 

2. clone -> .git 폴더(히스토리 창고)도 같이 다운 

depth를 1로 해서 최신 히스토리만 받을 수도 있다. (optional)

 

3. 프로젝트 개발 경향을 해석 (History 분석, 통계)

 

"이 소스파일은 누가 많이 개발?"

"프로젝트는 몇 번 commit이 이뤄졌나요?"

"이 소스파일은 최근 몇 번 수정되었나?" 

 

이런 정보를 혼자서 알아낼 수 있어야 자연스럽게 프로젝트에 녹아들 수 있다.

 

4. 테스트, 실행 -> 개발자가 되기 이전에 슈퍼 유저가 되는 것이 중요하다. (코드부터 보는 것은 잘못되었다.)

 

5. 소스 수정 -> 수정 이력 저장 : add / commit

 

6. 수정 이력 commit을 fork한 저장소에 업로드 : push

 

7. pull request를 통해 참여하는 프로젝트에 수정 이력 commit 제출

 

 

예전 commit log 순으로 보기

git log --reverse

 

전체 수정 횟수

git log --oneline | wc -l

 

사람별 수정 횟수

git shortlog -sn | nl

 

특정폴더(mnist) 일정기간 이후 수정 횟수

git shortlog --after=2018-01-01 -sn -- mnist | nl

 

한 가지 commit 내역 확인하기

git show commit고유ID

 

goormIDE 컨테이너 사용하면 좋다. 대부분의 오픈소스들은 도커 파일로 개발환경 세팅을 편하게 구축한다.

 

 

굳이 GIt을 명령어로?

GUI

사용자 친화적, 편하다

협업 문제를 해결하기 어렵다

 

CLI

세부적인 기능을 사용할 수 있다. 따라서 문제를 해결하기에 좋다.

자동화하기 좋다! (스크립트 사용)

 

 

기본 명령어

ls

cd

pwd

mv : 파일명 변경(또는 파일경로 이동)

touch : 빈 파일 만들기

 

 

오픈소스 프로젝트를 파악하는 요령

 

1. 인기도, 소프트웨어 가치 -> star 개수 : 좋아요 갯수

but 인기있는 free software일 수 있다.

 

2. 협업, 활성화 정도 -> commit 개수, contributor 인원 수 등등

오픈소스 프로젝트의 본질 : "협업, 리뷰, 토론"

 

commit message의 중요성!

fix, improve, add, support, refactor, remove

 

명령어 옵션

- : 한글자 옵션

-- : long 옵션

ex) -f, -force

 

git push할 때 필요한 토큰 생성하기

1. github.com/setting/tokens

2. generate new token

3. token 이름 생성

4. workflow 체크

5. 토큰 생성-> 복사 -> push 할때 사용

 

 

Pull-Request 하기

1. fork한 프로젝트 깃헙 접속

2. branch를 fix-mnist로 변경

3. contribute 버튼

4. open pull request 버튼

5. create pull request 버튼

 

 

Branch를 굳이 왜 사용할까?

"원본을 해치지 않으면서 새로운 작업을 편하게 하고 싶다."

같은 폴더/파일을 다른 세상에서 사용!

 

1. 원본을 유지하기 위해서

2. 압축파일을 따로 저장 안해도 된다.

3. 다른 폴더로 복사해서 작업 안해도 된다.

 

.git 숨김폴더 : 히스토리 창고

압축을 풀었다가 압축했다 왔다갔다 하면서 branch 기능을 사용

 

checkout 명령어 사용

 

브랜치의 명칭은 어떻게 할까?

'내가 작업하려고 하는 내용의 요약 단어로'

 

브랜치 운영 방법 -> git flow : 관리자 입장

 

프로젝트 관리자 vs 프로젝트 참여자 입장을 구분해서 운영

 

프로젝트 내에 CONTRIBUTING.md 파일에 협업 규칙이 적혀있다.

 

 

"fix-README" 이름으로 branch 생성

git checkout -b fix-README

 

 

 

Rebase

내가 작업하는 사이에 base commits가 바뀌기 때문에 base를 갱신해야 한다 : rebase

(git rebase 명령어를 활용하는 것은 또 다른 문제! 다양한 명령어로 rebase를 수행할 수 있다)

 

git rebase 명령어 != Rebase

 

1. 팀 프로젝트 url 등록

git remote add upstream "오픈소스 프로젝트 url"

 

2. 최신 히스토리를 가져온다 -> 내부 브랜치 자동 생성 (upstream/master)

git fetch upstream master

(rebase 명령어와 관련x)

fetch : 베이스 변경사항을 가져온다

 

3. rebase

git rebase upstream/master

 

총 3단계로 이뤄진다.

 

1단계) rewind : 되감기

 

즉, 내가 추가한 commit을 되감는다.

과거 시점으로 되감는 것이다.

 

되감기만을 위한 명령어

git rebase -i, --interactive HEAD~3

 

커밋 박스를 break point를 줘서 감았다가 풀기 가능

예) 12개의 커밋이 있는데 2개만 있던 상황으로 돌아간다.

 

되감은 것을 풀 수도 있다. 다시 현재 시점으로 rebase를 푼다.

git rebase --continue

 

history 처음 상태로

git reset --hard origin/master

 

 

git rebase 취소

git rebase --abort

 

 

 

2단계) rebase

 

즉, base를 갱신한다.

다른 사람이 날린 pr이 merge가 된 내용을 나의 base 위에 올린다.

 

 

3단계) commit 추가

 

즉, 내가 추가했던 commit을 새로운 base 위에 올린다.

 

 

4. 강제로 fork한 프로젝트를 갱신

git push --force origin fix-README

 fork한 내 repository니까 force push해도 괜찮다. force push를 하면 내가 보낸 PR도 자동 갱신이 된다.

 

 

 

origin : fork 해서 만든 프로젝트 url

upstream : opensource 프로젝트 url

 

 

pull = fetch + merge

 

 

Stash

 

소스수정 -> git stash : add commit을 하기 전에 임시저장

git diff나 git status에 나타나지 않음

 

git stash pop : 임시저장한 것을 다시 불러옴

 

stash는 개발할 때 언제 쓰일까?

ex) 버그 수정 후 before / after 테스트 점검

 

stash -> 임시저장 -> 수정 전으로 변경 -> before테스트 가능

-> stash pop => 수정 후로 변경 -> after 테스트 가능

 

* git checkout -- 변경파일 : 결과적으론 수정 전 상태로 돌아가는 것은 같지만 임시 저장을 하지 않는다.

 

 

 

checkout 명령어

.git 히스토리 창고에서 히스토리를 꺼내오는 명령어

 

따라서 branch 이동이나 추적 중인 파일의 변경 사항을 되돌릴 때 쓰이는 명령어다.

 

 

 

commit

수정(amend)

 

가장 최신 commit을 수정한다.

 

github에 있는 commit도 수정할 수 있나요? yes

 

1. 일단 local에서 commit을 수정(amend)하고

2. 그 다음에 github 히스토리를 강제로 바꿔버린다. force push

 

 

-s 옵션

 

commit message에 Signed-off-by: username <email> 추가된다.

 

author 정보가 있는데 왜 -s를 추가할까?

 

'라이센스 동의에 대한 서명 절차'를 의미한다.

 

만일 본인 오픈소스 프로젝트에서 CLA(contributor license agreement)를 받았으면 -s 옵션을 붙일 필요가 없다.