티스토리 뷰

TIL(Today I Learn)

Git 기본기 다지기

MinsoftK 2021. 10. 1. 17:58

728x90

Git

git flow를 사용하기 위해, git을 다시 공부하고 있다. 멘토님의 교육을 받으면서 git을 편하게 사용하던 나의 습관들이 안 좋다는 것도 알게 됐다. 그중 하나인 git add . , 이나 git commit -m "" 같은 명령어들을 자주 썼는데, 이는 내가 Commit Convention 대해 생각하지 못하게 만들었다. 따라서 git bash를 사용하면서 올바른 습관을 만드는데 노력하고 있다.

웹 개발을 하면서 node_modules를 add 해버리는 경우도 경험을 해봐서 더욱더 안 좋은 습관이라는 말이 와닿았다. 나름 commit 메시지에 신경 쓰면서 개발하고 있다 생각했는데 나만 알아볼 수 있다는 것을 몰랐다. 다시 한번 다른 사람들도 알아볼 수 있게 만드는 것이 중요하다는 것을 깨달았다.

.git으로 버전 컨트롤을 하면서 파일 이동이나 디렉터리 이름을 바꿔서, 연속성이 끊기는 부분을 간과했다. 그렇게 되면 나의 이전 commit들이 전부 의미가 없어져버리기 때문에 history을 위해 git에게 알려줘야 하는 것도 배웠다.

1. Shell command

ls : 파일의 디렉터리 보여주는 커맨드
- -l : 파일 라인으로 보여주세요
- -a : 숨긴 파일까지 보여주세요 ( .을 붙이면 숨김 파일이 된다.)
cd : 디렉토리 이동

2. vim Command

h j k l - left, down, up, right
i - insert mode
v - visual mode
ESC - back to normal mode
d - delete
dd - delete a line
y - yank
yy - yank a line
p - paste
u - undo
a - append
A - append from end of line
o - open line(under)
O - open line(upper)
H - move to the top of the screen
L - move to the bottom of the screen

문장의 끝 : shift + a

문장의 맨 앞 : 숫자 0

한 문장이 끝난 다음에 삽입하는 명령어 : 소문자 o

그 전 문장에 삽입하는 명령어 : Shift + o

수행했던 것 취소 (undo): u

취소했던 내용 복구 (redo) : ctrl + r

라인 줄 설명 : set nu

3. repo 생성

최근에 master에서 main으로 브랜치 바뀌어 브랜치 이름을 main으로 바꿔줘야 한다.

$ git init
$ git add README.md
$ git branch -M main
$ git commit -m "initial commit"
$ git remote add origin (원격 Repo 주소)
$ git push -u origin main
// 첫 push에 upstream을 써서 같은 저장소라는 것을 알려줘야 한다.

clone 하는 방식도 있다. git clone {클론 할 Repo 주소}

4. gitignore

https://www.toptal.com/developers/gitignore
windows, macOS, visual Studio Code 등등 추가해서 프로젝트에 넣어주자.

5. Commit Convention

커밋 제목은 50자 이내로 요약하여 작성한다
제목과 내용 사이 한 칸
prefix를 사용하여 한눈에 커밋의 용도를 알기 쉽게 한다

feat: features
docs: documentations
conf: configurations
test: test
fix: bug-fix
refactor: refactoring
ci: Continuous Integration
build: Build
perf: Performance

절대 git add . 을 사용하지 마라. status 확인 후, add 하기
적절한 커미테이션을 사용하자.

Commit Convention - example

feat: Create server.py to start flask project
docs: Create README.md
conf: poetry init
test: User model CRUD test complete

ref: https://www.conventionalcommits.org/ko/v1.0.0/

commit의 제목은 commit을 설명하는 하나의 구나 절로 완성
importanceofcapitalize Importance of Capitalize
prefix 꼭 달기
- feat: 기능 개발 관련
- fix: 오류 개선 혹은 버그 패치
- docs: 문서화 작업
- test: test 관련
- conf: 환경설정 관련
- build: 빌드 관련
- ci: Continuous Integration 관련

