코드 관리-gitlab 사용 제안

gitlab의 활용은 주로 관리자와 개발 제출자라는 두 가지 관점에서 분석됩니다.

1.1 초기 구성

브라우저 액세스 mit, push 및 기타 작업

* 개발자가 작은 모듈을 완료한 경우 "**새 병합"을 클릭할 수 있습니다. Request**" 버튼을 누르면 담당자에게 코드 병합 요청이 전송됩니다. 병합할 코드 파일도 목록 형태로 담당자에게 전송됩니다. 이때 담당자는 개발자의 요청에 따라 검토 후 코드에 문제가 없으면 모듈이 병합되고 병합을 확인하는 알림이 개발자에게 전송됩니다.

포크는 사용되지 않습니다.

1. 담당자가 개발자를 위한 개발 브랜치(namedev_branch)를 생성합니다.

* 프로젝트 리더는 gitlab에 새 프로젝트를 생성하고 개발자별 개발 브랜치(namedev_branch)를 생성합니다.

* 개발자가 프로젝트를 복제한 후 git 브랜치 검사를 통해 로컬에 마스터 브랜치만 있는 것으로 확인되므로 자체 개발 브랜치도 가져와야 합니다.

> `git fetch Origin namedev_branch:namedev_branch`

> `#namedev_branch라는 원격 브랜치를 가져오고, 원격 브랜치와 일치하도록 로컬에서 namedev_branch라는 브랜치를 생성합니다.`

* namedev_branch 브랜치로 전환

> ` git checkout namedev_branch`

* 후속 작업은 다음과 같습니다. 일반 프로젝트처럼 취급합니다.

> `git add hello.py`

> `git commit -m "add hello.py"`

> `git push -u Origin namedev_branch #원격 namedev_branch 브랜치로 푸시한다는 점에 유의해야 합니다`

~~이 방법 위험하다고 생각합니다. 프로젝트 구성원은 자신의 브랜치를 무시하고 마스터에게 직접 변경 사항을 제출하기 쉽습니다~~

2. 담당자. 개발자를 위해 별도의 개발 브랜치를 생성하지 않습니다(개발자가 직접 생성)

* 프로젝트 리더가 개발자를 위해 별도의 개발 브랜치를 생성하지는 않지만 브랜치를 생성하지만 그룹에 추가해야 합니다. 그렇지 않으면 개발자가 자신의 개발 브랜치를 프로젝트에 푸시할 때 권한 오류가 발생합니다.

* 개발자는 프로젝트 브랜치(namedev_branch)를 복제한 후 스스로 새로운 개발 브랜치를 생성해야 합니다. 로컬에서 마스터 브랜치

> `git Branch namedev_branch #새 브랜치`

> `git checkout namedev_branch #개발 브랜치로 전환`

> `git push Origin namedev_branch #새 개발 브랜치를 원격 프로젝트에 푸시`

* 이후 작업은 일반 프로젝트와 동일합니다.

> `git add hello.py`

> `git commit -m "add hello.py"`

> `git push -u Origin namedev_branch #원격 namedev_branch Branch로 푸시 중이라는 점에 유의해야 합니다`　

그 후 두 가지 방법 모두 프로젝트 리더는 프로젝트의 gitlab 홈페이지에서 각 개발자의 작업 진행 상황을 확인하고,

프로젝트 개선을 위해 개발자 브랜치를 마스터 브랜치에 병합할 때.

코드 복제, 수정, 제출 등의 작업 외에도 프로젝트 리더를 포함한 모든 구성원은 Gitlab 웹 페이지에서 병합 및 브랜치 설정과 같은 기타 작업을 수행할 수 있습니다.

모든 브랜치 중 마스터 브랜치는 트렁크 브랜치이며, 이 브랜치의 코드는 직접 수정이 불가능하며, 병합 요청은 다른 브랜치(일반적으로 개발 브랜치만)에서만 가능합니다. 프로젝트 관리자가 코드 검토를 통과한 후 일반 개발자는 푸시 및 병합과 같은 작업을 수행할 권한이 없습니다. 언제든지 이 브랜치에서 내보낸 프로젝트 코드가 안정적이고 실행될 수 있는지 확인하세요. 일반적으로 개발 분기는 개발 분기이며 다른 분기에서 시작한 프로젝트를 수락할 수도 있으며 프로젝트 관리자가 검토하고 승인한 후에만 병합할 수도 있습니다.

1.2.2 팀 초기화

프로젝트 팀이 팀1과 팀2라는 두 그룹으로 나누어져 있다고 가정합니다. 각 그룹에는 프로젝트에 대해 서로 다른 팀 구성원과 해당 하위 프로젝트가 있습니다. 그룹 사용자는 프로젝트에 대한 액세스를 열고 포크 방법을 사용하여 코드를 업데이트하고 제출합니다.

