핵심 쏙쏙 git 2

git으로 협업하기

같은 파일을 동시에 푸시하면 충돌이 발생하게 된다.

이 경우 다음과 같이 해결한다.

1. 누가 이 작업 할 것인지 정한다. (작업을 이슈라고 표현하여 [이슈를 할당한다]라고 표현하기도 한다.) - Issue
2. 각자 맡은 것을 작업한다. - Branch
3. 각자 작업을 프로젝트에 합칠 수 있게 공유한다. - merge
4. 작업한 내용을 리뷰(피드백)하고 최종적으로 프로젝트에 반영한다. - PR 후 merge

 

 

Issue - 할당

Issue는 누가 어떤 역할을 할 것인지 정하는 것만이 전부가 아니다. 

프로젝트에서 이슈라는 건, 프로젝트에서 해결해야 하는 문제를 이야기한다. 예를 들면 문제제기를 한다던가 의견을 제시할 수 있다.

New issue를 클릭하면 새로운 이슈를 만들 수 있고 내용을 입력한 뒤 해당 이슈를 누가 맡을 것인지 Assignees를 정하고 이슈에 어떤 라벨을 붙일 것인지 Labels를 클릭하여 선택하거나 만들 수 있다.

제목에 #1은 이슈의 번호이다.

이슈가 해결되었으면 Close issue를 누르면 됩니다. 만약 필요하다면 Reopen issue 버튼을 클릭하여 다시 열면 됩니다.

 

