Github, git kraken으로 프로젝트 관리하기

이전 글https://brilliantdevelop.tistory.com/206 에서 Local에서 간단한 git 사용을 해봤다.

명령어를 통해서 git을 관리할 수도 있지만,

git을 좀 더 쉽게 화면으로 관리할 수 있게 해주는 GUI tool이 존재한다.

대표적으로는 source tree, git gui 등이 있다.

여기서는 Git Kraken을 통해 좀 더 쉽게 Git을 관리해보려고 한다.

또  Local뿐만 아니라 원격에서도 관리하기 위해서 Github를 사용할 것이다.

 

 

 

 

깃허브와 깃 크라켄 연동하기

git 초기화하기

다음과 같이 폴더에 작업내용을 만들고 git init으로 초기화한다

(git kraken은 git init이 되어있지않으면 연동할 수 없다.)

 

 git kraken과 Local Repository 연결하기

깃 크라켄에서 open a repo를 선택해 작업할 폴더를 선택합니다.

※혹시 Open a Repository가 안되면  Init-Local only-Initilize a Repo를 통해 진행해보자.

Open a Repository은 git init이 되어있어야 하지만

Initilize a Repo은 git kraken이 git init까지 해준다 이때는 init폴더가 필요없다.

 

이렇게 하면 깃 크라켄과  로컬컴퓨터의 github_pracitce 폴더가 연동된다.

 

연동이 됐다면 commit도 해보자. 여기서 처음으로 a.txt파일을 commit하자.

local의 브랜치 이름은 master로 설정했다.

 

 

 

 

깃 크라켄+깃허브연동하기

이제 깃 크라켄(+github_practice폴더)를 github와 연동해보자.

a.txt를 커밋한 상태에서 Remote인 github에 push하려고 한다.  

깃 크라켄에서 github에 push를 하기위해  github에서 repository를 만들고 주소를 복사한다.

 

 

 

깃 크라켄에서 Remote에  github repository주소로 연결한다.

(난 GitHub로 안되서 URL로 했다.. 둘중 원하는 방식으로 연결만 하면 된다.)

 

 

 

깃크라켄에서 Remote(github)에 연결이 됐다면  아까 commit한 내용을 push하자

(push/pull 할 때는 항상 원격 로컬 브랜치 확인하자)

깃허브에서 로컬에서 push된 내용이 반영된 걸 볼 수 있다.

 

 

 

 

 

깃허브 Pull 충돌 해결하기 

충돌은 다음 상황에서 발생한다.

 

 

 

 

이 상황은 Local입장에서 보면  브랜치를 merge하는 과정이랑 유사하다.

 

 

 

 

 

 

 

이런 상황에서 깃 크라켄은 pull을 하지 않았기에 아직 로컬에는 적용이 되지 않았지만  

충돌이 날거를 미리 감지하기 때문에 다음화면처럼 보여준다.

여기서 8e6e16은 다른사람이 커밋(+push)했을 때의 커밋번호다.

 

 

 

깃크라켄을 이용해 pull을 해보면 다음과 같이 나타난다.

 

 

여기서 mark resolved는 문제가 해결된것으로 간주하겠다는 것이다.(누르지 말자)

a.txt를 누르면 충돌을 해결하는 창이 나오게된다.

 

 

충돌난 파일을 수정해 output을 낸다. 그리고 save버튼을 누르면 

수정된 output  a.txt가 staged되고 commit하면 된다.

 

 

 

충돌을 해결한 a.txt파일은 로컬에서만 commit 됐다.  ('수정된 a.txt 커밋 메세지')

이제 push하면 remote에도 수정된 a.txt커밋이 적용된다.  

 

 

 

 

 

 

 

깃허브 project kanban보드로 프로젝트 관리하기

kanban board 프로젝트 만들기

깃허브에서 새로운 프로젝트를 kanban board 형태로 만든다.

 

 

 

프로젝트를 만들면 다음과 같이 kanban board가 보인다.

 

여기에 프로젝트를 하면서 해야 할 작업들을 만들고 작성하면 된다.

 

 

Item 관리

밑에 Add Item을 통해 해야할 작업들의 내용을 추가해보자.

 

 

Item에서 필요한 내용들을 작성한다.

Convert to issue는 현재 진행중인 프로젝트의 Repository를 선택하면 도니다.

 

 

 

