[Git]

개발자들은 git을 많이 사용한다. 이유를 몰랐었지만 배워보니 너무 멋진 도구이다.

 

왜 깃이 중요하냐? 

• Single Source of Truth. 단일 요소 공급원이기 때문에 관리가 편하다.
• 지속적 통합이 가능하다.
• 데브옵스와 비슷한 깃옵스라는 말이 있을 정도다.

 

다음에도 보기 쉽게 협업을 위한 사용법을 기록하고자 한다.

---

위 그림처럼 작업이 진행된다.

 

크게 local, remote로 repository가 나뉜다. 

 

unstaged 혹은 untracked 파일은 git의 관리를 받지 않는 영역이라 한다.

 

staging area는 push 준비단계인 local repo이다.

 

1) 작업할 repo를 깃허브에서 찾고 fork 한다.

2) 작업물을 올린다.

$ get clone {https 또는 ssh 주소}

$ cd {복제된 파일}

$ nano hello.js //기능 추가 작업 혹은 수정 작업을 한다.

$ git commit -am "작업명" //작업 내용을 stage에 올리고 동시에 커밋한다.

$ git reset HEAD^1 //만약 실수했을 때 헤드를 1번 뒤로 돌린다.

$ git push origin master //remote repository의 master 브랜치에 올린다.

---

내 작업을 PR 해보자

PR은 pull request로 내 작업을 해당 저장소에 추가해달라는 요청을 하는 것이다.

 

내가 복제해온 해당 저장소에 가서 pull request 버튼을 클릭하면 된다.

---

동료와 협업해보자

$ git remote add {동료이름} {동료의 repo 주소} //나의 origin repo와 동료의 repo를 연결한다.

$ git pull {동료이름} {가져올 branch 이름} //동료의 작업물을 나의 local repo로 가져온다.

$ git push origin {branch 이름} //나의 origin으로 올리기

---

브랜치 전략

• main : 최종본. production-ready
• hotfix : 버그 수정
• release : 어떠한 것을 배포할지 선정하는 단계. 깃허브에 자체 기능이 있어서 없어도 되긴 한다.
• develop : 개발버전. 안정성이 보장되지 않는다. 배포 전 main에 머지된다.
• feature : 기능 구현 브랜치. 예를 들어 feat/mypage, feat/login

 

이 브랜치들을 명령어로만 구현하기엔 복잡하다. 

GUI 프로그램이 있다! smartgit, sourcetree, kraken

#dogfeet - A successful git branching model

 

---

merge 방식

 

• fast-forward: 원본에 커밋한 기록(변경사항)이 없다면, 합쳐서 일자로 merge 하겠다. 브랜치들은 사라지지 않는다. 포인터 같은 느낌이라 아래의 소셜 가입 구현을 가리키는 것은 feat/signup, HEAD, feat/signup-oauth

• rebase: fast forward와 비슷한 개념이다. 나중에도 또 나온다.