AI Convergence

Git 내부 저장소를 최적화 해주는 작업과 zip/tar로 묶는 방법에 대해 알아보자 

• git gc : 저장소의 크기 압축 및 최적화 (지저분한 내용을 정리)
• git gc --aggressive : 변경 사항 델타(delta)단위로 저장한다. 저장단위를 처음부터 최적화 한다 

• git archive --format=zip --prefix=aa/ HEAD > bb.zip : zip 포멧으로 aa/ 디렉토리 밑으로 모든 파일을 넣어서 HEAD에서 압축 생성하여 bb.zip파일을 만든다 
• git archive --format=tar --prefix=aa/ HEAD | gzip > bb.tar.gz : 상동. 단, gz에 대하여 gzip 압축 추가 함 

* 참조 : Git 선화

git은 브랜치로 코드를 다룬다. 릴리즈 브랜치는 릴리즈할 코드를 분리할 목적에서 사용한다.

• 구현하기로 한 기능 구현이 끝나면 릴리즈할 코드를 분리할 목적으로 브랜치를 생성한다. (완전히 검토된 상태는 아님)
• 최소한의 변경은 발생하며, 버그나 로직 수정에만 집중한다 (기능추가 없음)
• 이름은 RB_ 로 접두어를 붙이면 좋다
• 릴리즈 브랜치는 마지막 테스트까지만 존재한다
• 릴리즈 준비가 끝나면 태그(Tag)를 붙이고 해당 브랜치를 삭제한다 
• 해당 릴리즈의 수정은 태그에서 브랜칭하여 수정 처리한다 

* 참조 : Git 선화

Git의 tag는 코드의 책깔피와 같아서 릴리즈된 코드에 tag를 달아두면 언제나 해당 태그로 이동할 수 있다. 즉, Freezing Code Release 정도로 보면 되겠다. Tag 는 브랜치처럼 다루어 지지만 읽기만 가능하다. 따라서 변경을 하고 태그로 부터 별도 브랜치를 생성하여 진행하면 된다. 

릴리즈 버전에 대하여 코드 freezing 시에 사용하자 

Git은 분산 버전 관리 시스템이므로 원격의 공유 저장소가 있다. Private 하게 원격 저장소를 구축할 수도 있고, 요즘은 GitHub을 SaaS 형태로 사용하면 된다. GitHub에선 Public과 Private이 있는데, Public 은 공짜, Private은 subscription 모델로 월단위로 과금을 한다. 

▶ remote 저장소 주소들 (GitHub기준)

• SSH (Secure Shell) : git@github.com:<아이디>/<프로젝트>.git   (주로 write 권한을 주고자 할 때 사용 - push)
  예) git@github.com:ysyun/jmqtt_client.git
• GIT 프로토콜 :  git://github.com/<아이디>/<프로젝트>.git  (주로 read 권한을 주고자 할 때 사용. 9418포트 사용 - pull)
  예) git://github.com/ysyun/jmqtt_client.git
• HTTP, HTTPS : https://github.com/<아이디>/<프로젝트>.git  (속도 제일 느리지만 방화벽 오픈 필요없음)
  예) https://github.com/ysyun/jmqtt_client.git

▶ remote 저장소에 대한 별칭 관리

• git remote add <별칭> <원격지 주소> : 예) git remote add origin https://github.com/ysyun/jmqtt_client.git
• origin : 원격 저장소를 가르키는 일반적인 별칭으로 사용한다. 
• git remote -v : 별칭한 내역을 볼 수 있다
• git branch -r : 별칭에 대한 remote repository의 branch를 볼 수 있다 
• git remote rm <별칭> : 별칭을 제거한다 

• github의 경우는 머전 github에서 프로젝트의 remote repository를 생성한다
  
• git clone <remote address>를 통하여 local PC의 local repository로 복제를 한다 (위 예제 참조)
• git fetch <remote> <refspec> : 지역 저장소의 원격 브랜치가 갱신됨 (지역 브랜치에 변경사항을 합치진 않음)
• git pull : default origin 원격 저장소에서 현재 브랜치로 merge 함 
• git pull <remote> <refspec> : 원격 장소에서 가져온 소스를 현재 지역 브랜치에 merge 함
• <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.