따라서 우리 gitlab의 아키텍처는 대략 다음과 같습니다.

1. 그룹을 생성하고 기본 인터페이스 위의 더하기 기호에서 **새 그룹**을 선택합니다. 그룹을 생성하기 위해 필드를 채우려면 그룹 경로, 그룹 이름, 설명은 몇 가지 옵션일 뿐입니다. 가시성 수준 옵션의 경우 개인-개인 창고를 선택합니다.

2. 사용자를 생성해야 하는 팀 구성원에 대해 관리자는 해당 사용자를 생성할 책임이 있습니다. 정상적인 상황에서는 초기 로그인 연결이 이 이메일로 전송되지만, 불편한 경우 관리자는 생성 후 사용자의 초기 로그인 비밀번호를 수정할 수도 있습니다.

3. 해당 사용자를 추가할 그룹을 선택합니다. 사용자의 역할은 게스트, 보고자, 개발자, 유지관리자, 소유자로 구분됩니다. 기본적으로 게스트와 개발자만 사용합니다.

4. 그룹에서 프로젝트를 생성하고 하위 그룹을 선택한 후 새 프로젝트를 클릭하여 새 프로젝트를 생성합니다.

5. 프로젝트가 생성된 후 해당 팀원도 포크를 사용하여 프로젝트 내용을 얻을 수 있습니다. 포크 후 구성원 자신의 프로젝트의 git 주소가 다릅니다. 코드는 이 포크 프로젝트의 주소로 제출됩니다. 메인 프로젝트는 웹페이지에서 병합 요청을 시작하고 마스터에서 포크 프로젝트를 업데이트할 때만 사용됩니다.

1.2.3 코드 제출 관리

새로운 코드 제출 요청이 있는 경우 프로젝트 리더는 병합 요청을 확인하여 포크 또는 브랜치에서 병합 요청을 얻을 수 있습니다.

병합을 수락하면 Web IDE에서 열기를 선택하여 감사 변경 내용을 확인하고 문제가 없는지 확인한 후 병합 버튼을 클릭하여 병합할 수 있습니다.

1.2.4 활동 조회

오른쪽 막대에서 프로젝트 -> 활동을 선택하면 푸시, 병합, 이슈, 댓글(토론) 및 기타 정보를 볼 수 있습니다.

Select Cycle Analytics는 그래픽 분석 내용을 볼 수 있는 부분입니다. 이 부분은 충분한 데이터가 뒷받침되어야 하며 주의깊게 연구되어야 합니다.

> Cycle Analytics는 보유한 각 프로젝트에 대해 아이디어에서 생산까지 걸리는 시간을 측정합니다.

> Cycle Analytics는 아이디어에서 생산까지 걸리는 시간을 측정합니다. 각 프로젝트마다 필요한 시간이 있습니다.

## 프로젝트 개발 방법 이슈+마일스톤+라벨

gitlab에서 제공하는 이들 기능을 결합하여 제품이나 모듈의 개발 방법을 완벽하게 정리하고 관리하는 방법

개발 작업을 처음부터 할당하고 마지막에 완료를 표시하는 프로세스를 정의합니다.

이 측면이 gitlab을 잘 활용하는 열쇠입니다. 그렇지 않으면 svn을 대체하는 간단한 버전 관리 도구로 gitlab을 사용할 것입니다.

2.1 포크 프로젝트

프로젝트 구성원 먼저 브라우저를 이용해 gitlab 시스템에 접속해 자신의 그룹과 프로젝트를 확인하고, 개발 참여에 필요한 프로젝트를 포크(fork)합니다.

> 프로젝트 세부정보 인터페이스에서 포크 버튼을 클릭하세요.

포크할 때 **네임스페이스**를 선택하라는 메시지가 표시됩니다. 이 선택은 이 프로젝트가 속한 프로젝트를 결정하는 데 사용됩니다. 사용자 또는 그룹을 선택할 수 있습니다. 이는 후속 프로젝트의 URL에 영향을 미칩니다. 모든 프로젝트 구성원이 통합됩니다. 사용자 자신의 네임스페이스를 선택하기만 하면 됩니다.

2.2 포크 프로젝트 가져오기

프로젝트 콘텐츠는 주로 git 클라이언트 도구를 사용하여 가져옵니다. 프로젝트 개발자는 먼저 로컬 컴퓨터 [다운로드 주소]에 git 클라이언트 소프트웨어를 설치해야 합니다. (/ )

설치 시 기본 설정을 그대로 사용하세요.

설치가 완료된 후 주로 Git Bash 명령줄 도구를 사용하여 작업합니다.

2.3 계정 정보 설정

로컬 해당 gitlab 사용자 및 이메일을 설정하고 수정합니다.

2.4 SSH 연결 정보 구성(Windows에서는 성공하지 못함)

1. SSH 키 생성

