InfoGrab DocsInfoGrab Docs

코드 관리 시작하기

요약

GitLab은 코드 작성부터 제공까지 소프트웨어 개발 수명 주기 전체를 아우르는 도구를 제공합니다. GitLab에서 코드를 만들고 관리하는 방법을 알아봅니다. 이 프로세스는 더 큰 워크플로의 일부입니다. 프로젝트는 다른 사람과 협업하고, 이슈를 추적하고, 머지 리퀘스트를 관리하고, CI/CD 파이프라인을 자동화하는 등 여러 작업을 수행하는 중앙 공간입니다.

GitLab은 코드 작성부터 제공까지 소프트웨어 개발 수명 주기 전체를 아우르는 도구를 제공합니다.

GitLab에서 코드를 만들고 관리하는 방법을 알아봅니다. 이 프로세스는 코드 작성, 코드 리뷰, 버전 관리를 통한 커밋, 그리고 시간에 따른 업데이트로 구성됩니다.

이 프로세스는 더 큰 워크플로의 일부입니다.

GitLab DevOps 수명 주기의 Create 단계에서 코드 관리

1단계: 리포지터리 생성#

프로젝트는 다른 사람과 협업하고, 이슈를 추적하고, 머지 리퀘스트를 관리하고, CI/CD 파이프라인을 자동화하는 등 여러 작업을 수행하는 중앙 공간입니다.

각 프로젝트에는 리포지터리가 있으며, 여기에 코드, 문서, 소프트웨어 개발 업무와 관련된 그 밖의 파일을 저장할 수 있습니다. 리포지터리의 파일에 적용한 변경 사항은 추적되므로 히스토리를 확인할 수 있습니다.

리포지터리가 소스 코드의 버전 관리에 집중한다면, 프로젝트는 개발 수명 주기 전체를 위한 종합적인 환경을 제공합니다.

자세한 내용은 리포지터리 생성을 참고합니다.

2단계: 코드 작성#

코드를 작성하는 방법과 위치에는 여러 선택지가 있습니다.

GitLab UI를 사용하여 브라우저에서 바로 개발할 수 있습니다. 두 가지 선택지가 있습니다.

  • 단일 파일을 편집할 때 사용하는 일반 텍스트 편집기인 웹 편집기.
  • 여러 파일을 편집할 때 사용하는 더 다양한 기능을 갖춘 편집기인 웹 IDE.

로컬에서 작업하려는 경우에는 Git으로 리포지터리를 컴퓨터에 복제한 다음, 원하는 IDE에서 개발합니다. 이때 GitLab 편집기 확장 프로그램 중 하나를 사용하면 GitLab과 상호 작용하는 데 도움이 됩니다.

앞의 두 가지 선택지를 사용하지 않으려는 경우에는 원격 개발 환경을 실행하여 클라우드에서 작업합니다.

별도의 워크스페이스를 만들어 개발 환경을 더 세분화할 수도 있습니다. 워크스페이스는 서로 다른 프로젝트가 서로 간섭하지 않도록 분리된 개발 환경입니다.

자세한 내용은 다음을 참고합니다.

코드 작성에 관한 그 밖의 도움이 필요하면 코드 제안을 사용합니다.

3단계: 변경 사항 저장 및 GitLab에 푸시#

변경 사항이 준비되면 GitLab에 커밋하여 팀의 다른 구성원과 공유합니다.

변경 사항을 커밋하려면 먼저 다음과 같이 복사합니다.

  • 로컬 컴퓨터의 자신의 브랜치에서
  • 원격 컴퓨터의 GitLab에 있는 default branch로.

브랜치 간에 파일을 복사하려면 머지 리퀘스트를 만듭니다. 방법은 코드를 작성한 위치와 코드 작성에 사용한 도구에 따라 달라집니다. 다만 핵심은 소스 브랜치의 콘텐츠를 가져와 대상 브랜치에 합치도록 제안하는 머지 리퀘스트를 만드는 것입니다.

자세한 내용은 다음을 참고합니다.

4단계: 코드 검토 받기#

