GitHub 내에서 협업하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 협업을 증진하는 조직 구조를 구축할 수 있습니다.
  
• GitHub 저장소의 가장 자주 방문하는 섹션을 나열할 수 있습니다.
  
• GitHub에서 소스 코드 옆에 있는 협업 기능을 설명할 수 있습니다.
  

GitHub 저장소 둘러보기

Git 명령어를 살펴보기 전에 먼저 GitHub의 구조와 팀과 협업하는 데 해당 구조가 팀과 협업하는 데 어떻게 도움이 되는지 알아보겠습니다.

저장소는 GitHub의 가장 기본적인 요소입니다. 프로젝트 폴더라고 생각하면 가장 쉽습니다. 그러나 노트북의 일반 폴더와는 달리 GitHub 저장소는 다른 사용자와 협업할 수 있는 간단하고 강력한 도구도 제공합니다.

저장소에는 프로젝트와 관련된 모든 파일(문서 포함)이 포함되어 있으며 각 파일의 업데이트 내역이 저장됩니다. 단순히 호기심이 많든 주요 기여자이든, 저장소를 둘러보는 방법을 아는 것은 필수적입니다!

GitHub 조직 설정하기

효과적인 계획은 누가 누구인지 이해하는 것에서 시작됩니다. GitHub에서 팀과 조직을 설정할 경우 협업 과정이 훨씬 원활해질 수 있습니다.

GitHub에 가입하면 자동으로 사용자 계정이 제공됩니다. 사용자 계정에 대한 권한은 매우 간단합니다. 특정 저장소에 공동 작업자로 사용자를 추가할 수 있습니다. 

조직 계정은 저장소 권한에 대한 보다 세분화된 관리 기능을 제공합니다. 사용자를 위해 사람들로 팀을 만든 다음 해당 팀에게 특정 저장소에 대한 액세스 권한을 부여합니다.

권한(예: 읽기, 쓰기 또는 관리자)은 팀 수준에서 할당할 수 있지만 사용자별로도 할당할 수 있습니다.

팀은 GitHub의 강력한 기능으로, 회사의 실제 팀 구조를 기반으로 구성되거나 사용자의 지정된 역할에서 벗어날 수 있는 스킬, 관심사 및 전문 지식을 기반으로 임시 항목을 구성할 수 있습니다.

GitHub의 저장소에는 많은 정보가 있습니다. 처음으로 중요하게 다룰 섹션은 Code(코드), 문제(문제), Pull Requests(풀 요청), Actions(작업) 및 Projects(프로젝트)입니다.

저장소에 있는 코드

코드 보기는 저장소에 포함된 파일을 찾을 수 있는 곳입니다. 이러한 파일에는 프로젝트 코드, 문서 및 기타 중요한 파일이 포함될 수 있습니다. 또한 이 보기를 프로젝트의 루트라고 부릅니다. 이러한 파일에 대한 모든 변경 사항은 Git 버전 관리를 통해 추적됩니다.

저장소를 방문할 경우 코드 보기가 자동으로 기본 브랜치를 표시합니다. 저장소를 만들 때 기본 브랜치는 메인이라고 하지만 다른 이름을 원할 경우 변경할 수 있습니다. 드롭다운에서 브랜치를 선택하여 원격으로 푸시된 브랜치를 표시할 수도 있습니다.

프로젝트 토론에 문제 사용하기

포럼과 마찬가지로 Issues(문제)는 GitHub 저장소에 바로 통합된 스레드 토론을 나타냅니다. 버그 및 기능 요청을 추적하고 특정 팀 구성원에게 할당할 수 있습니다. 토론과 협업뿐만이 아니라 지역 사회의 참여까지도 장려하기 위해 고안되었습니다.

문제는 간단하고 경미하며 GitHub의 다른 강력한 기능과 함께 사용되어야 합니다. 함께 사용하면 문제가 다른 문제, 풀 요청, 라벨, 마일스톤 및 프로젝트로 연결되는 링크를 만듭니다.

