버전관리 : Git & Github 사용하기

Git이 무엇인가는 구글링만 해봐도 나오니까 생략하고, 사용하는 명령어 위주로 정리.

git 설치는 여기서 : https://git-scm.com/

간단한 CLI 명령어

pwd : 현재 위치를 확인하는 명령어
cd는 폴더를 이동하는 명령어다. 여기에 옵션을 붙여서 다양하게 사용할 수도 있다.
cd / : 최상위폴더, 루트폴더
cd ~ : 사용자폴더
cd .. : 상위 올라갈 때. 두단계 이상 올라가고 싶으면 ../.. 식으로 쓰면 된다.

디렉토리(윈도우즈의 경우엔 폴더)를 만든 다음에 해당 디렉토리로 cd를 이용해서 이동한다. 

이 다음에 깃허브로 이동해 저장소를 만든다. 저장소를 만들고 나면 아직 아무것도 없는 저장소에 어떤 명령어가 필요한지 적혀있다. 캡처를 해둘걸.... 이미 다 만들어서 캡처가 불가능함..ㅎ

아무튼 이 Github에 README파일을 추가해 다른 사람들이 보기 편하도록 해줘야 한다. 먼저 다음의 명령어를 입력한다.
echo "# Explanation(<-본인이 적고 싶은거 쓰면 된다)" >> README.md

이렇게 README파일이 생성된다.  이 다음에 저장소를 초기화해주기 위해서 git init을 입력한다. git 저장소 초기화는 생성시 딱 한번만 하면 된다! 이 다음엔..

git add README.md
git commit -m "first commit"
git remote add origin https://github.com/~~~
git push -u origin master

이렇게 하라고 되어있지만. 이대로 바로 적으면 오류가 나는 경우가 있다. 사실 처음이면 오류가 난다. 이거는 커밋하는 사람이 누구인지 지정해주지 않아서 가 원인이었던 것 같다. 이는 다음과 같이 적어준다.

$ git config --global user.name "Your Name"
$ git config --global user.email you@example.com

글로벌로 한번 정의해주면 계속 적용되므로 이 계정에선 다시 등록할 필요가 없다 한다. 

다음은 이후 필요한 git 명령어들. git 명령어에서 처음에 잘 알아야하는 것은 add, commit, push 이 세가지다. 물론 다른것도 잘 알아야하지만 아직 깃에 익숙하지 않은 처음에는 이 셋을 정말 지겹도록 쓰게 될 것이기 때문이다.

변경 후 스테이지-로컬, 그리고 깃허브에 올라가는 순서이다.

git status : 변경상황 확인. 빨간색인 것은 변경된 후 스테이지에 안 올라온 상태이고, 녹색은 스테이지에 올라온 상태다. 커밋이 완료되면 컬러로 나오는게 아니라 1 commit 이런 식으로 표기.

git add : 스테이지에 올림.

git commit : 로컬에 올림

git push origin master : 깃허브에 올림. (커밋된 것에 한해서)

touch 파일명 : 파일 생성

git commit -v : vi편집기에서 수정하고 동시에 커밋하는 방법

다음은 vim 명령어이다.

i : insert 모드로 변경. 아래에 insert가 뜨므로 확인이 가능!

첫줄은 제목을 입력할 수 있다. 그 다음줄에 커밋 내용을 입력하면 된다. 컬러가 변경되므로 확인 가능

w : write, q는 quit인데, esc로 insert모드에서 빠져 나와서, :wq를 입력하면 작성 내용이 저장되면서 편집기가 종료된다.

다음은 브랜치다. 난 이놈의 브랜치가 대체 뭔가 하면서 궁금해했다. 아무튼 기본 브랜치로 master가 있는데 (develop를 개발시 기본 브랜치로 정하기도 한다) 보통 master에 머지를 해서 최종 배포를 하는 경우가 대부분이다. 

이때 협업을 하는 상황을 가정해보자. 이 때 서로 연계된 기능을 개발하는 개발자들이 작업하다가 충돌한다면...? 한명씩 개발할 수는 없으니.... 이걸 위해서 나온 것이 브랜치다! 브랜치는 기본 브랜치 master(혹은 dev)에서 나눠지는...단어 그대로 가지이다. 이 브랜치내에서 내가 만든 코드를 테스트해보고 이상이 없으면 후에 다시 master 브랜치에 merge를 해주면 된다. 

git 의 기본 명령어 2