코드베이스 변경을 제안하는 머지 리퀘스트를 만들고 나면 해당 제안을 검토받을 수 있습니다. 코드 리뷰는 코드 품질과 일관성을 유지하는 데 도움이 됩니다. 또한 팀 구성원 간에 지식을 공유하는 기회가 됩니다.

머지 리퀘스트는 제안된 변경 사항과 머지하려는 브랜치 사이의 차이를 보여 줍니다.

검토자는 변경 사항을 확인하고 특정 코드 줄에 코멘트를 남길 수 있습니다. 또한 diff에서 직접 변경을 제안할 수도 있습니다.

검토자는 머지하기 전에 변경 사항을 승인하거나 추가 변경을 요청할 수 있습니다. GitLab은 리뷰 상태를 추적하고 필요한 승인을 받을 때까지 머지를 막습니다.

조직에 따라 특정 승인을 요구하거나 특정 동작을 막는 보호 규칙이 있을 수 있습니다. 예를 들어 변경하는 파일에 대해 코드 소유자의 승인이 필요하거나, 머지 리퀘스트를 머지하기 전에 일정 수 이상의 승인이 필요할 수 있습니다.

자세한 내용은 다음을 참고합니다.

5단계: 머지 리퀘스트 병합#

변경 사항을 머지하려면 일반적으로 다른 사람의 승인을 받고 CI/CD 파이프라인을 통과해야 합니다. 요구 사항은 조직마다 다르지만, 보통 다음을 확인하는 항목이 포함됩니다.

  • 코드 변경 사항이 조직의 가이드라인을 준수하는지 여부.
  • 커밋 메시지가 명확하고 관련 이슈에 연결되어 있는지 여부.

보호된 브랜치를 비롯한 리포지터리 보호 조치로 인해 직접 머지하지 못하거나 추가 단계가 필요할 수 있습니다. 변경 사항을 머지할 수 없다면 적용된 보호 규칙을 팀에 확인합니다.

브랜치를 만든 후 대상 브랜치에 머지하기 전에 다른 사람이 파일을 편집하면 머지 충돌이 발생할 수 있습니다. 머지하려면 먼저 모든 충돌을 해결해야 합니다.

자세한 내용은 다음을 참고합니다.

코드 관리 시작하기

GitLab v19.5
원문 보기

요약

GitLab은 코드 작성부터 제공까지 소프트웨어 개발 수명 주기 전체를 아우르는 도구를 제공합니다. GitLab에서 코드를 만들고 관리하는 방법을 알아봅니다. 이 프로세스는 더 큰 워크플로의 일부입니다. 프로젝트는 다른 사람과 협업하고, 이슈를 추적하고, 머지 리퀘스트를 관리하고, CI/CD 파이프라인을 자동화하는 등 여러 작업을 수행하는 중앙 공간입니다.

GitLab은 코드 작성부터 제공까지 소프트웨어 개발 수명 주기 전체를 아우르는 도구를 제공합니다.

GitLab에서 코드를 만들고 관리하는 방법을 알아봅니다. 이 프로세스는 코드 작성, 코드 리뷰, 버전 관리를 통한 커밋, 그리고 시간에 따른 업데이트로 구성됩니다.

이 프로세스는 더 큰 워크플로의 일부입니다.

GitLab DevOps 수명 주기의 Create 단계에서 코드 관리

1단계: 리포지터리 생성#

프로젝트는 다른 사람과 협업하고, 이슈를 추적하고, 머지 리퀘스트를 관리하고, CI/CD 파이프라인을 자동화하는 등 여러 작업을 수행하는 중앙 공간입니다.

각 프로젝트에는 리포지터리가 있으며, 여기에 코드, 문서, 소프트웨어 개발 업무와 관련된 그 밖의 파일을 저장할 수 있습니다. 리포지터리의 파일에 적용한 변경 사항은 추적되므로 히스토리를 확인할 수 있습니다.

리포지터리가 소스 코드의 버전 관리에 집중한다면, 프로젝트는 개발 수명 주기 전체를 위한 종합적인 환경을 제공합니다.

자세한 내용은 리포지터리 생성을 참고합니다.

2단계: 코드 작성#

코드를 작성하는 방법과 위치에는 여러 선택지가 있습니다.

