기초 지식 정리
1. branch
branch를 사용하지 않으면 로컬에서 작업 후 git push를 하기 전, 서버에 변경사항이 있는 경우 git pull로 원격 저장소의 변경사항(commit 내용)을 가져와야 한다. 이때 가져온(pull) 코드가 내가 수정하고 있는 코드와 동일하면 충돌(conflict)이 생겨 문제가 발생하게 된다. 같은 파일의 같은 코드를 수정한 경우 Git에서 로컬의 코드와 서버의 코드 중 뭘 골라야 할지 몰라서 고쳐달라는 오류 메시지가 뜨게 된다. 이런 상황에선 협업자와 어떻게 해결할지 결정해서 코드를 적절하게 수정해야 한다.
버전 관리 시스템에서 branch를 통해 원본의 복사본을 만들고 그 위에 개발을 진행할 수 있다. 원본에 직접 개발하지 않고 복사본(branch)에서 개발한 뒤 문제가 없다면 원본에 merge 하는 방식(Compare & Pull requests)으로 협업을 진행하게 된다.
git branch
git branch <branch name>
git branch -d <branch name>
git push origin -d <branch name>
git branch -a
git branch -r
git checkout <branch name>git branch로 어떤 branch가 생성돼 있는지 확인할 수 있고, 뒤에 만들고 싶은 branch 이름을 붙여 새로운 branch를 생성할 수 있다.
로컬에 있는 특정 branch를 삭제하고 싶을 땐 git branch -d 뒤에 삭제할 branch 이름을 붙이면 된다. branch에 병합되지 않은 변경사항이나 원격 저장소에 저장되지 않은 commit이 있는 경우에는 삭제가 불가능하다. -d option 대신 -D option를 사용해 강제로 삭제할 수도 있지만 이 경우 변경사항이 없어질 수 있기 때문에 주의해야 한다. 원격에 있는 특정 branch를 삭제하고 싶을 땐 git push origin -d 뒤에 삭제할 branch 이름을 붙이면 된다.
git branch 뒤에 -r option을 붙이면 원격 저장소에 있는 branch를 확인할 수 있고, -a option을 붙이면 모든(로컬 + 원격) branch를 확인할 수 있다.
다른 branch로 이동할 땐 git checkout 뒤에 이동하고 싶은 branch 이름을 붙이면 된다.
2. branch로 협업하기
- git init을 하고 최초 commit을 하면 한 개의 branch(default: main)가 기본으로 생성된다.
- 협업할 레포지토리를 만든 뒤 설정에서 collaborator에 팀원들을 초대해 접근(push, merge 등) 권한을 줘야 한다.
- 이후 초대를 받은 팀원이 clone을 통해 로컬에 원격 저장소의 파일을 복사한다.
- issue를 통해 새 branch를 만들어 각자 개발을 진행한다.
- main branch에 merge를 요청(pull requests)한 뒤 팀원들의 승인을 받아 merge 한다.
issue
혼자 개발할 땐 branch를 마음대로 만들어도 되지만, 팀원들과 프로젝트를 할 땐 branch를 생성할 때나 기능을 구현하려고 할 때 issues를 열어 알려야 한다. 이외에도 버그를 알린다거나 질문용으로 쓸 수도 있고, 해야 할 일과 설명을 적어 Asignees에 해당 일을 진행할 팀원을 지정한 뒤 팀원에게 이메일로 바로 알려줄 수도 있다.
pull requests
팀원들이 각자 로컬에서 개발한 코드를 자기가 작업하던 branch에 push 하고 나면, 다른 팀원들과 코드를 merge해야 한다. 이때 멋대로 merge하게 되면 팀원들의 코드와 충돌이 발생할 수 있고 팀에 민폐를 끼칠 수 있다.
그래서 보통은 push하고 compare & pull requests를 진행한다. branch를 비교했을 때 merge가 가능하면 아래처럼 초록색으로 Able to merge라고 뜬다.
제목이나 설명은 주로 주어진 틀이 있다. 보통은 제목 앞에 기능을 추가했을 땐 feature, 코드를 수정했을 땐 chore 등을 적는 방식을 쓰는데 자세한 건 팀원들과 정해야 한다. 설명에는 요약, 변경사항 등을 적고, 오른쪽 상단 Reviewers에 PR을 확인해 줄 팀원들을 추가한다. Asignees엔 보통 본인을 넣고, Labels엔 feature, chore 등을 넣게 된다.
Reviewers를 설정하지 않으면 아래처럼 뜨게 된다. base branch와 충돌이 없는 경우 바로 merge 할 수 있다. 팀 프로젝트를 진행할 땐 merge를 하기 전 팀원들이 PR에서 변경사항(commit)을 확인해 comment(승인, 수정 요구 등)를 날릴 수 있다. 아래에 Add rule을 통해 이 PR을 merge 하려면 최소 몇 명의 승인이 필요한지 결정할 수 있고, 조건을 만족하면 merge 할 수 있게 된다.
merge를 하게 되면 PR은 닫힌다. 이후 다른 팀원들은 pull을 통해 원격 저장소의 변경사항을 가져온 뒤 push를 할 수 있다.
3. fork
협업을 할 땐 branch를 사용하는 게 일반적이지만, fork로도 협업할 수 있다. fork는 Github에 있는 public 레포지토리를 그대로 복사해 내 레포지토리로 가져오는 것이다. 내 레포지토리에서 개발을 진행한 뒤 복사해 온 원본 레포지토리에도 적용시켜 달라고 PR을 날릴 수 있다.
이 방식으로 오픈소스에 기여할 수 있다고 한다. Google이나 에어비앤비 레포지토를 fork 한 뒤 코드를 추가하고 PR을 넣었는데 merge가 됐다면? 기여 성공 :)
4. Github와 Slack 함께 사용하기
slack은 업무 현업 메신저로, 많은 기업들이 프로젝트를 진행할 때 사용한다. 그냥 메신저 기능만 있는 건 아니고 각종 개발 도구들과 연동해 효율적으로 사용할 수 있다. Github와 연동하면 레포지토리에 변경사항(commit, PR)이 생겼을 때 알림이 오게 된다.
/github subscribe <계정 이름>/<레포지토리 이름>채널 채팅에 입력하면 slack과 Github를 연동하고 나서 레포지토리를 구독할 수 있다.
마무리
정리하면서 들으니까 생각보다 시간을 더 쓴 것 같다. 🥲
'오픈소스 기여'라는 말을 여러 번 봤는데 솔직히 어떻게 하는 건지 감도 안 왔는데 알게 돼서 좀 새롭다. 냅다 PR을 날리고 받아주면 기여한 거라니... 🤔 나중에 하나쯤은 해보고 싶다.
프로젝트를 진행하면서 새로 알게 되는 거나 모르는 게 있으면 가볍게 추가로 정리해 봐야겠다.