git log : 이 방법을 통해서 git의 커밋 기록을 볼 수 있다.
git branch : git의 브랜치 종류를 확인할 수 있다.

git checkout -b <feature> : -b는 새 브랜치를 만든다는 뜻이다. 즉 feature라는 새 브랜치를 생성한다. 마스터와 독립적인 부분으로 서로에게 영향을 끼치지 않는다. 따라서 푸시할때 git push origin feature라고 해야한다. 

git checkout <브랜치 명> : 이동방법
git checkout -D <브랜치명> : 해당 브랜치 삭제

브랜치가 다르면 로그 역시 달라진다.

git merge <feature> : Merge. Merge 후에 다시 푸시를 해줘야 깃허브가 병합 사실을 알아챈다. Merge말고 pull request도 많이 씀.

git pull origin master : master내의 최신 코드를 다 내 로컬 워킹디렉토리로 끌고오겠다는 것.

Git flow

Git에서 브랜치를 새로 생성하고 만들고 배포하고 수정하는 형태가 계속 해서 반복된다. 이를 바탕으로 만들어진 Git을 사용하는 방법론. git의 확장판으로 인식해도 무리는 없는듯 하다.

이미지 출처 : https://leanpub.com/git-flow

각 브랜치의 기능은 다음과 같다.
master : release용. 개발이 끝나면 배포할 때 여기로 옮긴다.
develop : 개발단계에서 사용
feature : develop를 구성하며, 이 feature 브랜치 역시 다른 feature브랜치로 구성될 수 있다.
hotfix : 급하게 수정해서 production에 반영해야할 때 사용.

여기서 개발은 develop 브랜치에서 이뤄지므로, 여기가 가장 메인이 될 것이다. 여기에서 각 기능당 feature/(something)으로 브랜치를 생성하여 개발 후 pull request를 통해 merge한다. 그런데 release된 후에 문제가 발생한 경우, 수정을 위해 사용하는 것이 hotfix 브랜치이다. 

git flow 설치

우분투 : apt-get install git-flow
MAC : brew install git-flow

이렇게 설치 후 확인을 위해 커맨드라인에 git flow라고 쳐서 뭔가 주르륵 나오면 설치된 것.

Github :Branch Protect

github에서 해당 repository의 Settings에 가면 Branches가 있다. develop와 master 브랜치를 혹여나 실수로 삭제하지 않도록 해줄수 있다. 여기서 Protected branches에서 브랜치를 선택해서 protect걸어준다고 하면 된다.

git flow 초기화

git flow init : git 시작시 git init 이라 하듯이, git flow도 init으로 시작한다. 그럼 여러 브랜치명을 어떻게 설정할지 물어보는데, 늘 그렇듯 그냥 기본으로 가는 것이 가장 편한 일이다. 그냥 계속 엔터를 치면 각 브랜치들이 생성되고, master에서 develop로 이동된다. 혹시 모르니 git branch로 현재 브랜치를 확인해보자.  

git flow feature 생성

가장 먼저 테스트를 위해 간단한 기능을 만들어보자. 기능이니 feature 브랜치에서 시작한다.

git flow feature start (기능명) 

이 다음, 해당 브랜치가 생성된 것을 레포지토리에 알려준다. push 명령어를 사용하면 된다.

git push origin feature/(기능명)

Github : Issue 

그 때 그 때마다 어떤 것을 만들지에 대해서 목표를 세울 수 있다. 여기서 milestone 생성을 할 때 보면, 구현할 기능에 대해 적고 날짜를 선택할 수 있다. 그 옆의 Labels는 해당 milestone이 무엇과 관련있는 것인지 정할 수 있다. 예시로 나의(정확히는 수찬샘이 생성한 labels) Labels 모습이다

이 라벨들은 milestone 생성시 추가해서 이게 뭐와 관련있는 것인지 나타낼 수 있다. (약간 카테고리같은 느낌) 또한 milestone에는 이 milestone에 누가 참여할 것인지도 추가할 수 있다.

+실제 프로젝트는 milestone을 여러개로 나눠줘서 진행하게 된다.
+ issue는 기능들의 단위 같은 느낌으로 생각하자.

Github : Pull Request

어떤 feature가 완료되었을 때 git 내에서 명시적으로 하는 것 말고 github내에서 merge하기 위해서 하는 것. Pull Request에서 생성하면 이슈 연결이 가능하다. #을 치면 이슈가 떠오른다. 만약 1 이슈에 1 pr이라면 아래의 close버튼으로 이슈를 닫아주자.

