Day21 - git 특강

오늘 배운 내용

- 구름 IDE

- 협업을 위한 git 사용법

- git 도구 사용하기

구름 IDE 세팅하기

독립된 리눅스 환경을 만드는 법

1. 클라우드 AWS (가상머신)

2. virtual box, vmware (가상머신)

3. 컨테이너 (가상머신 아님! 독립된 리눅스 환경을 제공해주는 형식 | cgroup, / namespace) - 구름 

    ㄴ> IDE 환경을 웹에서 실행할 수 있음 

만들어진 컨테이너 - 여기서 cmd창을 통해 git 이용

도커파일 (KB) = 텍스트파일 -> 용량이 작은 파일로 굉장히 빠르게 컨테이너를 만들 수 있다 

    ㄴ> 리눅스 안에 설치할 것들이 명시되어 있음

 

CLI vs GUI

CLI -> 텍스트 기반 (cmd 기반) , 자동화, 세부적인 기능 활용 / 다수의 파일을 다뤄야 할 때 

GUI - 직관적으로 사용할 수 있는 편리함이 장점 , 자동화 및 세부적인 기능 활용 어려움 / 포토샵, 영상편집 

      - 간편한 버튼 (add, commit, push) 

GUI로 할 수있는 모든것은 CLI로 가능하다 

 

git 협업 개발 참여 과정

1. fork (프로젝트 복사)

2. clone (프로젝트 다운) -> 진행된 경향파악 가능

3. commit (수정 작업)

4. push (작업 내용 업로드 - to fork repo)

5. pull-request (작업내용 제출)

1. fork (프로젝트 복사) & clone (프로젝트 다운) 

fork는 진행되고 있는 팀 프로젝트의 git repo를 나의 개인 git repo로 가져오는 것을 이야기 한다 

이후 fork된 나의 repo를 로컬 pc에 clone 한다

>>> git clone https://github.com/gymin97/pytorch-example.git

이름이 기니까 간단하게 바꿔준다

>>> mv pytorch-example/ examples
>>> cd examples/

위 명령어 실행시 명령 입벽 앞에 (master)가 뜬다면 성공 

-> (master)가 안뜬다면 

>>> git status

입력하고 현재 실행중인 branch 확인

수정한 사람들 순위보기 (github - insights - Contributors)

>>> git shortlog -sn | nl

머지 커밋 빼고 보기

>>> git shortlog -sn --no-merges | nl

merge commit : 병합되었음을 보여주는 커밋 = 깡통 커밋  (소스코드 변경, 변화분 미포함)

 

2020년 이후를 기준으로 랭킹 확인하기

>>> git shortlog -sn --no-merges --after=2019-01-01 -- mnist | nl

특정 폴더/파일에서 커밋 랭킹 확인하기 

>>>git shortlog -sn --no-merges -- mnist | nl
>>> git shortlog -sn --no-merges -- mnist/main.py | nl

 

** 커밋이란 소스코드 수정 단위라고 보면된다 

   - 협업시 커밋 단위로 토론, 릴리즈, 유지보수를 수행하므로 commit message를 신경써서 작성해야 한다

   - 하나의 커밋안에 너무 많은 기능을 수정하거나 너무 작은 단위의 수정을 커밋으로 남기는것도 바람직 하지 않다 

   - 너무 작은 단위의 커밋도 별로지만 너무 클바에는(ex. 10,000 라인 수정) 차라리 작게하는것이 났다

 

커밋 로그 확인

>>> git log --oneline

git 커밋 횟수 세기 - wc 는 'word count'를 의미 옵션 -l 은 라인 숫자를 셈

>>> git log --oneline | wc -l

 

옵션 추가

>>> git log --oneline --no-merges --after=2018-12-31 | wc -l
>>> git log --oneline --no-merges --after=2018-12-31 -- mnist | wc -l
>>> git log --oneline --no-merges --after=2018-12-31 -- mnist

wc 옵션 사용 안하면 쌓인 commit이 출력된다 

 

각 커밋을 한 줄 말고 자세하게 보기

>>> git log -p

커밋 아이디중 하나 확인하기 (커밋마다 고유한 아이디가 있고 수정 내용을 담고있음)

>>> git show 6c8e2ba

각 커밋에서 수정된 내용은 diff --git으로 시작된다 이를 활용하여 수정된 내용만을 뽑아 출력할 수 있다

# 명령어로 확인하기
>>> git show 6c8e2ba | grep "diff --git" 
# 숫자로 확인하기
>>> git show 6c8e2ba | grep "diff --git" | wc -l

예전 커밋부터 보기 (프로젝트 경향 파악 가능 / 이 프로젝트가 언제 시작했는지,, 등)

>>> git log --reverse

실습 퀴즈 - 2020년 6월 한달동안의 수정내역을 확인하는 명령을 입력하고 개수를 출력하세요

>>> git log --oneline  --after=2020-06-01 --before=2020-06-30 | wc -l
>>> git log --oneline  --after=2020-06-01 --before=2020-06-30 --no-merges | wc -l
>>> git log --oneline  --after=2020-06-01 --before=2020-06-30 --no-merges -- mnist | wc -l

wc는 출력라인의 수를 센다 -> 한줄로 커밋을 읽어와야 한다 (onelog) 

merges를 빼고 싶다면 --no-merges 옵션 추가

mnist 폴더의 커밋만 보고싶다면 --mnist 옵션 추가

 

3. commit (수정 작업)