GitLab UI를 사용하여 브라우저에서 바로 개발할 수 있습니다. 두 가지 선택지가 있습니다.

  • 단일 파일을 편집할 때 사용하는 일반 텍스트 편집기인 웹 편집기.
  • 여러 파일을 편집할 때 사용하는 더 다양한 기능을 갖춘 편집기인 웹 IDE.

로컬에서 작업하려는 경우에는 Git으로 리포지터리를 컴퓨터에 복제한 다음, 원하는 IDE에서 개발합니다. 이때 GitLab 편집기 확장 프로그램 중 하나를 사용하면 GitLab과 상호 작용하는 데 도움이 됩니다.

앞의 두 가지 선택지를 사용하지 않으려는 경우에는 원격 개발 환경을 실행하여 클라우드에서 작업합니다.

별도의 워크스페이스를 만들어 개발 환경을 더 세분화할 수도 있습니다. 워크스페이스는 서로 다른 프로젝트가 서로 간섭하지 않도록 분리된 개발 환경입니다.

자세한 내용은 다음을 참고합니다.

코드 작성에 관한 그 밖의 도움이 필요하면 코드 제안을 사용합니다.

3단계: 변경 사항 저장 및 GitLab에 푸시#

변경 사항이 준비되면 GitLab에 커밋하여 팀의 다른 구성원과 공유합니다.

변경 사항을 커밋하려면 먼저 다음과 같이 복사합니다.

  • 로컬 컴퓨터의 자신의 브랜치에서
  • 원격 컴퓨터의 GitLab에 있는 default branch로.

브랜치 간에 파일을 복사하려면 머지 리퀘스트를 만듭니다. 방법은 코드를 작성한 위치와 코드 작성에 사용한 도구에 따라 달라집니다. 다만 핵심은 소스 브랜치의 콘텐츠를 가져와 대상 브랜치에 합치도록 제안하는 머지 리퀘스트를 만드는 것입니다.

자세한 내용은 다음을 참고합니다.

4단계: 코드 검토 받기#

코드베이스 변경을 제안하는 머지 리퀘스트를 만들고 나면 해당 제안을 검토받을 수 있습니다. 코드 리뷰는 코드 품질과 일관성을 유지하는 데 도움이 됩니다. 또한 팀 구성원 간에 지식을 공유하는 기회가 됩니다.

머지 리퀘스트는 제안된 변경 사항과 머지하려는 브랜치 사이의 차이를 보여 줍니다.

검토자는 변경 사항을 확인하고 특정 코드 줄에 코멘트를 남길 수 있습니다. 또한 diff에서 직접 변경을 제안할 수도 있습니다.

검토자는 머지하기 전에 변경 사항을 승인하거나 추가 변경을 요청할 수 있습니다. GitLab은 리뷰 상태를 추적하고 필요한 승인을 받을 때까지 머지를 막습니다.

조직에 따라 특정 승인을 요구하거나 특정 동작을 막는 보호 규칙이 있을 수 있습니다. 예를 들어 변경하는 파일에 대해 코드 소유자의 승인이 필요하거나, 머지 리퀘스트를 머지하기 전에 일정 수 이상의 승인이 필요할 수 있습니다.

자세한 내용은 다음을 참고합니다.

5단계: 머지 리퀘스트 병합#

변경 사항을 머지하려면 일반적으로 다른 사람의 승인을 받고 CI/CD 파이프라인을 통과해야 합니다. 요구 사항은 조직마다 다르지만, 보통 다음을 확인하는 항목이 포함됩니다.

  • 코드 변경 사항이 조직의 가이드라인을 준수하는지 여부.
  • 커밋 메시지가 명확하고 관련 이슈에 연결되어 있는지 여부.

보호된 브랜치를 비롯한 리포지터리 보호 조치로 인해 직접 머지하지 못하거나 추가 단계가 필요할 수 있습니다. 변경 사항을 머지할 수 없다면 적용된 보호 규칙을 팀에 확인합니다.

브랜치를 만든 후 대상 브랜치에 머지하기 전에 다른 사람이 파일을 편집하면 머지 충돌이 발생할 수 있습니다. 머지하려면 먼저 모든 충돌을 해결해야 합니다.

자세한 내용은 다음을 참고합니다.