GitHub에서 팀과 작업하기
학습 목표
이 유닛을 완료하면 다음을 수행할 수 있습니다.
- GitHub 워크플로를 팀을 위한 효과적인 브랜칭 전략으로 전환할 수 있습니다.
- GitHub에서 병합 충돌을 해결할 수 있습니다.
- 단일 작업 단위를 나타내는 원자적 커밋을 생성할 수 있습니다.
효과적인 브랜칭 전략
독자적으로 작업하는 경우의 간단한 GitHub 플로 예제를 살펴보았으므로 워크플로가 팀에서는 어떤 식으로 작동하는지 상상해 보세요. 모든 브랜치, 커밋 및 풀 요청의 수는 팀의 인원과 개발 중인 작업의 수에 따라 늘어나게 됩니다. 많은 팀들이 이전에 이 작업을 수행했으며 시간이 경과됨에 따라 성공을 보여주는 패턴이 있습니다.
일반적으로 브랜치는 수명이 짧아야 하며, 기능을 수행하기 위해 생성해야 하고, 병합 후 삭제해야 합니다. 브랜치를 단기적으로 이용함으로써 혼란을 막고 최신 코드를 유지하며 개발자는 프로젝트를 반복적으로 개선할 수 있습니다.
장기간 사용되는 브랜치는 의도적으로 사용하지 않을 경우 문제가 발생할 수 있습니다. 수명이 긴 브랜치는 개발 브랜치에 적합하거나 배포 수준의 코드가 여러 개 필요한 다른 상황에 적합할 수 있습니다. 장기간 사용되는 브랜치의 문제 대부분은 개발자가 각 브랜치의 최신 버전을 가지고 있지 않고, 불필요한 병합 충돌, 혼란 및 작업을 생성하는 것에서 초래됩니다. 더 복잡한 브랜칭 워크플로가 올바른 해결책으로 간주될 수 있지만, 종종 너무 복잡한 GitHub 플로와 더 간단한 GitHub 플로가 더 효과적으로 작동합니다.
다음은 팀 브랜칭에 대해 질문할 몇 가지 사항입니다.
- 어떤 브랜칭 전략을 사용할 건가요?
- 주로 사용하거나 배포되는 코드는 어떤 브랜치인가요?
- 브랜치에 명명 규칙을 사용할 것인가요?
- 라벨과 할당인은 어떻게 사용하나요?
- 마일스톤을 사용할 것인가요?
- 프로젝트 게시판(프로젝트)을 사용할 것인가요?
- 문제 또는 풀 요청에 필요한 템플릿/요소가 있나요(예: 배송 체크리스트)?
- 풀 요청에 대한 승인은 어떻게 표시되나요?
- 누가 풀 요청을 병합할 것인가요?
브랜칭의 이점은 안전한 장소에서 변경 사항을 적용할 수 있는 것과 풀 요청으로 검토 및 테스트를 수행할 수 있다는 것입니다. 팀이 브랜칭에 대해 기대하고 있는 것을 결정하게 되면 가볍고 학습하기 쉽도록 유지하고 협업에 중점을 두세요.
병합으로 인한 충돌 해결
팀과 협업할 경우(단독으로 일할 경우에도) 종종 병합 충돌을 생길 수 있습니다. 처음에는 병합 충돌이 위협적일 수 있지만 실제로 이를 해결하는 것은 매우 쉽습니다.
병합 충돌을 만들고 무슨 일이 일어나는지 살펴보겠습니다.
충돌하는 커밋이 있는 다중 브랜치 만들기
병합 충돌은 동일한 파일의 동일한 섹션에 대해 여러 개의 커밋이 있을 경우 발생합니다. 충돌을 해결하기 위해 충돌을 설정해 보겠습니다.
- 메인에서 새 브랜치(new-branch-1)를 만들고 README.md 파일을 변경한 다음 풀 요청을 만듭니다.
- 다음 명령을 입력합니다.
git checkout -b new-branch-1 - 저장소에 있는 README.md 파일을 변경합니다. 변경한 행을 기록해 둡니다.
- New-branch-1에서 다음과 같이 변경 사항을 추가하고 커밋합니다.
- 다음 명령을 입력합니다.
git add README.md - 다음 명령을 입력합니다.
git commit -m "Changes to the README"
- 다음 명령을 입력합니다.
- 다음 명령을 입력합니다.
일반적인 실무에서는 메인에 직접 커밋하는 것을 권장하지 않지만 빠르게 병합 충돌을 일으키기 위해 커밋하는 것입니다.
- 원격 저장소로 브랜치 푸시합니다.
git push -u origin new-branch-1 - GitHub를 열고 이 커밋에 대한 풀 요청을 생성합니다.
- 다음 브랜치 및 풀 요청을 만들려면 메인으로 돌아갑니다.
git checkout main - 다음에 따라 새 브랜치(new-branch-2)를 만들고, 동일한 파일을 변경하고 풀 요청을 생성합니다.
- 다음 명령을 입력합니다.
git checkout -b new-branch-2 - README.md 파일의 같은 행에 변경 사항을 적용합니다.
- 다음 명령을 입력합니다.
git add README.md - 다음 명령을 입력합니다.
git commit -m “More changes to the README” - 다음 명령을 입력합니다.
git push -u origin new-branch-2 - GitHub에서 풀 요청을 생성합니다.
- 다음 명령을 입력합니다.
한 개의 풀 요청 병합하기
지금까지는 어느 한 브랜치에도 병합 충돌이 나타나지 않았습니다. GitHub에서 첫 번째 풀 요청(new-branch-1에서)을 병합해 보세요.
다른 브랜치의 충돌 해결
new-branch-1의 풀 요청을 병합한 후 new-branch-2에서 풀 요청으로 이동합니다.
병합 충돌이 있는 것을 알 수 있습니다! 당황하지 마세요. 해결할 수 있습니다. 병합 충돌이 얼마나 복잡한지에 따라 GitHub의 브라우저에서 충돌을 해결하도록 선택할 수도 있고 로컬에서 해결해야 할 수도 있습니다.
로컬에서 이를 해결하려면 메인을 브랜치로 병합하고 병합을 완료하기 전에 충돌을 해결해야 합니다.
- 충돌이 있는 브랜치를 체크아웃합니다.
git checkout new-branch-2 - 로컬 저장소의 최신 상태 여부 확인합니다.
git pull - 기능 브랜치로 메인을 병합합니다.
git merge origin/main원격 추적 브랜치를 병합하고 있지만 메인의 로컬 사본은 병합하지 않았습니다. 이는 풀 명령이 원격 브랜치와 현재 브랜치를 업데이트했지만 메인을 업데이트하지 않았기 때문입니다. - 충돌이 있는 것을 확인했다면 괜찮습니다!
git status를 입력하여 충돌이 있는 파일을 확인합니다. 충돌이 있는 파일은Unmerged Paths(병합하지 않은 경로) 아래에 나열됩니다. - 텍스트 편집기에서 해당 파일을 열고 충돌 병합 마커를 찾습니다. (
<<<<<<<,=======,>>>>>>>) - 두 브랜치의 코드 버전이 모두 존재하며 다른 브랜치를 유지하고 삭제할 코드를 선택합니다. Git에서 만든 병합 충돌 마커를 삭제하고 변경 사항을 저장해야 합니다.
- 병합 충돌을 해결하기 위해 저장된 변경 사항을 추가하고 커밋합니다.
- 다음 명령을 입력합니다.
git add README.md - 다음 명령을 입력합니다.
git commit -m "Commit to resolve merge conflict"
- 다음 명령을 입력합니다.
- 원격으로 기능 브랜치를 푸시합니다.
git push - GitHub의 풀 요청으로 돌아갑니다. 이제 풀 요청에는 충돌이 없습니다.
- 풀 요청을 병합합니다.
이제 해당 브랜치를 완료하면 GitHub에서 삭제한 다음 git checkout main 및 git pull 명령을 사용하여 로컬 저장소를 동기화합니다.
원자적 커밋 작성하기
원자적 커밋을 제작하는 것은 프로젝트의 읽기 쉽고 유익한 내역을 만드는 데 중요한 부분입니다.
완벽한 세상이라면 여러분은 내역에 어떤 것도 보거나 바꿀 필요가 없습니다. 그러나 우리는 완벽한 세상에 살고 있지 않습니다. 그 때문에 버전 관리를 통해 필요한 경우 변경 내역을 살펴볼 수 있습니다. 각 커밋은 작은 논리적 변경 단위여야 하며 저장소에 대한 사례를 전달해야 합니다.
명령어를 연습하여 git add --patch(줄여서 gitadd -p) 원자적 커밋을 만들어 보겠습니다. 이 명령을 사용하면 파일의 여러 부분을 스테이징 영역에 추가하여 진정한 논리적 변경 단위인 커밋을 수행할 수 있습니다.
- bigFile.md를 컴퓨터에 다운로드합니다. (마우스 오른쪽 버튼을 클릭하고 Save Target As(다른 이름으로 대상 저장)을 선택해야 할 수 있습니다.)
- GitHub에서 bigFile.md를 best-repo-ever 저장소에 있는 메인 브랜치에 업로드합니다.
- Upload files(파일 업로드)를 클릭합니다.
- 컴퓨터에서 bigFile.md를 선택합니다.
- Commit directly to the main branch(메인 브랜치로 바로 커밋하기)를 선택합니다.
- Commit changes(변경 사항 커밋하기)를 클릭합니다.
- 로컬 메인 저장소가 최신 상태인지 확인합니다.
- 다음 명령을 입력합니다.
git checkout main - 다음 명령을 입력합니다.
git pull
- 다음 명령을 입력합니다.
- Git으로 추적하는 내용을 확인합니다.
git status커밋할 항목이 없다는 것을 알 수 있습니다. - bigFile.md의 행 1 및 행 100번째를 변경합니다. (변경 사항은 중요하지 않습니다.)
- 스테이징 영역으로 --patch 플래그(
git add -p)를 사용하여 일부 파일의 일부를 이동합니다. -
y를 눌러 변경 단위를 나타내는 Git 언어인 헝크를 실행합니다.
헝크에 대해 어떤 옵션이 있는지 궁금하신가요? ?를 사용하여 헝크 위의 옵션 목록을 볼 수 있습니다.
