github tutorial developers how use github
이 GitHub 자습서에서는 GitHub 란 무엇이며 리포지토리, 분기 및 풀 요청을 만드는 방법에 대해 설명합니다. 여기에는 분기 보호 규칙 및 충돌 해결이 포함됩니다.
GitHub 란?
GitHub는 개발자가 소스 코드를 저장 및 관리하고 소스 코드의 모든 변경 사항을 추적 및 제어하는 데 도움이되는 클라우드 서비스입니다.
간단히 말해서 GitHub는 프로젝트를 관리하고 소스 코드를 호스팅하고 검토 할 수있는 개발자를위한 것입니다. 이 시리즈에서이 모든 것을 살펴볼 것입니다.
이 GitHub 시리즈의 자습서 목록 :
튜토리얼 # 1 : 개발자를위한 GitHub 자습서 | GitHub 사용 방법 (이 튜토리얼)
튜토리얼 # 2 : 프로젝트 문서화를위한 GitHub 프로젝트, 팀, 포크 및 위키
튜토리얼 # 3 : 고급 Git 명령 및 GitHub 통합 자습서
튜토리얼 # 4 : GitHub REST API 자습서 – GitHub에서 REST API 지원
튜토리얼 # 5 : GitHub 데스크톱 자습서 – 데스크톱에서 GitHub와 공동 작업
튜토리얼 # 6 : TortoiseGit 자습서 – 버전 제어를 위해 TortoiseGit을 사용하는 방법
학습 내용 :
Git이란?
Git은 개발자의 컴퓨터에서 전체 소스 코드를 사용할 수있는 오픈 소스 버전 제어 시스템입니다. Git은 분기 및 병합을 수행 할 수있는 클라이언트 및 분산 버전 제어 시스템 (DVCS)이기도합니다.
GitHub 시작하기
GitHub를 시작하기 위해 다음 단계를 수행합니다.
- 프로젝트를 구성 할 저장소를 만듭니다.
- 브랜치 생성
- 파일을 변경하고 커밋합니다.
- 콘텐츠를 병합하려면 Pull Request를 생성합니다.
- 지점 보호
시리즈의 두 번째 부분에서는 조직, 팀, 이슈, 마일스톤, 포크, 릴리스 및 Wiki 생성과 같은 GitHub의 다른 기능도 살펴볼 것입니다.
GitHub 리포지토리 생성
GitHub 저장소에는 소스 코드, 문서, 이미지 등과 같은 프로젝트의 아티팩트가 포함됩니다. 데모 저장소를 만들고 사용하여 위의 모든 단계를 수행합니다.
Github.com에 로그인하고 새 저장소 생성 . 클릭 새로운 단추.
표시된대로 아래 repo 세부 정보를 추가하고 저장소 만들기 . 비공개 또는 공개로 액세스를 설정합니다. 이 액세스에 의존하는 기능이 거의 없으므로 공개로 설정하는 것이 좋습니다.
참고 : 리포지토리를 생성하는 사용자는 GitHub 리포지토리의 소유자입니다.
리포지토리는 README 파일로 생성됩니다.
GitHub 리포지토리에 공동 작업자 추가
우리는 팀이이 저장소에서 작업하기를 원합니다. 이를 위해 우리는 저장소에서 작업 할 공동 작업자를 초대해야합니다. 공동 작업자를 추가하려면 저장소의 기본 페이지로 이동하여 설정 상.
클릭 협력자 왼쪽 창에서 Github 계정이있는 공동 작업자를 추가합니다. 초대가 전송되고 공동 작업자는 초대를 수락해야합니다.
공동 작업자는 아래와 같이 추가됩니다. 나중에이 튜토리얼에서 코드를 병합하기 위해 생성 된 풀 요청에 대한 검토 자로 Collaborators가 추가되는 방법을 살펴 봅니다.
기본 C 수행 생략
README 파일을 열고 기본 커밋을 수행합니다. 클릭 편집 아이콘 파일 수정을 시작합니다.
파일을 수정하고 주석을 추가 한 다음 범하다 .
파일이 Github 리포지토리에 커밋 (변경 사항 저장)됩니다.
저장소 내부에 폴더 및 파일을 만드는 작업은 거의 없습니다.
폴더와 파일을 만들려면 : 클릭 새 파일 생성 저장소 수준에서 버튼을 클릭합니다. 아래에 표시된대로 디렉토리 이름 뒤에 /와 파일 이름을 입력합니다.
클릭 범하다 하단에. 폴더와 파일이 그림과 같이 생성됩니다. 따라서 파일과 폴더는 석사 주요 통합 브랜치이며 대부분 소프트웨어 릴리스를 빌드 할 수있는 브랜치입니다.
개발자는 일반적으로 별도의 분기에서 자신에게 할당 된 작업을 수행하고 변경 사항을 마스터 분기에 병합합니다. 예를 들어, 기능 개발 또는 버그 해결 또는 개선 작업 등을 위해 브랜치를 생성 할 수 있습니다. 따라서 브랜치를 생성하면 다른 브랜치를 방해하지 않고 작업이 격리됩니다.
다음 단계에서는 브랜치를 생성하고 코드를 검토하고 마스터 브랜치에 병합하기 위해 풀 요청을 정의하는 방법을 살펴볼 수 있습니다.
파일 이동
파일을 다른 폴더로 이동하려면 다음 단계를 수행하십시오. 예를 들어, rules.txt 파일을 doc 폴더로 이동합니다. 파일을 클릭하십시오.
아이콘을 클릭하여 파일을 편집하십시오.
경로 추가 문서/ 파일 앞에 rules.txt . 클릭 변경 사항 커밋.
이제 경로가 업데이트됩니다.
GitHub 브랜치 생성
저장소의 기본 페이지로 이동하여 입력하여 특색 그림과 같이 분기합니다. 클릭 분기를 만듭니다.
우리는 지금 특색 분기. 파일이 동일합니다. 이제 파일의 일부를 변경합니다. 특색 분기하고 풀 요청을 생성하여 변경 사항을 검토하고 코드를 석사 분기.
기능 분기에서 파일을 변경하십시오.
Src 폴더에서 Java 파일을 열고 코드를 추가하고 변경 사항을 커밋합니다.
GitHub 풀 요청 생성
이전 섹션에서 분기를 만들었습니다. 특색 파일을 약간 변경했습니다. 변경 사항은 석사 분기. 이를 위해 사용자가 검토 및 병합 할 특정 변경 사항을 제안하는 Pull Request를 생성해야합니다. 석사 분기.
Pull Request를 생성하면 소스 브랜치와 타겟 브랜치의 차이점이 표시되며 충돌이있는 경우 해결해야합니다.
클릭 비교 및 풀 요청 저장소의 메인 페이지에서.
두 분기의 변경 사항을 병합 할 수 있음을 알 수 있습니다. 클릭 Pull Request를 생성합니다.
클릭 풀 요청 병합 과 확인 병합을 완료합니다.
변경 사항이 석사 분기. 첫 번째 Pull 요청이 성공적으로 완료되었습니다.
풀 요청 및 코드 검토로 검토 자 지정
Github에는 CODEOWNERS 파일을 사용하는 좋은 기능이있어 저장소에서 소스 코드를 담당하는 사람을 선택할 수 있습니다. 리포지토리 소유자는이 파일을 만들 수 있으며 파일에 정의 된 모든 사용자는 기본적으로 풀 요청 생성 중에 검토를 위해 요청됩니다.
이 기능을 사용하려면 GitHub Pro 버전을 사용하거나 저장소를 공개해야합니다.
저장소의 루트에서 다음 형식으로이 파일을 만들고 파일을 커밋합니다.
* @username 또는 @orgname 또는 @teamname
* 주로 repo의 모든 파일을 의미합니다. * .java 또는 * .js 등과 같은 특정 확장자를 지정할 수도 있습니다. 파일에 정의 된 사용자에게 자동으로 검토 요청이 전송됩니다. CODEOWNERS 파일을 정의하면 검토자를 명시 적으로 추가 할 필요가 없으며 검토 할 파일을 선택할 수있는 유연성이 조금 더 있습니다.
다시 특색 브랜치는 Java 파일을 약간 변경하고 Pull Request를 만듭니다. Pull Request 화면에서 오른쪽에 리뷰어를 할당합니다. 클릭 Pull Request를 생성합니다.
위 화면에서 검토자를 수동으로 지정할 수 있지만 검토자는 코드 변경 검토 요청을 자동으로받는 CODEOWNERS 파일에 정의되어 있음을 알 수 있습니다.
어쨌든 지금은 로그인 검토 자로서 변경 사항을 승인합니다. 사용자 vniranjan2512로 로그인하여 변경 사항을 승인합니다.
아래에 변경 승인 / 거부 요청이 있습니다. Pull Request.
Pull Request를 클릭하고 리뷰를 추가하세요.
클릭 할 수 있습니다 + 표시되는 화면에서 추가 / 수정 / 삭제 코드 줄에 대한 검토 주석에 서명하고 추가합니다.
클릭 검토를 시작하십시오.
클릭 검토를 마칩니다. 표시된대로 승인하고 리뷰 제출 .
풀 요청을 제기 한 원래 사용자로 돌아가서 댓글을 추가하고 대화를 해결하거나 닫을 수 있습니다.
이제 Merge pull 요청을 완료 할 수 있습니다.
변경 사항이 성공적으로 석사 브랜치는 리뷰를 게시하고 풀 요청을 병합합니다.
따라서이 단계에서 요약하자면 개발자가 특색 분기 한 다음 Pull Request를 발생시켜 변경 사항을 석사 분기. 위는 갈등이없는 시나리오였습니다. 다음 섹션에서는 파일이 여러 브랜치에서 변경된 경우 충돌을 수동으로 해결하는 방법을 살펴 보겠습니다.
충돌 해결
여러 분기에있는 동일한 파일이 변경 될 수 있습니다. 이 경우 충돌이 발생할 수 있으며 제기 된 Pull Request를 통해 해결해야합니다.
예를 들어, 둘 다에서 Java 파일을 변경하십시오. 석사 과 특색 분기하고 풀 요청을 제기하십시오.
표시된 풀 요청 메시지는 변경 사항을 자동으로 병합 할 수 없다는 것입니다. 따라서 갈등을 해결해야합니다. Pull Request 생성을 진행합니다.
Pull Request가 발생하면 충돌은 다음을 클릭하여 해결해야합니다. 갈등 해결 단추.
본질적으로 충돌을 수동으로 해결하는 표시를 제거하고 해결됨으로 표시 과 병합을 커밋합니다.
표시가 제거 된 후 파일의 최종보기입니다.
병합 풀 요청을 완료 할 수 있습니다. 그만큼 석사 과 특색 이제 분기가 동일합니다.
위의 화면에서 검토가 요청되었지만 필수 사항은 아니라는 것을 계속 확인할 수 있습니다. 다음 섹션에서는 저장소 소유자가 의무적으로 검토를 요청할 수있는 지점 보호 규칙에 대해 알아보고 석사 직접 커밋에서 분기하지만 풀 요청을 통해서만 가능합니다.
지점 보호 규칙
이전 섹션에서 우리는 Github Pull Requests에 대해 보았습니다. 또한 필수 또는 선택 사항이 아닌 리뷰를 요청했습니다. 일반적인 프로젝트 시나리오 코드에서 검토는 필수이며 개발 프로세스의 일부입니다.
이를 시행하는 방법을 살펴 보겠습니다.
github.com에서이 기능은 공용 저장소 또는 Github pro 버전을 사용하는 경우에만 설정할 수 있습니다. 저장소의 기본 페이지에서 설정 그리고 지점 왼쪽의 카테고리.
클릭 규칙 추가 아래의 지점 보호 규칙. 규칙은 병합하기 전에 코드 소유자의 필수 풀 요청 검토 요청을 추가했습니다. 석사 분기.
이것은 또한 마스터 브랜치 보호되고이 브랜치에서 직접 커밋을 수행 할 수 없으며 철저한 검토 후 Pull Request를 통해서만 커밋 할 수 있습니다. 이 설정은 저장소 소유자가 설정합니다.
참으로 훌륭한 기능 !!!
클릭 창조하다 일단 완료되었습니다. 이 시나리오를 테스트하려면 다음에서 파일을 변경하십시오. 특색 분기하고 풀 요청을 만듭니다.
다음 화면은 코드 소유자가 반드시 검토해야 함을 보여줍니다.
코드 소유자의 리뷰를 게시하여 풀 요청을 병합 할 수 있습니다.
저장소의 공동 작업자로서 파일을 변경하면 보호 된 브랜치의 규칙이 생성되어 마스터 브랜치에 직접 커밋 할 수 없지만 표시된대로 브랜치를 생성 한 후 Pull Request를 통해서만 가능합니다. 이하.
다른 사용자 계정으로 리포지토리 전송
일반적으로 개인 사용자 저장소에는 단일 소유자가 있고 나머지는 모두 공동 작업자입니다. 따라서 사용자 계정 저장소에 여러 소유자를 가질 수 없다는 의미입니다. 그러나 소유권은 다른 사용자 계정으로 이전 될 수 있습니다. 완료되면 원래 저장소 소유자가 자동으로 새 사용자 계정 저장소의 공동 작업자가됩니다.
그런 다음 새 소유자는 아티팩트, 문제, 가져 오기 요청, 프로젝트, 릴리스 및 설정 관리를 시작할 수 있습니다.
일반적으로 'git clone'또는 'git push'와 같은 명령이 로컬 저장소에서 수행되면 명령이 새 저장소로 리디렉션됩니다. 그러나 'git remote -v'명령을 실행하면 원래 저장소 URL이 계속 표시됩니다. 새 원격 URL로 변경하는 데 혼란을 피하기 위해‘git remote set-url’명령을 사용하여 저장소 전송을 게시합니다.
저장소를 전송하려면 저장소의 설정 탭으로 이동하고 옵션? 위험 지역 클릭 이전
소유권을 이전해야하는 저장소 이름과 새 사용자 계정을 입력하십시오.
이해합니다.이 저장소 전송을 클릭하십시오.
저장소가 새 소유자에게 이전되었다는 메시지가 표시되어야합니다.
이전을 승인하기 위해 원래 저장소 소유자에게 메일이 발송됩니다. 이전이 승인되면 저장소가 새 소유자에게 이전되고 원래 저장소 소유자가 공동 작업자로 추가됩니다.
이제 이전 저장소가 복제 된 시스템에서 새 저장소 URL을 설정하십시오. 이전 저장소가 복제 된 모든 시스템에서 다음 명령을 설정해야합니다.
모든 풀 리퀘스트, 이슈, 위키가 전송됩니다. 문제 할당은 그대로 유지됩니다.
몇 가지 유용한 Git 명령
Git 클라이언트가 Linux 또는 Windows 시스템에 설치되면 로컬 시스템에서 초기에 구성 할 몇 가지 기본 Git 명령이 있습니다. 개발자는 GitHub의 리포지토리에 연결하지 않고 GitHub에서 사용할 수있는 소스 코드의 전체 사본에 대해 로컬에서 작업하고 동기화합니다.
먼저 사용자 이름과 이메일 주소를 설정하여이 정보를 사용하는 모든 커밋을 확인하십시오.
git config –global user.name“UserName”
git config –global user.email“myemail@myemail.com”
커밋 중에 메시지를 추가해야하는 경우 필요한 편집기를 구성 할 수도 있습니다.
informatica 인터뷰 질문 및 답변 pdf
git config –global core.editor 메모장
설정된 모든 구성 값 목록을 가져옵니다.
git config –list
때때로 조직에는 인터넷 연결을위한 프록시 서버가 있습니다. 이 경우 GitHub의 모든 리포지토리에 액세스하려면 프록시 서버와 포트 번호를 지정해야합니다.
git config –global http.proxyhttp : // Username : Password @ proxyserver : port
저장소의 로컬 사본을 복제하거나 만듭니다. GitHub에서 저장소의 복제 URL을 가져 와서 git 명령을 실행하십시오.
결론
이 자습서에서는 개발자가 GitHub 리포지토리, 브랜치, 풀 요청 생성, 브랜치 보호 및 몇 가지 기본 Git 명령에서 바로 GitHub 작업을 시작할 수있는 방법을 살펴 보았습니다.
다가오는 자습서에서는 주로 조직, 팀을 만들고, 저장소를 포크하고, 문제, 이정표를 만들고, 끌어 오기 요청, 위키 및 그 용도와 연결하는 방법과 유용한 기타 고급 Git 명령에 대한 GitHub의 다른 기능을 살펴볼 것입니다. 개발자에게.