이슈와 커밋을 연결할 수 있습니다. 커밋을 할 때 이슈번호를 입력(여기서는 #1)하면 다음과 같이 나옵니다.

code에서 #1을 누르면 해당 이슈가 나온다

이슈에 이슈 번호를 적은 repo가 올라왔음을 알려준다.

이것을 이용해서 팀원들과 의사소통을 하는데 도움이 될 수 있습니다.

이슈 작성에 대해 보다 자세히 알고 싶으시다면 다음 페이지에서 알아볼 수 있습니다.

https://terry-some.tistory.com/93

GitHub를 활용한 이슈 관리

 

 

Branch - 각자 공간에서 작업하기

브랜치(branch)란 무엇일까?

앞서 브랜치는 각자 맡은 것을 작업한다고 했습니다. 즉, 각자 작업을 할 수 있는 공간을 만들기 위해 사용하는 것이 branch입니다.

브랜치는 나뭇가지와 비유되곤 합니다. 나뭇가지가 뻗어나오듯 기능에 맞게 나눠 작업하는 모습이 닮았기 때문입니다.

간단한 그림을 보겠습니다.

브랜치를 그림으로 나타낸 모습

master라는 기본 브랜치가 있고 별도의 작업을 위해 Feature 1,2 를 브랜치하여 작업을 마친 뒤 다시 병합(merge)하여 기본 브랜치와 합친 것을 볼 수 있습니다.

작업할 브랜치로 바꾸는 것을 체크아웃한다고 합니다. 그림을 예로 들면 마스터에서 Feature1으로 체크아웃한다고 말할 수 있습니다.

그리고 브랜치의 이름을 정할 때 보통 [feature + / + (이슈 번호(없으면 생략) + 이름)]으로 짓습니다. 이외에도 프로젝트마다 정해진 브

또한 브랜치를 삭제할 수 있습니다. 이 경우 해당 브랜치에서 작업했던 내역이 사라지게 됩니다.

 

 

Merge(병합) - 작업 내용 합치기

Merge(병합)은 브랜치를 다른 브랜치에 합치는 것을 뜻합니다. 즉, 특정 브랜치의 commit을 다른 브랜치의 commit 내역에 모두 반영하는 것입니다. 기본적인 설정은 해당 브랜치의 모든 commit을 모두 다 반영합니다.

현업에서는 개발하기 위한 브랜치가 있고 서비스를 사용자에게 배포하기 위한 브랜치가 따로 있는 등 용도에 따라 브랜치가 나뉩니다.

✨ 프로젝트마다 Branch 관리하는 방법이 조금씩 다릅니다. commit하고 작업하는 방법을 flow(흐름)라고 합니다. 대표적으로 github-flow, gitlab-flow, git-flow가 있습니다. 웹 프로젝트 개발의 경우 github-flow를 많이 사용합니다.

flow의 자세한 설명은 다음 페이지를 참고하시길 바랍니다.
설명 1. https://guides.github.com/introduction/flow/
설명 2. https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/

 

병합을 하려면 먼저 병합할 브런치에 체크아웃을 해야합니다. 이후 병합을 하면 되는데 병합 방식은 다음과 같습니다.

출처: https://meetup.toast.com/posts/122

이 중 원하는 방식을 하나 채택해서 병합하면 됩니다.

이렇게 하면 main branch에 특정 브랜치의 내역이 반영됩니다. 그러면 특정 브랜치는 제 역할을 다 했음으로 삭제해도 상관없습니다. 이때 체크아웃으로 메인 브랜치를 선택해야 삭제가 진행됩니다.

만약 다른 브랜치에서 같은 파일을 수정한다면 merge conflict, 머지 할 때 충돌이 일어나게 됩니다. 그래서 이 점을 주의하며 브랜치해야 합니다.

 

 

Merge conflict - 충돌 해결하기

 

에러를 안 내는 게 중요한 것이 아니라 버그를 고칠 수 있느냐 없느냐가 중요하다

 

에러는 일어날 수 밖에 없습니다. 실수를 할 수 있고 모르는 것이 나타날 수 있고 내가 아닌 타인으로 인해 일어날 수 있습니다. 이외에도 다양한 방법으로 에러는 일어납니다. 

그렇기 때문에 에러를 내지 않으려고 노력하는 것보다 버그를 찾아내고 수정하는 법을 익혀야 합니다.

 

git으로 일어나는 에러 중 하나인 merge conflict는 하나의 파일을 여러 브랜치에서 수정하고 하나의 branch에 merge하려고 할 때 merge conflict(병합 충돌)가 발생합니다.

이 경우 3가지 방법으로 해결할 수 있습니다.

1. 원래 파일을 유지하는 방법
2. 병합하려는 파일로 덮어씌우는 방법
3. 파일 내용 변경 전, 후가 함께 있는 파일로 존재하는 상태에서 사용자가 직접 수정하여 충돌을 해결하는 방법

직접 수정하면 이런 형태의 파일이 주어진다. (변경 전, 후가 같이 존재)

 

 

원격 repo 와 Branch

따로 설정하지 않으면 기본적으로 로컬 repo의 브랜치 명과 같게 원격 repo의 브랜치명이 생성되어 tracking됩니다.

pull과 push는 결국 특정 branch에 있는 commit을 연결되어있는 branch에 가져오는 것입니다.

로컬 repo를 원격 repo에 push을 하면 다음과 같이 됩니다.

로컬 repo에서 진행되었던 작업이 원격 repo의 branch에 push 되면서 원격과 로컬의 repo가 같아지게 됩니다.

 

 

*요약*

협업할 때 다음 단계를 따릅니다.

1. Issue : 역할 분배, 기능 추가, 버그 리포트
2. branch: 각자 맡은 작업을 진행합니다. 기능별로 이름을 붙여줍니다.
3. merge: 갈라져서 작업했던 것들을 다시 메인 브랜치에 합칩니다.

각 과정을 좀 더 살펴보겠습니다.

Issue는 누가 작업할지 정하고, 기능을 추가하고 버그리포트 등을 할 수 있습니다.

branch는 작업할 공간을 나눕니다. 이때 기능별로 브랜치에 이름을 만들어줍니다. 작업할 브랜치로 바꾸는 것을 체크아웃이라고 하며 체크아웃된 브랜치에만 commit이 반영됩니다. 작업을 끝낸 브랜치는 삭제하여 헷갈리는 것을 방지합니다.

merge는 각 브랜치에 commit된 작업들을 특정 브랜치에 합치는 것을 뜻합니다. 이때 merge conflict(병합 충돌)이 발생할 수 있습니다. 이는 merge하는 과정에서 같은 파일이 수정된 부분이 있으면 발생합니다. 우리는 이때 반영할 파일을 선택하거나 직접 수정에 커밋할 수 있습니다.

현업에서는 사용자가 보는 브랜치가 있고 개발형 브랜치가 있다. 작업한 내용을 모두 모아놓은 것이 개발형 브랜치로 여기서 오류나 문제점을 확인하고 최종적으로 검토를 해서 사용자가 보는 브랜치로 merge합니다.

 

tracking 한다는 것은 로컬 repo와 원격 repo의 특정 branch를 연결해주는 것을 의미합니다.

 

push와 pull은 기본적으로 tracking되어 있는 브랜치를 기준으로 commit 내역을 반영합니다.

 

 

★ 키워드 ★

issue  /  branch  /  merge  /  merge conflict  /  원격 repo  /  로컬 repo  /  clone  /  협업하기 위한 단계