commit은 수정한 소스코드 파일을 git에 올리는 것을 말한다

개인 프로젝트를 진행하며 내 개인 repo를 관리한다면 branch를 따로 만들어 관리할 필요가 없을 수 있지만

 

팀 프로젝트 수행시에는 다음 순서를 따른다 

팀 git -> 나의 repo로 fork -> 나의 local pc로 clone -> 새로운 브런지를 만들어 여기서 수정 작업 -> add / commit

-> 나의 repo로 push -> 팀 repo로 Pull Request

 

branch 생성 

>>> git checkout -b fix-mnist

branch는 기존 브랜치와 별도로 히스토리를 남기고 작업할 수 있다

fix-mnist 에서 hihi를 만들었지만 master에서는 보이지 않는다 

 

브랜치에서 커밋을 안하면 - 관리대상이 아닌 파일이 됨, 브랜치에 속하지 않고 그냥 파일 / 왔다갔다해도 다 보임

-> add, commit 을 해야만 브랜치별로 왔다 갔다함

브랜치 삭제

>>> git branch -D fix-mnist

Branch가 왜 필요할까?

- 원본을 헤치지 않고 수정하고 싶을때 압축 해놓고 복붙해서 사용한다 -> 디스크 낭비 / 폴더 경로 바뀜으로 인한 오류 방지

- master브랜치를 헤치지 않고 보존하면서 따로 브랜치를 만들어 새로운 작업을 할 수 있음 

 

수정한 내용 add, commit 하기 ( 오탈자 수정인 경우 Correct typo 표현 많이 씀)

>>> git add -A or git add mnist/main.py 
>>> git commit -m 'Correct typo in default value within help'

4. git push & 5. pull, pull request 

push - 내가 작업한 것 (commit)을 origin에 올리기 (fork한 내 레포)

origin repo - 내가 fork한 내 git의 repo

upstream repo - 팀 프로젝트 repo

 -> push를 위해 토큰이 필요 (password에 올려야함)

https://github.com/settings/tokens
1. Generate new token

2. Note 토큰 명칭

3. workflow 체크

4. 토큰 생성 (Generate token)

 

내가 수정한 브랜치 확인하고 해당 브런치에서 

>>> git remote -v
>>> git push origin fix-mnist

-> username - 깃허브 이름

-> password - 토큰

 fork한 나의 repo확인하면 fix-mnist가 생겨있음

Pull Request - git의 기능이 아닌 github의 기능이다 -> 따라서 깃허브에서 진행

fix-mnist 브랜치 선택 - Contribute -> 올리기

 

git 도구 사용하기

git stash - 소스코드 수정 후 임시저장할때 

>>> git stash

stash 후 status하면 수정 안한것처럼 보임

취소하고싶으면

>>> git stash pop

수정한 상태가 잘 되는지 안되는지 확실하지 않은 상태에서 임시저장 후 실험할때 사용

 

원상복구하기 

>>> git checkout mnist/main.py

-> mnist/main.py 보면 수정사항 사라짐

 

checkout 과 stash 차이점은?

checkout -> 싹 밀기 (수정전으로)

stash -> 수정한 내용 임시저장해두고 두개 왔다 갔다하며 비교 가능

 

add 명령 취소하기

>>> git add -A 
>>> git reset

commit 삭제하기

>>> git log --oneline -3 # 최근 3개 커밋 확인
>>> git reset --hard HEAD~1

 

commit 에 서명 넣기 ( -s -m or -sm )

>>> git commit -s -m 'add import reqeuts'

 

커밋 자체를 실수한 경우 (커밋을 지우지 않고 수정하고 싶다면)

>>> git add -A
>>> git commit --amend

제일 최근에 commit된 내용을 바꾼다

 

나랑 협업하는 사람이 같이 커밋, Pull Request 한 후 먼저 Merge한다면 -> 내거와 충돌 될 수 있음

rebase 사용하여 나의 repo 최신화 

- 내가 가진 저장소가 old 해서 최신화 하겠다는 뜻

 

rebase하면 충돌이 일어날수있을까?

-> rebase는 로컬에서 일어나는 일이기 때문에 rebase 자체는 충돌 X 

-> but 내가 수정한 파일과 남이 pull한 파일중 겹치는 파일이 있다면 (같은 파일을 서로 수정했다면) 충돌이 날 수 있다

--> 잘 일어나지 않음 / 모듈화가 잘 되어 있어 같은 파일을 건들고 있을 확률이 낮다

 

# 팀프로젝트 깃 연결 (upstream)

>>> git remote add upstream https://github.com/taeung/pytorch-example

>>> git fetch upstream master # upstream 의 가져올 브랜치까지 꼭 입력

-> 내부에 'upstream/master' 자동 생성됨

>>> git rebase upstream/master # 현재 내가 있는 브랜치를 기준으로 rebase작업이 일어남

--> 여기까지 하면 내 로컬에서만 rebase가 된것 

# push  -> 내 레포(origin)에 force push 

>>> git push --force origin fix-mnist

 

오늘의 회고

• 깃에 대해 배우고 실제 팀 프로젝트와 유사하게 실습해볼 수 있어서 좋았다
• repo에 commit할때 Git Desktop을 사용하여 손 쉽게 관리했었는데 각 단계별로 하는일을 잘 알지는 못했다
  • 오늘 특강을 듣고 git 으로 협업을 한다는것의 의미와 각 단계별 실행 내용을 잘 알 수 있어 좋았다