Slow but steady wins the race

-Open UP에서 공개SW 실습교육 2일차-

1. Fork 저장소와 오픈소스 GitHub 저장소 설정

**upstream으로 등록 <팀프로젝트 깃허브 저장소>**

git remote add upstream (오픈소스 github 프로젝트 URL)

upstream을 fork한 저장소의 url을 넣지 않도로 주의*

현재 등록된 저장소 확인

git remote -v

2. Rebase가 필요한 상황

팀프로젝트 498commits (를 가져온 내용) => base commits 

base commits위에 다른 499,500번째 commit을 만들어내고, 이 달라진 부분을 제출할 수 있음

Q. base는 항상 똑같은가?

A. No. 팀프로젝트가 혼자 하는 것이 아니기 때문에, 계속 바뀌게 된다. 

Rebase란?

- base를 교체하는 방식

<git rebase vs merge>

기능에 집착하면 이 둘의 차이를 이해하기 어렵다.. 

"rebase이 왜 필요한지", "협업 과정"에 중점을 두고 이해할 것

혼자 local branch 상에서 rebase는 잘 쓰지 않음(거의 없음)

아래와 같은 사고 과정을 통해 이해해보면,, 

같은 파일 내에서 다른 사람 것이 먼저 Merge가 되는 경우, 다른 사람의 commit 과 나의 commit이 충돌이 될 수 있음!

Q. 왜 충돌이 발생할까?

A. 같은 file을 건드렸기 때문에

Q. 충돌이 발생하지 않는다면, 왜 발생하지 않을까?

A. 다른 File을 건드려서 

Q. 충돌이 발생할 확률이 높을까?

A. 발생할 확률이 낮음. 같이 협업을 하기 위해 폴더나 파일을 잘 나눈다는 등, 이미 설계가 잘 되어 있음. (이미 설계적으로 방지가 되어있음) 하나의 파일을 몇천명의 사람들이 수정해서  충돌이 발생하는 경우는 rebase의 할아버지가 나타나도 해결할수없음ㅋㅋ 잘 된 분업화, 모듈화, 등등 잘 쪼개놨기 때문에 충돌이 발생할 확률이 낮음

Q. 충돌이 발생하는 상황

A. Rebase 요청 -> 최신 역사로 베이스를 업데이트 

<Rebase를 수행하는 과정> 

fetch는 upstream에 있는 최신 commit들을 가져오는 것! 같이 협업하기 때문에, 다른 사람들의 작업을 가져오는 것은 항상 있는 일

즉, fetch는 rebase와 관련 X, 단순히 가져오는 역할!

1. pull = fetch +merge

(.git 폴더 히스토리 창고에다 넣어둔다)

2. git fetch upstream master 

(내부 브랜치가 자동 생성됨 -> "upstream/master" ) 

3. git rebase upstream/master

Q. 이 명령어에서 문제가 생길 수 있을까?

A. "File이 같은지"가 중요!! 아래 빨간색과 보라색이 파일이 같을 경우, 충돌이 발생함

** base가 바뀌는 부분과 commit간의 충돌이 나는 부분을 구분해야함! 

4. git push origin (branch 명) --f

Fork 부분을 갱신하는 작업

-f : force 옵션

force는 쓰지 말라는데, 왜 쓰면 안 되는 지가 중요!

공식 오픈소스 프로젝트에서는 base를 갱신한다던지, 중간 commit을 빼버린다던지, 등등 문제가 발생할 수 있기 때문에 "Force Push"를 잘 사용하지 않음

하지만, Fork한 프로젝트에서는 "Force Push" 사용 가능, Force Push는 달라진 점만 push하기 때문에 자주 사용

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2, commit 3)

이렇게 commit이 새롭게 추가된 경우에는 push가 가능하지만,,

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2-1, commit 3)

이렇게 중간에 commit이 수정된 경우에는 force push가 필요함!

※ Stash vs Checkout

★ Stash 

- 수정내용 임시 저장, 복구 가능

- keeping 느낌