convert to Issue를 하면 다음과 같이 변경된다. 

여기서 프로젝트 환경설정에 관한 세부내용을 작성한다.

 

 

브랜치 만들어 프로젝트 관리하기

보통 하나의 Item 작업은 하나의 브랜치로 만들어서 작업한다.

브랜치를 깃크라켄(Local)에서 만들어 push를 하든 깃허브(Remote)에서 만든 다음,   깃크라켄으로 pull하든  

Remote와 Local의 브랜치 상태를 확인하면서 조심스럽게 작업하자.

대부분의 일반적인 작업이라면 브랜치를 Local에서 만들어 push할 것이다.

 

'프로젝트 환경설정'이라는 Item 작업을 위해 Local에서 브랜치를 만들자.

깃 크라켄 Local 탭에서 create branch here을 선택하고 , 브랜치 이름은 project-setting이라고 하자.

 

 

 

브랜치를 만들었으면 '프로젝트 환경설정'에 맞는 일을 진행한 후 commit하면 된다.

여기서는 간단하게 text파일로 프로젝트 환경설정을 다 했다고 가정하고 진행해보겠다.

 

 

 

 

깃 크라켄에서 변경된 내용을 확인하고 커밋해보자.  이 때 현재 작업중인 브랜치를 꼭 확인하자.

 

 

 

현재까지의 커밋상태는 다음과 같다.

 

 

 

 

이런식으로 프로젝트를 진행하면서  commit을 반복한 뒤에  push를 해보자.

push를 했다면 remote에도 project-setting 브랜치가 생기는 걸 알 수 있다.

 

 

 

 

이렇게 commit push를 하다가 '프로젝트 환경설정' 마지막작업까지 commit, push를 했다면

이제는 project-setting 브랜치에서 작업한 내용을 master브랜치에 합쳐야 한다.

이 때 바로 merge를 해도 되지만,  깃허브에서 pull request를 통해  merge를 진행해보자.

 

깃허브 repository에서 Pull requests 탭으로 가서 만들어도 되고 

바로 pull request 만들기 버튼을 눌러도 된다.

 

 

 

pull request에 필요한 내용들을 작성하고 pull request를 만들자.

Pull request는 브랜치를 merge하기전에 확인하는 과정이다.

지금은 혼자 작업하고 있으니까 reviewer를 선택할 수 없지만, 같이 작업하는 동료한테

merge 전 확인작업을 위임할 수 있다.

 

 

 

pull request를 만들었다면 해당 브랜치의 내용들을

commits, Checks, Files changed 탭에서 확인하고 이상이 있다면 pull request에 comment를 추가한다.

이상이 없다면 merge를 하면 된다.

 

 

 

 

Merge를 했다면 쓸모없는 브랜치는 삭제해주자.

 

 

 

깃허브에서 Merge+브랜치 삭제를 했을 때 Remote와 Local의 commit log는 다음과 같다.

파란선은 삭제된 브랜치이다.

 

 

Pull request를 하고 Merge를 한것은 Remote(깃허브)이기 때문에 Local에서는 적용이 안되어있다.

Pull request와 Merge내용을 Local에 적용하기 위해  Local에서 Master 브랜치로 옮기고

Pull한다. (Remote의 Master 내용을 Local의 master에...)

그리고 필요없어진 Local의 project-setting 브랜치를 제거해주면 Merge과정이 Local, Remote 모두 적용된다.

 

 

Local에도 적용해야 드디어 project-setting 작업이 끝났다고 볼수 있다.

 

 

 

 

 

Merge를 로컬에서 하고 그냥 push해도 되는데 굳이 Github에서 pull request 만들고 merge 하는 이유는

브랜치를 만들어 하나의 작업을 했을 때 이 작업결과를 master 브랜치에 바로 합치기 전에 확인하기 위해서이다. 

Local, Remote 커밋상태를 조금 더 신경써야 하지만,

다른사람과의 협업을 통해 더 안정적인 작업결과물(브랜치)를 master에  합치기 때문에

프로젝트 전체적인 안전성이 더 높아지는 결과가 된다.

 

 

 

이렇게 merge를 통해 하나의 작업을 완료했다면 kanban board에서 해당 작업이 완료댔다는 표시를 하자.