다시 로컬로 돌아오자. 먼저 develop 브랜치로 이동하자. git checkout develop
로컬에서 Github의 내용을 끌어오기 위해 다음의 명령어를 사용한다.

git pull origin develop 

위에서 말했듯이 각 branch마다 log는 다르게 된다. 만약 다른 브랜치의 개발상황을 끌어오고 싶다면 다음 명령어를 사용한다. 

git rebase [basebranch] [topicbranch] 

근데 내가 빠가라서 이거 순서가 헷갈려서 코드가 꼬이는 일이 발생해버렸다. 그냥 헷갈리지 않도록 checkout으로 다른 브랜치로 이동 후 git rebase [개발상황을 가져올 브랜치] 명령어를 사용하자.

* rebase 명령어는 merge랑 비교되는데, merge는 합치는 것이고 rebase는 가져오는 것이라는 점이 다르다.

fork란? 다른 저장소에 있는 프로젝트를 내 저장소로 따오는 것. 

pull request ? 내가 작업한 부분을 기여하고 싶을 때 하는 것. 이 pull request를 하고 나서, 이를 프로젝트를 관리하는 개발자가 수락하면 내가 작업한 부분이 merge되는 것이다.

clone 후 git remote -v 해보면 내가 clone한 프로젝트와, 기존 프로젝트 모두 origin으로 표시된다. 이 때, 내가 내려받은 소스와 기존 프로젝트간의 싱크를 맞춰주고 싶을 때 사용하는 것이 git remote add upstream (상위 프로젝트명)

관례적으로 내 repository는 origin, 가장 근본이 되는 프로젝트는 upstream이라고 칭한다.

이 방법으로 오픈소스 프로젝트에도 기여할 수 있다. 
Pull request는 말 그대로 요청이니 원 개발자의 스타일과 맞지 않거나, 소스에 너무 많이 손을 댔다거나 한다면 거절될 수도 있는 것이니 혹시 거절되더라도 그러려니 할 것! (이라고 하지만 그래도 거절당하면 슬프다.)

Slack + Github

상황가정 : 4명의 팀원들이 프로젝트를 한다고 생각해보자..이 때 무슨 상황이 일어나는지 알려면 github상에선 새로고침을 해줘야하는데, 계속 새로고침을 하면서 들여다볼 수도 없는 노릇이다. 이럴 때 slack으로 알림으로 받는다면 해결할 수 있다!

- 깃헙을 크롤링하다 변동이 생기면 나타나는 메시지

이게 동작원리에 가깝다고..

이걸 github hooks (hook => 특정 이벤트가 발생한 시점에 발생되는 기능/이벤트)라고 하는데..

방법
1. 개인이나 팀 슬랙을 만든다.
슬랙 링크 : https://slack.com/
2. slack의 채널에서 Add an app or custom integration을 누른다-> github 검색
3. 특정 레포지토리에 이벤트가 발생하면 슬랙 특정채널에 소식이 가도록 설정해주면 된다.

Gitignore

깃허브에 개인화된 설정은 올리지 않는 것이 관행이다.(관행이라기 보단 보안상으로 안올리는 이유도 있다.) 이 부분을 해결할 수 있는 것이 바로 gitignore인데, 여기에 무시할 설정들을 추가하면 깃허브에 올리지 않도록 할 수 있다. 

이때 이걸 일일이 수동으로 저장할 필요없이 python에 특화된 설정이 있다. 이 설정을 다운받을 수 있는 링크는 다음과 같다.

링크 : https://github.com/github/gitignore/blob/master/Python.gitignore

해당 링크에서 raw라는 부분을 눌러 주소를 복사해준다. 그 다음 터미널에다가 wget이라는 명령어를 치는데, 이것은 네트워크 다운로더로 자료들을 다운받을 수 있게 해주는 것이다. 

wget https://github.com/github/gitignore/blob/master/Python.gitignore

이 명령어로 받은 다음, mv Python.gitignore .gitignore 이라고 하면 현재 나의 gitignore에 해당 파일의 내용이 복사된다. 이 다음 git add .gitignore 후 커밋을 해주면 이제 앞으로 나의 개인화된 설정은 올라가지 않도록 해준 것이다.

** gitignore에 설정을 했음에도 안 먹히는 경우가 있는데 이럴 땐 캐시가 남아서 그럴 가능성이 높다. git rm --cache를 해준다.