- 버그 수정 (before/after 비교 가능) 

★ Checkout 

- git checkout -- 파일명

파일 원상 복구(수정 내용 완전히 날림)

- git checkout -- 브랜치명"

도서관(.git 히스토리 창고)에서 책을 대출받다" 이런 느낌 

<Stash : 수정 내용 임시 저장>

1. git diff(수정내용 확인)

2. 임시저장

git stash

3. 임시저장 복구

git stash pop

<Checkout : 수정 파일 복구하기>

1. git diff (수정 내용 확인)

2. 수정 전 상태로 복구

git checkout -- (파일이름)

- 완전히 원상복구

<Branch란?>

" 같은 폴더 다른 세상" 

- branch에서 뭘하든 master에는 적용이 되지 않음

- 분할된 작업을 진행할 수 있음! 

- 즉, Git을 쓰는 이유가 됨

1. Branch 생성

git checkout -b (branch 이름)
# git checkout -b fix-mnist

- 작업의 명칭으로 branch 생성해주는 것이 좋음

2. 폴더 생성 및 수정작업

hello.txt를 만들고 commit 해보면.. 

3. 브랜치를 master branch로 변경하고 확인해보면

- hello.txt는 없는 것을 확인할 수 있음

4. 브랜치 삭제 

- master 브랜치에서 진행

git branch -D fix-mnist

< Branch에서 소스파일 수정하고 확인하기 >

1. 브랜치 생성

2. 수정할 파일 확인 

