1월 14일 여정 6일차이다.
입학 시험에 합격하였다는 즐거운 소식이 들려왔다.
오늘은 깃허브에 대하여 조금 더 자세하게 이야기 해볼까 한다.

오늘의 Today I Learned

Problem

Branch 전략? Git-flow? GitHub-flow? 이게 다 무엇일까? 강의를 들었지만 사실 전혀 상상이 가지 않았다. 깃허브에 대해 이제까지 내가 알고 있던 것들과 전혀 달랐다.

try

구글에 검색을 해보았다. Branch 전략, Git-Flow, GitHub-flow 검색 해보았지만, 이론으로는 전혀 이해가 가지 않았다. 보자마자 제일 먼저 드는 생각은 왜 구지 저렇게 하는 것일까? 였다.

solve

나는 바탕화면에 테스트용 파일을 만들어 혼자 실험을 하였다.
실험은 이러하다. front와 back이라는 2개의 브런치에서 각각의 작업을 하면 나중에 main에서 전부 merge를 하여 합치는 것이다.

workflow라는 폴더에 3개의 파일이 있다. 기본적으로 나는 여기서 github-flow라는 것을 구현해보려고 하였다.

위와 같이 main과 2개 front back 이라는 branch가 있다.
일단 프론트에서 작업을 한다고 가정해보자. 프론트에서 html과 css 파일을 수정하였다. 수정을 하여 commit과 push를 하였다.

나머지 back 역시 동일한 작업 후에 commit과 push를 하였다.

Sourcetree를 보면 이러하다. main에 아직 merge가 되지는 않았지만 front와 back이 전부 작업을 마쳤다고 가정해보자. 이제는 main에 merge만 남았다.

아까는 merge 전이고, 지금은 merge 후이다. main에 back과 front의 브랜치가 병합되었다.
한번 더 여러 다른 작업들도 해보겠다.

아까보다 무엇인가가 많아졌다. 자세히 보면 2개의 branch가 나중에 main에서 merge되는 것을 볼 수 있다.
이것이 바로 github-flow이다. 내가 분할 작업 후에 하나로 합쳐보는 것 그것이 github-flow(git-flow)이다.

knew

branch 전략이라는 것은 정말로 어려운 것이 아니다. 결국 branch를 어떻게 만들어 일을 더 효율적으로 효과적으로 할 것이가에 대한 전략이다. 여러 브랜치를 나누에 보기 쉽게 분할하고 나중에 test가 끝나면 main에 합치는 것이 branch전략이고 workflow이다.

마지막으로

이제는 깃허브로 협업의 준비가 다 되었다.
다음주부터 시작되는 모든 협업에 내가 배우고 실험한 지식을 활용할 것이다.