문제는 순전히 토론에 기반을 두고 있습니다. 문제의 결과로 실제로 수정되는 것은 없습니다.

풀 요청

Pull Request(풀 요청)는 두 개의 브랜치를 비교하는 것을 의미합니다. 일반적으로, 해당 비교는 메인 브랜치(프로덕션 코드가 있는 브랜치)와 개발에서 코드에 사용되는 또 다른 브랜치 사이의 비교입니다. 풀 요청은 코드에 대한 변경 사항을 나타냅니다. 작성자가 다른 브랜치에 통합하고자 하는 브랜치에 만들어진 파일을 추가, 수정 또는 삭제하는 것을 의미할 수 있습니다(즉, 일반적으로 프로덕션 코드에서). 풀 요청 내에서 수행되는 작업은 저장소의 문제에서 빈번하게 초래됩니다.

풀 요청은 두 브랜치 간의 변경 사항에 대해 자세한 대화를 나눌 수 있는 장소이기도 합니다. Ali가 버그 수정을 제안하지만 실수로 버그 수정을 해결할 때 새 버그를 만든다고 가정해 보겠습니다. Sally는 이 작업을 보고, 새로운 문제를 식별하는 Ali에게 빠르게 의견을 보낼 수 있으며, 문제를 직접 해결하거나 병합하기 전에 Ali가 빠른 수정 작업을 할 수 있는 기회를 제공할 수 있습니다.

풀 요청으로 코드 검토를 용이하게 하고 자동화된 테스트 상태를 확인하여 더 나은 소프트웨어를 작성할 수 있습니다. 이 부분을 간과해서는 안 됩니다. 풀 요청은 코드를 비교하고, 해당 코드에 대한 대화를 위한 플랫폼을 제공하며, 철저한 코드 검토를 장려하고, 다양한 통합 기능(테스트 포함)과 원활하게 작동합니다. 풀 요청은 GitHub에서 공동 작업의 가장 효과적인 기능 중 하나입니다.

작업

GitHub Actions(작업)를 사용하면 GitHub 저장소에서 직접 맞춤형 소프트웨어 개발 수명 주기 워크플로를 만들 수 있습니다. 개별 작업을 작성하고 이를 결합하여 맞춤형 워크플로를 만들 수 있습니다. 워크플로는 GitHub에서 모든 코드 프로젝트를 빌드, 테스트, 패키지, 릴리스 또는 배포하기 위해 저장소에서 설정할 수 있는 맞춤형 자동 프로세스입니다.

GitHub 작업을 통해 저장소에서 직접 유용한 CI/CD 기능을 구축할 수 있습니다. 또한 작업에서는 푸시, 문제 생성 또는 새 릴리스와 같은 GitHub 이벤트에서 워크플로를 실행할 수도 있습니다.

GitHub 작업을 사용하면 실시간 로그에 대한 색상 및 이모티콘 지원을 통해 워크플로가 실시간으로 실행되는 것을 확인할 수 있습니다. 이를 통해 성공 또는 CI/CD 구축 실패에 대해 공유할 특정 라인 번호를 식별하고 쉽게 강조할 수 있습니다.

프로젝트를 사용하여 업무 정리하기

문제 및 풀 요청은 매우 유용하며 다양한 협업 스타일에 효과적으로 활용할 수 있습니다. 프로젝트는 이를 하나로 통합하여 대규모 작업의 추적 및 계획을 보다 직관적으로 만듭니다.

프로젝트를 통해 간판 스타일 게시판을 사용하여 작업 카드, 문제 및 풀 요청과 함께 맞춤형 열을 사용하여 작업을 시각화할 수 있습니다. 프로젝트는 또한 저장소 또는 조직 수준에서 생성될 수 있으며, 따라서 여러 저장소로부터의 이슈 또는 풀 요청을 하나의 계획 페이지로 통합할 수 있습니다.