3. 원하는 편집기(vim, emacs, nano, 등으로 파일 수정하기

- nano로 실습

nano mnist/main.py

- 수정

- mac에서 nano 편집기 사용법

(1) 저장하기 : control + o

(2) 나가기 : control + x

4. 소스 파일 수정한 내용 확인하기 

git diff

5. commit 할 준비

(1) git status 명령어를 통해 "not staged" 확인

(2) git add 명령어 실행 

git add mnist/main.py

(참고) add 취소

git reset

6. commit하기 

git commit -m "수정한 내용"

7. git show 명령어를 통해 commit이 잘 되었는지 확인 

8. git status 명령어를 통해 현재 소스파일 상태 확인하기

- "nothing to commit, working tree clean" 확인

    == 현재 변화분도 없고 commit할 것이 없음 

(참고) 서명과 함께 commit

git commit -sm "커밋 메시지"

- "-s"를 함께 넣어 명령 실행

- git show를 실행하면 아래와 같이 "Signed-off-by :~~"가 표시됨

- Why 사용?  license에 관련하여 인식하였음을 표시

- 실제로는 "Contributor License Agreements" 많이 사용 

   (https://opensource.google/documentation/reference/cla) (https://cla.developers.google.com/clas) 

(참고) commit 수정하기

- 가장 최신 commit만 수정 가능

- 변경분을 추가하지않고 메시지만 추가할 수 있고, 수정하는 순간 commit ID 도 변경됨

git commit --amend

(참고) commit 삭제하기

- 최상위 commit부터 지울 수 있음(중간 X) 

# 생성한 commit 정보 확인하기
$ git log --oneline -3

# 최상위 commit부터 첫번째(1) 내용 삭제하기
$ git reset --hard HEAD~1

< Pull-Requset 하는 과정>

1. git branch 명령어를 통해 branch 확인하기

2. Fork 저장소에 업로드에서 commit 제출(pull-request) 준비하기 (push 하기)

git push origin (branch명)

token 만들어서 username, password 에 토큰 붙여넣기

3. Fork저장소(Github)에서 commit 제출하기

- 해당 branch에서 "Open pull request" 누르기

--> 현재까지의 과정은 아래와 같다

< 개발자 별 commit 순위 확인 >

git shortlog -sn | nl

- s 옵션 : 개발자별 commit 개수 요약

- n 옵션 : 개발자별 commit 개수 순위 정리 

- nl 명령 : line number 명시 (순위 표시 용으로 사용) 

- 해당 부분은 gui 로 확인 가능 ( Github 해당 프로젝트 -> Insights -> Contributors) 

Q. 왜 GUI로 보지않고 CLI 로 보는가? 

A. 전체의 history보다 최근의 history,  특정 폴더에 집중적으로, 등등 확인하기 위해 

이렇게 세부적인 사항은 GUI로 확인할 수 없음 

즉, 세부적인 경향 파악을 위해 GUI가 아닌 CLI를 사용

(1) 특정 폴더에 집중적으로 순위 확인 

git shortlog -sn -- (디렉토리명)

(2) 특정 폴더 + 특정날짜 이후(최근) 순위 확인 

git shortlog -sn --after=2019-01-01 -- mnist

(3) merge commit 제거한 순위 확인

git shortlog -sn --no-merges

* commit : 소스 변경 히스토리 단위

* merge commit : "병합이 되었음을 나타내는 빈 commit" 

< 전체 소스파일 수정내역 개수 (commit 개수) 확인 >

git log --oneline | wc -l

- wc -l 명령 : (파일) 라인 수 개수 측정

- GUI로도 확인 가능 -> "숫자"commits

- 팀 프로젝트의 commit 전체 개수 == base commit이라고 부름 

Q. base commit 은 계속 똑같은가? 

A. No. 당연히 변경됨. **우리는 base commit 위에 작업을 함**

(1) 전체 소스파일 수정내역 리스트 확인

git log --oneline

- 실행시 나오는 노란색글씨 : 소스파일 수정내역 고유한 ID (SHA1 해시값)

(2)전체 소스파일 수정내역(commit) 자세히 확인

git log -p

(3) 특정 날짜 기준 수정내역(commit) 확인 

git log --oneline --after=2020-01-01 --before=2020-06-30

(4) 특정 날짜 기준 수정내역(commit) 개수 확인

git log --oneline --after=2020-06-01 --before=2020-06-30 | wc

(5) 특정 날짜+파일/폴더 기준 수정내역(commit) 개수 확인

git log --oneline --after=2020-06-01 --before=2020-06-30 -- mnist/

- 협업 시 특정파일에 집중해서 개발하므로, 필요! 

(6) 최근이 아닌 옛날 것부터 소스파일 수정내역(commit) 확인

git log --oneline --reverse

* reverse 사용 시 주의 

- 첫번째꺼는 옛날꺼부터 3개

- 두번째 명령은 최신꺼 3개 중 거꾸로! 

< 특정 ID의 소스파일 수정 내역(commit) 내용 확인 >

git show (ID)

- commit 단위로 어떤 것을 수정했는지 확인할 수 있음

(1) 특정 ID의 소스파일 수정 파일 확인

git show 6c8e2ba | grep "diff --git"

(2) 특정 ID의 소스파일 수정 파일 개수 확인

git show 6c8e2ba | grep "diff --git" | wc -l

(3)전체 소스파일 수정내역(commit) 리스트에서, Merge commit 수정내역 확인

-Open UP에서 공개SW 실습교육 1일차-

<협업과정>

1. 참여할 프로젝트 Fork 복사

2. Fork한 프로젝트를 다운로드(Clone)

3. 프로젝트 분석(개발 경향 파악) : https://bskwak.tistory.com/243 참고 

4. config 설정 (저자(author) 정보) 

<5~7 branch 에서 작업 -> https://bskwak.tistory.com/244 참고>

5. commit 설정( 소스코드 수정분)

6. Fork한 프로젝트에 commit 업로드 ( == Push) 

7. 참여할 프로젝트에 commit 제출 ( == Pull-Request : PR) 

※ Commit 이란?

1. log message(수정한 이유) 

- ⭐️협업 시 중요⭐️

2. patch/ diff (코드 수정: 변화분) 

- ⭐️+(초록)/-(빨강) 코드를 볼 줄 알아야 함

※ Fork

- 공식 오픈소스 프로젝트의 내용들을 복사하는 것 (Github 안에서)

※ Clone

- history와 함께 소스코드를 다운받는 것 

- zip 다운과는 다름! (zip : commit history은 다운 X)

< CLI(명령어 기반 인터페이스) vs GUI(그래픽 유저 인터페이스) >

※ CLI 

- 사진파일 1만개를 폴더 분류할 때 유리 (쉽게 말해, 드래그 하는 것보다 명령어를 사용하는 것이 편리) 

- 장점 : 세부기능 활용, 자동화(스크립트) 

※ GUI 

- 포토샵, 영상편집, 등에 유리

- 장점 : 쓰기 좋음 

- 단점 : 세부기능 활용, 자동화가 어려움

< 기본 명령어>

★ pwd

- print working directory

- 현재 디렉토리 출력

★ ls

- 현재 디렉토리 내부내용(내부에 존재하는 파일들) 출력

★ cd

- change directory

- 현재 폴더 경로 변경 

- cd .. : 상위 디렉토리로 이동 

★ mv

- 파일명/디렉토리명 변경 or 파일  경로 이동

★ rm

- rm 파일명 :파일 삭제

- rm -r 디렉토리명 : 디렉토리 삭제

★ touch

- 빈 파일 생성

★ clear

- 터미널 화면 정리

"command not found" 에러는 오타!

** 협업 프로세스 ** 

1,2 과정

master 표시 : git으로 관리되는 폴더이다! 라는 의미 

"No such file or directory"  에러 

- 해당 파일/폴더가 없는 경우에 발생 

- 이미 그 폴더에 들어와 있는 경우에도 발생

1. pwd 를 통해 어느 폴더에 있는지 확인 -> 이미 그 폴더인지 확인가능

2. ls 를 통해 현재 폴더 안에 무엇이 있는지 확인 -> 이동할지, 등등 결정 

* config 설정

git config -l

- config 설치 확인

* upstream vs origin

upstream : 공식 오픈소스에 push

origin : fork한 프로젝트/본인 프로젝트에 push

1.설치

brew install mysql

버전 확인 

mysql -V

2. 서버 켜기 

mysql.server start

3. 초기설정 

mysql_secure_installation

3. 실행

mysql - u root -p

4. 종료

mysql.server stop

TinyML이란?

- Tiny Machine Learning

- 평균 1 milliwatt 이하의 저에너지 시스템에서 구현되어 임베디드 장치에서 실행하는 머신러닝

- 가격이 착함..ㅎㅎ

Software for TinyML?

- Tensorflow : 머신러닝을 위한 오픈소스 플랫폼

- Tensorflow lite : 기기 내 추론을 위한 오픈소스 딥 러닝 프레임워크(Deep learning framework for on-device inference)

작동방식                    

1. 모델 선택

- 새로운 모델을 선택하거나 재학습시킬 모델 선택

- Python Tensorflow Using colab

2. 모델 변환

- TensorFlow 모델을 압축된 플랫 버퍼로 변환

- Tesorflow lite converter : convert to C array

3. 기기에 배포

- 압축된 .tflite 파일을 가져와서 모바일 또는 임베디드 기기에 로드

- c++ library

4. 최적화

- 32비트 부동 소수점을 좀 더 효율적인 8비트 정수로 변환하여 양자화하거나 GPU에서 실행

Hardware for TinyML

- Arduino nano 33 BLE Sense : no "Person detection(Face detection)"

- ESP-EYE : no "Gesture recognition"

참고: www.tensorflow.org/lite?hl=ko

Notepad++ console창에 "iverilog -o functions functions.v functions_tb.v" 를 실행시켰는데, 

"No such file or directory No top level modules, and no -s option"라는 에러가 발생하였다. 

path설정도 잘 했고, file을 만들어 저장까지 완료하였는데 해당 에러가 발생한다??

workspace가 다른곳에 설정되어있기 때문이다.

(해결방안)

workspace를 해당 파일이 있는 폴더로 설정해 주거나, 파일들을 notepad++폴더에 넣어주어야한다.

<성공~>