다음 명령을 사용하십시오. 키를 입력하고 명령의 YOUR_EMAIL@YOUREMAIL.COM을 Gitlab 등록에 사용된 이메일 주소로 바꿉니다.

`ssh-keygen -t rsa -C "duwj@gitlab.com"`

참고: 암호를 입력하세요(암호가 없는 경우 비어 있음): 직접 Enter를 두 번 누를 수 있습니다. 빈 암호를 입력하려면 암호를 입력하도록 선택할 수도 있습니다. 이때 암호를 입력하는 경우 제출할 때마다 확인을 위해 이 암호를 입력해야 한다는 점을 기억하십시오.

2. 공개키 내용 획득

SSH 키 생성이 완료된 후 프롬프트 정보에 따라 SSH 디렉터리를 찾습니다(보통 SSH 키 저장 경로는 ~/. ssh 디렉터리) 개인 키 id_rsa와 공개 키 id_rsa.pub 두 파일이 표시되면 개인 키 파일 id_rsa의 정보를 누구에게도 공개하지 마세요.

메모장으로 id_rsa.pub를 열고 다음 단계를 위해 내부 내용을 모두 복사하세요.

3. 키에 공개 키를 Gitlab에 추가합니다.

Gitlab 웹사이트에 로그인하고 프로필 설정 - SSH 키 페이지에 들어가서 2단계에서 얻은 내용을 붙여넣습니다. 텍스트 상자 키에 기억하기 쉽도록 제목을 입력한 후 저장하세요.

2.5 코드 복제

gitlab 웹 페이지에 프로젝트 세부 정보를 입력하면 아래로 당겨서 표시된 코드 정보를 볼 수 있습니다.

이러한 방식으로 포크 프로젝트 콘텐츠를 로컬에서 얻을 수 있습니다.

2.6 일반 코드 업데이트 제출

2.7 로컬 웨어하우스 콘텐츠 업데이트 명령

2.8 마스터로 병합 요청

프로젝트 입력 웹 페이지 세부 인터페이스에 진입한 후 포크 프로젝트 코드에 변경 사항이 있는 경우 인터페이스 오른쪽 상단에 병합 요청 생성** 메시지가 표시되어 병합 신청서를 제출합니다.

클릭 후 작성하고 이 제출물의 제목과 설명을 입력하십시오. 설명은 관리자의 검토를 용이하게 하기 위해 이번에 제출된 스크립트, 수정된 내용 및 기타 정보를 설명해야 합니다.

2.9 핵심은 최신 마스터 라이브러리 콘텐츠를 동기화하는 것입니다.

포크된 프로젝트는 마스터 브랜치에서 자동으로 업데이트를 받지 않으며 포크를 담당하는 개발자는 버전을 업데이트해야 합니다. 자신

포크된 코드를 업데이트하는 방법:

* 먼저 기본 저장소의 원격 소스가 설정되었는지 확인하세요.

실행 로컬 프로젝트 라이브러리의 `git remote -v`

* 자신의 두 소스(가져오기 및 푸시)만 볼 수 있는 경우 기본 프로젝트의 소스를 추가해야 합니다. repo:

* fetch 소스 브랜치의 새 버전을 로컬로 가져옵니다.

`git fetch upstream`을 실행합니다.

실행 후 로컬의 내용 라이브러리는 마스터 라이브러리의 내용과 일치하도록 업데이트됩니다.

* 코드의 두 로컬 버전을 병합합니다:

`git merge upstream/master` 실행

* 로컬로 병합된 코드를 자신의 github에 푸시하여 github Warehouse의 포크를 업데이트합니다.

`git push Origin master` 실행

실행 후 웹의 웨어하우스 콘텐츠 페이지는 병합된 새 버전으로 업데이트됩니다.

개발자의 경우 포크를 사용하여 프로젝트를 복제할 때 로컬 Git 클라이언트를 사용하여 프로젝트 콘텐츠를 업데이트, 편집 및 제출하게 됩니다. 웹 페이지에 코드 병합 신청서를 제출하고 표준화된 방식으로 신청서 설명을 작성하면 충분합니다.

관리자의 경우 gitlab을 사용하면 각 직원이 담당하는 콘텐츠의 제출 진행 상황을 쉽게 알 수 있고 제출한 코드에 대한 품질 검사 및 판독도 용이해집니다. 또한 더 많은 통계 및 개발 진행 관리 및 기능이 있습니다. 다른 기능도 있지만 이슈를 사용하여 개발 작업 할당을 관리하거나 마일스톤을 사용하여 마일스톤을 공식화하고 관리하는 등 gitlab의 일부 기능을 능숙하게 사용할 수 있어야 합니다.

# 3. gitlab 사용 및 개발 사양

참고: [gitlab 사용 및 개발 사양](/ruanhao1203/article/details/80440824)