▶ remote 저장소 Pushing

• git push : default origin 저장소를 & 현재 브랜치를 원격의 같은 브랜치로 푸싱한다 
  
• git push <remote> <branch> :현재 브랜치를 원격의 신규 또는 존재하는 branch로 푸싱한다
• git push <remote> <branch1>:<branch2> : 지역 branch1을 원격의 신규 또는 존해하는 branch2로 푸싱한다 
• git push --dry-run <매개변수>: 푸싱된 변경 사항을 확인
• <remote> : 원격 저장소의 별칭 origin을 입력하면 된다. 별칭이 없다면 전체 주소를 넣어야 한다.

* 참조 : 선화의 Git

Git의 local repository의 commit 히스토리를 보고, 관리하는 방법에 대해서 알아보자. 참조 블로그 내용을 명령어 위주로 정리함.

▶ 리비전 로그와 범위 알아보기 

• git log : 지금까지 수행한 내역이 전부 보인다. 끝낼 땐 :q 차례로 입력한다
• git log <hash id 7자리> : 특정 커밋내역만 출력 (출력 형식 : 커밋명, 작성자, 날짜, 로그메세지)
• git log --since="5 hours" : 5시간 동안 현재까지 (minute 또는 2012-10.01 날짜 형식가능)
• git log --before="5 hours" : 현재부터 5시간을 제외하고 5시간 전의 모든 커밋내역 보기 
• git log 184dfa1..HEAD : 해쉬아이디부터 현재(HEAD)까지 로그 내역 (HEAD 생략가능)
• ^ : 캐럿문자 -1 취급 (12819fe^ = 12819fe와 일치하는 리비전 바로 이전 리비전으로 해석), 여러 캐럿 사용가능 예) 34fa3rt^^ 
• ~N : 커밋명에 N만큼 뺌 (12819fe~1 = 12819fe 바로 이전 리비전을 나타냄)
• git log -1 HEAD^~2 = git log -l HEAD~1^^  같은 의미의 리비전 필터링임

• git diff --stat 1.0 : 릴리스 사이의 통계를 보여줌
• git blame <fileName> : 누구의 책임인지 보여줌 
• git commit -C HEAD -a --amend : 커밋 수정하기 -> 커밋된 것을 다시 스테이징으로 옮겨줄 때 --amend를 사용한다 
• git revert -n HEAD : 기존 커밋을 다시 돌려 놓을때 사용 -> 이전 커밋상태로 돌아감 
• git reset --hard HEAD : 저장소 재설정임. 이전 커밋의 오류를 수정하려는 경우 사용 (--soft는 스테이징으로 옮김, --hard는 저장소와 작업트리에서 커밋을 완전 제거해 버림)
• git rebase : 커밋 순서를 대화형으로 재배치 하는 것이다 (vi식으로 커밋 순서를 재배치 하는 것이다)
• git rebase -i HEAD~3 : vi로 위치조정 -> 저장하면 rebase 작업을 수행한다
• git log --pretty=format="%h %s" HEAD^3 : 변경 내역 확인

git은 branch를 만들어 "테스트할 기능", "새로운 기능", "버그 픽스"등에 대하여 만들고, master에 다시 merge를 할 수 있다. branch를 만들고, merge하는 방법을 알아보자 

▶ Git 제어

• git branch new : 새로운 branch 를 만든다. 아무런 내역이 없다.
• git checkout new : 새로 만든 new 브랜치로 이동한다 
• git checkout -b alternate master : master를 복제하여 브랜치를 만들고 alternate로 checkout 이동한다 
• git branch -m alternate alternative : 브랜치의 명칭을 alternative로 변경한다 (-M 기존 같은 명칭 브랜치 있어도 덮어씀)
• git brranch -d alternative : alternative 브랜치를 삭제한다 (-D 옵션은 강제 삭제)

• Straight Merge (바로 합치기) : 브랜치 변경 이력 전체를 합치는 방법
  
• Squashed Commit (커밋 합치기) : 한 브랜치 이력 압축하여 다른 브랜치의 최신 커밋으로 하나 만드는 방법
• Cherry-picking (선택하여 합치기) : 다른 브랜치의 하나의 커밋을 현재 브랜치에 적용하는 방법

