대부분의 sw프로젝트는 혼자가 아닌 여러명의 개발자들의 협업으로 이루어진다.
Git은 하나의 프로젝트를 여러 명이서 작업할 수 있는 환경을 제공하므로 협업에 필수적으로 사용된다.
이번 글에서 git 협업의 핵심인 branch의 개념 및 협업전략에대해 알아보겠다.
Commit이란: staging area에 tracked된 파일들을 저장소에 저장
커밋을 하면 커밋 객체가 생성된다.
HEAD: 해당 브랜치의 마지막 커밋을 의미. 모든 브랜치에 HEAD값이 존재.
Branch란
가지 또는 분기점을 의미. 쉽게 말해 기존 코드와 관계없는 개별적인 작업장!이라고 할 수 있다.
각각의 브랜치는 다른 브랜치의 영햐을 받지 않기 때문에, 여러 작업을 동시에(협업) 진행할 수 있는 것이다.
협업시 할때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 Pull Request과정을 거치고 완전하다 싶을때 Merge를 하여 작업을 한다.
전체적인 흐름은 이러하다.
★협업과정★
1.Issue 생성 & branch 생성
이와같이 issue생성 및 branch 생성까지 완료하였다.
issue제목과 branch명을 굳이 귀찮게 저렇게까지 적어야한다고 생각할 수 있다(나도 처음에 그랬지..)
다시한번 강조하지만 이건 개인 프로젝트가 아닌 "TEAM"프로젝트이다!!
그러므로 issue제목과 branch명은 팀끼리 convention(협약)을 정해서 정해진 규칙대로 적어주어야한다.
convention 적용 유/무에 따른 차이점을 내가 경험했던 예시로 설명하겠다.
한눈에 봐도 convention을 지키며 작성한 commit이 다른 팀원들이 봤을때 어떠한 작업을 한건지 이해도 쉽고, 혹시 오류가 생겼을때 수정도 쉽다! convention 규칙은 팀원들과 개발 시작 전 정해서 사용하여도 되고, 공통적으로 많이 쓰이는 방식을 따라 사용하여도 된다! Commit convetion 외에도, 코드 짤때 code convention, 주석 convention등 많은 규칙들을 사용할 수록 통일성 있고 깔끔한 개발을 할 수 있는것 같다!
2.Pull Request &review
사진관계상 과정이 다소 생략되었는데 설명을 하자면, 내가 만든 issue와 branch에서 작업을 마치고 git add , git commit , git push까지완료하였다고 하자.
이 코드는 내가 생성한 branch상에서만 반영되어있고 실제 프로젝트 코드인 main(혹은 develop)branch에는 반영되지 않았다. 그러므로 main과 merge해서 코드를 병합하는 과정이 필요한데 이 과정에서 팀원들에게 나 merge해도돼? 라고 승인을 받은 것이다.
왜냐고? 당연히 또 "TEAM"프로젝트이기 때문. 만약 팀원이 나랑 같은 코드를 수정했다면? 바로 충돌이 일어날 것이다.
이러한 사고를 방지하기 위해 위와같은 작업을 거친다.
3.Merge
다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다
예를 들어 master브랜치와 test 브랜치가 있다고 했을 경우,
**git merge test**를 하게되면
test브랜치에만 있던 코드가 master브랜치에 병합된다.
이상으로 협업관점에서의 git 사용법을 마치겠다.
뭔가 더 성장한 느낌..!
'Git' 카테고리의 다른 글
| [Git] conflict 충돌은 왜 발생할까? + 해결방법 (1) | 2024.09.12 |
|---|---|
| Git/Github 개념 및 사용법 (3) | 2023.11.23 |