5.1 commit 할 때 기억해야 할 것

commit은 동작 가능한 최소 단위로 자주 할 것.
해당 작업 단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 함.
모두가 이해할 수 있는 log를 작성할 것.
Open Source Contribution시 영어가 강제되지만, 그렇지 않을 경우 팀 내 사용 언어를 따라 쓸 것.
제목은 축약하여 쓰되(50자 이내), 내용은 문장형으로 작성하여 추가 설명할 것.
제목과 내용은 한 줄 띄워 분리할 것.
내용은 이 commit의 구성과 의도를 충실히 작성할 것.

6. hexo 정적 블로그 만들기

티스토리를 사용하고 있는데 가끔 git과 blog가 따로 관리하려니 굉장히 힘들 때가 많았다. hexo로 github에 페이지를 만들게 되면 잔디심기도 가능하며, 관리하기가 매우 편할 것 같다. 기존의 문서들을 다 md 파일로 가지고 있기 때문에 옮기는 것이 어렵지는 않다. 하지만 블로그에서의 맞춤법 검사라던지 티스토리에 맞게 수정한 내용들이 md에 업데이트되진 않았다. 따라서 옮길 생각에 머리가 아프다.. 또한 아직은 hexo에 익숙하지도 않아서 문서화만 잘해두고, 천천히 github blog로 글을 옮길 생각이다. 미래의 나에게 욕먹지 않기 위해서 열심히 옮겨보자... 커스터마이징도..

Requirements