• git checkout -b alternate master
• git add about.html (내용 넣음) -> git commit -m "add about"
• git checkout master 
• git merge alternate : master 브랜치에 alternate 브랜치를 합친다 (즉, about.html 파일이 신규로 합쳐짐)

• git checkout -b contact master
• git add contact.html (주소 내역 추가) -> git commit -m "add contact address"
• contact.html (email 내역 추가) -> git commit -a -m "add contact email" (즉, commit object 두개가 된다)
• git checkout master
• git merge --squash contact : contact의 커밋 두개를 하나로 만들어 master의 staging에 추가함 (git status 확인)
• git commit -m "add contact address" -m "add contact email"  (master 브랜치에 contact.html 을 커밋한다)

• git checkout contact
• git commit -a -m "add contact sns id" (contact.html안에 twitter 계정추가 commit object Hash 코드를 34abcd 로 가정함)
• git checkout master
• git cherry-pick 34abcd  ( contact 브랜치의 34abcd 커밋을 master 브랜치에 커밋한다)
• git reset --hard HEAD 마지막 커밋을 master 브랜치에서 제거
• git cherry-pick -n 34abcd ( -n 옵션 사용하면 master 브랜치의 staging에 넣음, 커밋안함. git status 로 확인)
• git commit (최종 커밋함)

• git checkout -b about master : about 브랜치 생성 후 checkout
  
• git add about.html (about 내역 입력) -> git commit -m "add about"
• git branch about2 abut : about 브랜치를 기반하여 about2 브랜치를 생성
• git commit -a -m "add XXX" : about 브랜치의 about.html 파일에 XXX 입력
• git checkout about2 
• git commit -a -m "add YYY" : about2 브랜치의 about.html 파일에 YYY 입력 (이제 about 브랜치의 about.html과 about2 브랜치의 about.html 파일에 XXX 와 YYY 충돌이 발생함)
• git checkout about
• git merge about2 : about2 브랜치를 about 브랜치로 바로 합치기
• about.html 안에 conflict 내역이 표시됨 : 내역을 직접 수정하거나, git mergetool 명령으로 merge.tool 값 확인하고 도구로 합치기 시도함 (도구 사용법은 다시 상세히 봐야겠음)

Git의 로컬 Repository에 저장된 commit 내역에서 이전 commit 내역으로 이동하고 싶을 경우. HEAD를 조작함으로써 가능하다. 

• 지금 까지 커밋 내역 보기 : git reflog  (하기 내역으로 파란색으로 3 번의 commit 이 존재한다)

• c6d5478 commit 내역에서 aa64af1 commit 내역으로 이동하기 : git reset --soft HEAD~  (staging, working 영향없음)
• --mixed 는 staging을 local repository와 같게 만든다. 즉, staging에 HEAD정보를 복사하여 영향줌. working 영향없음 
• --hard 는 staging, working 둘다 영향을 줌

• aa64af1 commit 으로 이동했을 때 상태 정보를 확인 : git status  (c6d5478 commit 되기전 rename 명령을 내렸었음)

• Git 에서 HEAD, Branch는 Pointer이다 

commit을 하여 Blob format으로 되어 있는 binary 파일에 대한 명칭은 SHA-1 해쉬알고리즘으로 해쉬명을 가지고 있다. 파일명과 해쉬명을 오가면 확인하는 방법을 알아보자 

• 파일명 통하여 해쉬명 알아내기 : git hash-object <fileName>

• 해쉬명 앞 6자리를 통하여 변경 내역이 무엇인지 파악하기 : git cat-file -p <해쉬명 앞 6자리>

• 전체 해쉬에 대한 파일명 맵핑 목록 보기 : git ls-files -s  ( .git/index 파일 내역을 참조함 )

▶ Git의 4가지 객체

> Blob Object

• Header + Content 
• zlib으로 압축되어 있음
• .git/objects/ 아래 있음 

• blob + 다른 tree 객체
• 폴더와 같은 개념
• .git/objects/ 아래 있음 

• blobs + trees + author + date + message
• .git/objects/ 아래 있음

• pointer to commit object
• .git/refs/tags/ 아래 있음 

* 참고 : 개발자를 위한 고급 Git 활용 (p50부터)