github projects teams
이 GitHub 튜토리얼에서는 GitHub 프로젝트, 조직 및 팀, 리포지토리 포크, 이슈 및 프로젝트 마일스톤, GitHub Wiki 등과 같은 개념을 설명합니다.
GitHub에 대한 일련의 자습서의 이전 자습서에서 개발자가 플랫폼을 활용하여 프로젝트 관련 아티팩트 및 버전 제어를 동일하게 저장하는 방법을 살펴 보았습니다. 또한 풀 요청, 병합, 분기 및 보호 분기에 대한 개념도 살펴 보았습니다.
그게 다가 아닙니다. 이 튜토리얼에서는 더 깊이 파고 들어 GitHub가 개발자를 위해 할 수있는 다른 작업을 알아 봅니다.
=> 여기에서 완벽한 GitHub 교육 가이드를 확인하십시오.
여기에 우리가 집중할 것입니다.
- 조직 및 팀 만들기
- 저장소 포크
- 이슈 및 프로젝트 마일스톤 생성
- 프로젝트 게시판 만들기
- GitHub Wiki 생성
학습 내용 :
조직 및 팀 만들기
이 섹션의 선구자로서 GitHub는 다음 3 가지 유형의 계정을 제공합니다.
- 개인 사용자 계정 공개 및 비공개 저장소를 무제한으로 생성하고 공동 작업자를 초대 할 수도 있습니다.
- 조직 계정 이는 주로 공유 계정의 개념이며이 섹션에서 더 많이 볼 것입니다.
- 기업 계정 GitHub를 사용하는 사용자를 위해 내부적으로 정책을 관리하는 회사에서 사용합니다. 일반적으로 GitHub Enterprise의 온-프레미스 버전에서 사용됩니다.
1 부에서는 해당 사용자가 저장소의 단일 소유자 인 단일 개인 계정을 사용하여 저장소를 만드는 방법을 살펴 보았습니다. 이는 3 ~ 9 명 또는 더 많은 인원이있는 소규모 스크럼 팀에 적합하거나 단일 프로젝트에 대한 저장소를 생성하는 것이 좋습니다.
그러나 실행을 위해 여러 저장소와 여러 팀이 액세스해야하는 대규모 Github 프로젝트가 있다면 어떻게 될까요? 여기서는 GitHub Organization이 하나의 대규모 프로젝트에 대해 여러 저장소를 그룹화하는 데 어떻게 도움이되는지 살펴 봐야합니다. 따라서 여러 저장소 / 팀이 관련되므로 소유자도 여러 명있을 것입니다.
새 조직 생성을 시작하려면 + 오른쪽 상단에서 새로운 조직.
그에 따라 계획을 선택하십시오. 지금은 무료 플랜을 사용할 것입니다. 오픈 소스 팀.
조직에 대한 세부 정보를 입력 한 다음 다음.
조직에 구성원을 추가하고 설치를 완료하십시오.
다음 단계는 프로젝트 요구 사항에 따라 저장소 생성을 시작하고 동일한 팀을 추가하는 것입니다.
클릭 할 수도 있습니다. 누군가 초대 방금 만든 조직에 구성원을 추가합니다. 구성원이 추가되면 역할을 구성원 또는 소유자로 지정할 수도 있습니다. 이렇게하려면 사람들 탭 및 선택 역할 변경 그 회원을 위해.
지금은 사용자 1 명을 소유자로, 다른 사용자를 회원으로 유지하겠습니다. 따라서 소유자는 여러 저장소를 생성하고 각 저장소에 팀을 할당 할 수 있습니다.
저장소를 만들기 전에 먼저 팀을 만들어야합니다. 다음으로 이동 팀 탭을 클릭하고 새로운 팀.
UI 팀과 미들웨어 팀의 두 팀을 만들 것입니다.
클릭 팀을 만듭니다. 팀이 생성되면 아래와 같이 팀에 구성원을 추가 할 수 있습니다.
마찬가지로 다른 팀을 만들고 구성원을 추가합니다. 이제 2 개의 팀이 있음을 알 수 있습니다.
리포지토리를 생성 해 보겠습니다. 따라서 시나리오로서 이제 우리는 저장소 2 개 즉, 하나는 UI 관련 코드를 보유하고 다른 하나는 미들웨어 코드를 보유합니다. 그에 따라 팀이 배정됩니다.
다음으로 이동 저장소 탭을 만들고 새 저장소 .
클릭 저장소 만들기 단추. 다음은 저장소에 대한 UI 팀 액세스를 제공하는 것입니다.
다음으로 이동 팀 탭. 클릭 UI 팀 그리고 저장소 탭. 각 팀을 클릭하고 저장소를 다시 추가하십시오. 저장소 탭.
저장소 이름을 입력하여 저장소를 추가하십시오.
또한 쓰기 권한 팀 구성원의 경우이 저장소로 이동합니다. 즉, 팀 구성원은이 저장소를 읽고, 복제하고, 푸시 할 수 있습니다.
마찬가지로 위의 단계를 수행하여 미들웨어 저장소를 다른 팀에 추가하십시오. 따라서 이제 우리는 그 안에 저장소가있는 조직과 팀도 가지고 있습니다. 팀 구성원은 액세스 권한이있는 저장소를 복제하고 동일한 작업을 수행 할 수 있습니다.
GitHub 포크
리포지토리를 포크하고 원래 리포지토리와 동기화 상태를 유지합니다.
이전 섹션과 이전 자습서에서 리포지토리가 생성되고 여기에 소스 코드가 추가되는 것을 보았습니다. 이제 원래 저장소가 수행 할 장소가 아닐 때 팀이 일부 코드 변경 사항을 테스트하려면 어떻게해야합니까?
원본 저장소를 그대로 유지하여 코드 변경 사항을 실험하려면 복사본을 만들어야합니다. 이것은 ... 불리운다 GitHub 포크 . 포크를 생성하려면 조직이 아닌 개인 계정에서 생성 된 저장소로 이동합니다. 클릭 포크 오른쪽 상단에 있습니다.
원래 저장소를 포크해야하는 계정을 선택하십시오. 이 경우 저장소를 분기 할 조직 계정을 선택합니다.
저장소는 이제 다음과 같이 분기됩니다. Demo-Proj-Org / Demo_Project_Repo_VN . 따라서 코드를 사용한 모든 실험은 원래 저장소가 아닌 분기 저장소에서 수행 할 수 있습니다.
원래 저장소에서 변경이 수행 된 경우 분기 된 저장소는 동조 . 명령 줄 옵션을 사용하여 분기 된 저장소를 동기화 할 수 있지만 풀 요청을 만드는 것이 더 간단한 옵션입니다.
원래 리포지토리의 파일이 변경되었다고 가정하면 계속해서 Pull Request를 생성합니다.
링크를 클릭하십시오 포크 간 비교.
원래 저장소로 헤드를 선택하고 그림과 같이 분기 저장소로 기본을 선택하고 풀 요청을 생성합니다.
클릭 풀 요청을 병합하고 병합을 확인합니다.
변경 사항은 분기 된 저장소에 나타나며 원래 저장소와 동기화됩니다.
GitHub 문제 및 프로젝트 마일스톤
일반적으로 모든 프로젝트에서 진행 과정의 일부로 작업, 결함, 개선 사항 등을 추적해야합니다. GitHub의 문제를 사용하여 위에서 언급 한 모든 문제를 프로젝트 보드와 함께 추적 할 수 있습니다.
문제가있는 경우 pull 요청이 병합 될 때 자동으로 닫힐 수 있도록 동일한 항목을 pull 요청과 연결할 수 있습니다. 또한 미해결 이슈가있는 경우 다른 리포지토리로 전송할 수도 있습니다. 이 섹션에서는 이슈가 어떻게 사용될 수 있는지에 대해 더 많이 볼 것입니다.
이슈 및 마일스톤 생성
저장소의 기본 페이지로 이동하여 이슈 탭. 클릭 새로운 문제.
작업 할 공동 작업자에게 할당하고 개선 사항으로 구별 할 레이블을 추가합니다. 좋은 관행은 또한 획기적 사건 제기 된 문제의 진행 상황을 추적합니다.
클릭 새로운 문제를 제출하십시오.
문제 요약이 표시됩니다. 문제 번호는 나중에 참조 할 # 11입니다.
문제를 다른 저장소로 전송할 수도 있습니다. 이를 수행하는 옵션은 하단에 있습니다. ‘이체 문제’.
을 추가하다 마감일 이정표 – R1. 저장소의 기본 페이지에서 이슈 탭을 클릭하고 마일스톤 .
편집하다 마일스톤 R1에 대한 세부 정보를 입력하고 기한을 추가합니다. 완료되면 변경 사항을 저장하십시오.
통합 테스트는 무엇입니까?
Milestone R1에는 이제 2 개의 미해결 문제가 있으며 완료율도 볼 수 있습니다.
이 마일스톤에 대해 전달 될 문제를 보려면 마일스톤 R1을 클릭하십시오. 문제를 위아래로 이동하여 문제의 우선 순위를 다시 지정할 수도 있습니다.
필터 문제
Open / Close 상태이고 여러 공동 작업자에게 할당 된 여러 문제가 있다고 가정합니다. 특정 기준에 기반한 문제를 검색하는 것은 매우 중요합니다.
예를 들어 사용자에게 할당 된 모든 문제, 열린 상태의 모든 문제 등. GitHub는 문제를 필터링 할 수있는 검색 옵션을 제공하며 풀 요청도 제공합니다.
문제 탭으로 이동 필터 상자에 다음과 같이 기준을 입력합니다.
예를 들어, 진행 중 상태이고 공동 작업자에게 할당 된 모든 미해결 문제입니다.
유형 : 문제 상태 : 양수인 열기 : vniranjan2512 마일스톤 : R1 레이블 : 향상
Pull Request에 이슈 연결
Pull Request가 특정 키워드 및 문제 번호로 참조되고 병합되면 문제가 자동으로 종료됩니다. 커밋이 키워드 및 이슈 번호로 참조 되더라도 이슈는 종결됩니다.
키워드는 무엇이든 될 수 있습니다. 닫기, 닫기, 수정, 수정, 해결, 해결합니다.
예를 들어 풀 요청 또는 커밋 메시지 언급 # 11을 닫습니다.
풀 요청을 생성하고 메시지에 표시된대로 키워드 및 참조 번호를 언급합니다. 클릭 풀 요청을 생성하고 병합합니다.
풀 요청 병합시 문제가 자동으로 종료됩니다. 약간의 자동화가 확실히 필요합니다.
소스 코드에서 새 이슈 생성 또는 열기
코드 변경에 대해 새로운 이슈를 열 수 있습니다. 이를 통해 코드 변경 줄의 URL이 문제에 추가됩니다. 코드의 비 편집 모드에서 코드 줄 옆에있는 3 개의 점 (…)을 클릭하고 신간 참조 .
문제 세부 정보가 업데이트되었습니다.
핀 문제
문제를 더 쉽게 찾을 수 있도록 문제를 고정하고 생성되고 있습니다.
문제를 열고 문제의 오른쪽 하단에서 핀 문제.
이제 문제가 문제 목록 위에 추가됩니다.
노트 : 언제든지 최대 3 개의 문제를 고정 할 수 있습니다.
GitHub 프로젝트 보드
GitHub의 프로젝트 게시판은 문제를 시각화하는 쉬운 방법을 제공합니다. 프로젝트 진행 상황을보고 아직 시작되지 않은 문제, 진행중인 문제 및 완료된 문제를 볼 수 있습니다.
GitHub의 프로젝트 보드는 미리 정의 된 워크 플로가 있고 사용자 정의 할 수있는 Kanban 템플릿을 기반으로 만들 수 있습니다. 예제는 사용자 계정을 기반으로 생성 된 보드를 보여줍니다.
저장소의 기본 페이지에서 프로젝트 탭을 만들고 새로운 프로젝트.
위에서 볼 수 있듯이 프로젝트 보드는 다음을 수행하는 데 도움이됩니다.
- 작업 정렬
- 프로젝트 계획
- 워크 플로우 자동화
- 진행 상황 추적
- 공유 상태
- 프로젝트 닫기
기본 Kanban 템플릿이있는 새 프로젝트 보드.
보드는 워크 플로우로 생성됩니다. 추가 워크 플로 열을 클릭하여 추가 할 수도 있습니다. + 열 추가.
워크 플로를 자동화 할 수도 있습니다. 예를 들어 새로운 이슈가 생성되면 바로 추가 할 수 있습니다. 할 일 상태. 선택 자동화 관리 그 상태에 대한 옵션.
확인란을 선택하십시오. 새로 추가 자동화 업데이트를 클릭하십시오. 따라서 새로운 이슈가 생성되면 이슈에 대해 선택된 프로젝트가 자동으로 할 일 상태. 또한 기존 문제를 상태로 끌어다 놓은 다음 한 상태에서 다른 상태로 이동할 수 있습니다.
열에 해당 열의 문제에 대한 몇 가지 중요한 정보를 제공 할 수 있도록 메모를 추가 할 수도 있습니다. 클릭 + 서명하고 메모를 추가합니다.
클릭 더하다.
문서 용 GitHub Wiki
모든 프로젝트에서 매우 중요한 활동 중 하나는 전체 팀이 사용할 저장소에 대한 문서를 만들고 유지하는 것입니다. GitHub 리포지토리는 GitHub Wiki를 사용하여 이러한 문서를 생성 할 수 있도록 지원합니다. 따라서 프로젝트 및 사용에 대한 모든 정보를 위키에서 캡처 할 수 있습니다.
Wiki는 GitHub의 공용 저장소에서 무료로 사용할 수 있습니다. Wiki는 오픈 소스 마크 업 라이브러리를 사용합니다. 위키를 작성하는 동안이 라이브러리를 사용하는 방법을 살펴 보겠습니다.
리포지토리에 대한 Wiki 지원 활성화
저장소의 메인 페이지에서 설정 탭하고 위키 옵션은 풍모 부분.
GitHub Wiki 만들기
저장소의 기본 페이지에서 위키 탭. 클릭 첫 페이지를 만듭니다.
제목을 입력하고 Wiki에 텍스트를 추가합니다. 또한 Markdown 지원을 사용하여 서식 옵션을 사용할 수 있습니다. 클릭 페이지 저장 일단 완료되었습니다.
위의 내용에서 #은 제목 1, ##은 제목 2, ###은 제목 3입니다. *는 정렬되지 않은 리스팅에 사용됩니다. 미리보기는 아래와 같습니다.
에 위키 탭 클릭 + 사용자 지정 바닥 글을 추가합니다.
콘텐츠를 추가하고 페이지를 저장합니다.
저장된 Wiki를 열면 바닥 글이 표시됩니다.
사이드 바 추가
위키 탭에서 + 사용자 정의 사이드 바를 추가하십시오.
안전한 무료 YouTube to mp3 변환기
사이드 바에 콘텐츠를 추가하고 페이지를 저장합니다.
위키를 열면 사이드 바가 표시됩니다.
위키 기록보기
기록에서 변경 한 사람, 커밋 메시지 및 변경 날짜를 볼 수 있습니다.
Wiki를 열고 페이지를 편집하십시오. 클릭 페이지 기록, 오른쪽에.
변경 사항을 보려면 해시를 클릭하십시오. 개정을 선택하여 변경 사항을 비교하고 최신 개정의 변경 사항을 되돌립니다. 클릭 변경 사항을 되돌립니다.
변경 사항은 이전 버전으로 되돌아갑니다.
노트 : 위키 편집 권한에 따라 변경 사항을 되돌릴 수 있습니다.
결론
GitHub 시리즈의 1 부 및 2 부에서는 버전 제어 활동, 리포지토리 생성, 풀 요청, 브랜치, 코드 검토, 조직 및 팀, 리포지토리 포크, 레이블, 마일스톤, 문제, GitHub 프로젝트, Wiki에 대해 살펴 보았습니다.
다음 자습서에서는 릴리스 생성, Jira와의 통합 및 Git 명령 개발자가 변경 사항을 GitHub 저장소에 푸시하기 전에 도움이됩니다.
모든 개발자가 GitHub에 대한이 실습 방식이 프로젝트에서 유용하다는 것을 알게되기를 바랍니다.
=> 독점적 인 GitHub 교육 자습서 시리즈를 보려면 여기를 방문하십시오.
추천 도서
- 소프트웨어 프로젝트의 위험 유형
- 개발자를위한 GitHub 자습서 | GitHub 사용 방법
- DevOps에서 Eclipse와 함께 JAVA 프로젝트 용 Microsoft TFS를 사용하는 방법
- JIRA Agile Tutorial : Agile 프로젝트 관리를 위해 JIRA를 효과적으로 사용하는 방법
- 수동 및 자동화 프로젝트에서 테스트 계획은 어떻게 다릅니 까?
- 셀레늄 어설 션 예제-프로젝트의 실제 응용
- 온 사이트-소프트웨어 테스트 프로젝트의 오프 쇼어 모델 (및이를 작동시키는 방법)
- Git vs GitHub : 예제를 통해 차이점 탐색