git
node.js(https://nodejs.org/en/)

$ npm install -g hexo-cli

Init hexo project

$ hexo init <folder>
$ cd <folder>
$ npm install

clean && generate static files

$ hexo clean && hexo generate

Run hexo server

$ hexo server

deploy

$ npm install hexo-deployer-git --save
deploy:
  type: git
  repo: <repository url>  branch: [branch] #published
  message:

7. git flow에 익숙해지기.

git flow란? branch 부분에 참고.
만약 git이 git for windows가 아니라면 git for windows로 재설치를 해줘야 한다. 그 이유는 git flow를 편리하게 사용하는 도구를 제공하기 때문이다. 그냥 git에서는 설정이 힘들다. 환경이 다른 경우에는 아래 사이트를 참고하여 setup을 하자.
이 사이트에서 git flow에 대한 자세한 설명이 돼 있다. 보고 따라 해 보자.

8. 파일 이름 수정 or 파일 이동

mv 명령어를 그냥 써버리면 history가 깨져버리기에 연속성에 문제가 생긴다. 이를 해결하기 위해서

이전에 끊긴 history를 연결시킬 수 있는가? 절대 없다... 따라서 꼭 git mv로 연속성을 꼭 유지시켜 줘야 한다.

9. Status 되돌리는 법

checkout

checkout에는 2가지 기능이 있는데 현재는 restore, switch로 변경됐다. checkout으로도 사용은 가능하다. git add 로 staged 된 파일을 되돌려야 하는 상황이 있다.

1. 한 가지 파일에 대한 상태 되돌리기.

git checkout -- (해당 파일 이름) : 한 가지 파일에 대한 상태를 되돌린다.
git checkout -- . : 전체 파일의 상태를 되돌린다.

2. Unstaging (staged 된 데이터 내리기)

git reset HEAD {해당 파일 이름} : Staged 된 파일을 Unstaged로 바꿔준다.
git rm -rf {파일명} : Unstaged까지 하고 파일을 삭제함.

3. Commit 수정

가장 최신의 Commit 수정을 권고한다. 이전의 커밋은 역사 관점에서 삭제하거나 바꾸는 것이 아니라는 관점에 동의한다. 따라서 우리는 실수한 부분을 새로 Commit 하는 방법으로 대체한다. 오래된 Commit을 삭제하거나 수정하는 일은 없도록 하자. rebase는 브랜치의 시점을 옮겨주는 것이다. interactive 하게 commit을 바꿔주는 기능도 있다. 하지만 배우지 않는다. 우리의 관점과는 멀기 때문에.

git commit --amend : 가장 최신의 commit의 내용을 수정할 수 있다.
commit은 자주 하고 push는 신중하게 해라. push 된 데이터를 수정하는 것이 더욱 어렵기 때문이다. 결국엔 잘못된 push나 commit을 해결하는 것도 개발자의 실력이다.

4. Reset (최악! 절대 쓰지 마라)

위험한 부분들이 많다. 아예 배우지 않는 것을 추천한다. 실제로 배우지 않았다...

//직전 3개의 commit을 삭제한 후, remote에 강제 push
$ git reset --hard HEAD~3
$ git push -f origin <branch>

5. Revert

Reset을 사용하기보다는 차라리 잘못 사용했다는 내용을 추가해줄 것. Reset 같은 경우, 나의 로컬에서는 삭제가 되어도, 다른 사람들의 로컬에 데이터가 남아있다면 해당 데이터가 좀비가 되어버려서 계속 생성이 된다. 이를 해결하기 위해서 삭제가 되었다는 것을 Revert를 사용해 git에게 알려준다.

/* 현재 HEAD에서 직전의 3개의 commit을 순서대로 거슬러 올라가 해당 내역에 대해 commit, push 수행 */
$ git revert --no-commit HEAD~3..
$ git commit
$ git push origin <branch>

잘못하기 전 과거로 돌아가 최신을 유지하면서 되돌렸다는 이력을 commit으로 남겨 모든 팀원이 이 사항을 공유할 수 있음.
commit을 따로 안 할 땐 --no-edit
merge commit을 되돌릴 땐 -m($git revert -m {1 or 2} {merge commit id})

10. 협업

크게 2가지 방법이 있다.

콜라보레이터
권한을 팀원에게 주는 방법. 이 방법은 팀원들이 나의 원본에 직접 넣는 것이라 좋은 방법이 아님.
fork를 하는 방법
팀원들이 fork로 내 repo를 복사하고, git flow 작업을 통해서 pull request를 요청한다.

Issue & Projects

Issue: 프로젝트, 레포와 관계된 모든 해야 할 일과 버그, 개선사항 등을 기록.

Projects: 해야 할 일의 진도에 따른 구성과 우선순위 지정.

팀장의 역할

Repo생성 -> git flow init -> 작업 대상 파일 생성 -> develop 브랜치를 만들어놓은 상태를 팀원에게 공유한다.

팀원의 역할

팀원들은 포크를 하기 전에 issue를 작성한다. issue에 설명을 최대한 자세히 적어주는 게 좋음.
마지막 Task를 끝낼 때 모든 이슈에 넘버링이 들어가 있다. #1번 이슈에 대한 Commit이다.라는 의미를 붙여줘야 한다. git convention중의 문법 안에 있다. resolved #1 ,close #1
팀장의 repo로 push를 할 때, develop인지 꼭 확인
develop 브랜치로 push를 하기 전에, fetch로 Upstream(팀장의 Repo)에 변경된 데이터 있는지 확인하기.

/* pull 명령어 사용을 지양하자. */
$ git fetch upstream develop
$ git merge FETCH_HEAD

/* 팀원들이 업데이트된 develop을 받을 때 
만약 팀장 git remote가 없다면 git remote에서 
팀장 레퍼런스가 없으면 등록해야 한다.

팀장의 Repo에서 fetch를 develop 브랜치에 해준다면,
FETCH_HEAD에 해당 정보들을 담게 된다. 그러므로
해당 정보들을 merge 해주는 과정.
*/
$ git remote add upstream {팀장 Repo 주소}       
$ git fetch upstream develop
$ git merge FETCH_HEAD

정리

git flow 전략을 효율적으로 사용하기 위해 git을 처음부터 다시 제대로 배웠다. git을 이렇게 체계적으로 실제 업무에 쓰이는 방식을 공부를 할 기회가 없었다. 이 공부를 통해서 내가 git을 사용하면서 간과한 부분(Commit message, Convention ... )들과 안 좋은 습관들을 피드백할 수 있는 시간이었다. 실제로 협업에 쓰이는 방식을 통해서 git을 다시 배우니 재미있었고 유익했다.