/
20240808 Azure DevOps를 활용한 Git 기초 및 활용 가이드

20240808 Azure DevOps를 활용한 Git 기초 및 활용 가이드

 

 

 

image-20240809-033849.png

 

 

 

 

 

1. Git 프로세스 개요

 

2. Git 아키텍처 개요

 

3. 소스 가져오기 : git clone

 

 

 

소스를 clone하고 해당 디렉토리로 이동한다.

git clone <소스 URL> <디렉토리명> cd <디렉토리명>

 

ADO-git-handson# git clone https://zerobig-devops4demo@dev.azure.com/zerobig-devops4demo/202408_AzureDevOps_Git_Demo/_git/202408_AzureDevOps_Git_Demo 20240808_git_handson Cloning into '20240808_git_handson'... Password for 'https://zerobig-devops4demo@dev.azure.com': warning: You appear to have cloned an empty repository. ADO-git-handson# cd 20240808_git_handson/ ADO-git-handson# ls -rlht total 0 ADO-git-handson#

 

 

4. git 명령 맛보기 : add/commit/push 실행하기

파일을 생성하고 커밋 후 리모트로 푸시한다.

vi README.md git status git add . git commit -m "First Commit" git status git push

 

 

리모트 리포지토리를 새로고침하여 푸시 결과를 확인한다.

Repos > Commits를 선택하여 내용을 살펴본다.

로컬에서 git log 명령을 통해 commit에 대한 로그를 확인해본다.

 

 

 

5. 새로운 브랜치 생성하여 작업하기

현재 브랜치를 확인하고 새로운 브랜치를 생성하여 작업을 준비한다.

 

 

VS Code를 띄워서 colors.txt 파일을 생성하고 내용을 입력 후 저장한다.

 

터미널로 돌아와 git status 명령을 수행하여 상태를 확인한다.

 

 

다시 커밋 후 리모트로 푸시한다.

 

리모트 리포지토리를 새로고침하여 푸시 결과를 확인한다.

새로운 브랜치 feat-1-colors를 선택하고 결과를 확인한다.

master 브랜치에는 존재하지 않는 colors.txt 파일이 존재함을 확인할 수 있다.

Repos > Commits를 선택하여 두 브랜치의 내용을 비교하여여 살펴본다.

# master

# feat-1-colors

feat-1-colors 브랜치에는 colors.txt가 추가되어 있으며 하나의 커밋이 더 생겨 있음을 확인할 수 있다.

이는 로컬의 터미널에서도 git log 명령을 통해 확인할 수 있다.

 

 

HEAD 포인터

HEAD현재 브랜치를 가리키는 포인터이며, 브랜치는 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킨다. 지금의 HEAD가 가리키는 커밋은 바로 다음 커밋의 부모가 된다. 단순하게 생각하면 HEAD는 *현재 브랜치 마지막 커밋의 스냅샷*이다.

 

 

6. Pull Request 수행하기

 

Azure Repo > Branches로 이동하여 Create a pull request를 선택한다.

 

상세한 요청 내역 작성, Reviewer 추가 후 Create 클릭한다.

Complete를 클릭하여 master 브랜치에 병합을 수행한다.

Complete merge를 선택한다.

정상적으로 병합이 이루어졌음을 확인한다.

Repos > Commits를 선택하여 두 브랜치의 내용을 비교하여 살펴본다.

master 브랜치에 Merged 커밋이 추가되어 있으며 커밋 이력이 일치하고 있음을 확인할 수 있다.

# master

# feat-1-colors

이는 로컬의 터미널에서도 git log 명령을 통해 확인할 수 있다.

 

 

# master

# feat-1-colors

 

참고

현재 시나리오에서는 간단히 하기 위해서 본인이 직접 Pull Request를 요청하고 처리하지만 실제로는 권한 있는 검토자를 지정하고 해당 검토자를 통해 코드 검토 및 확인을 받아야 한다.

Pull Request를 요청하게 되면 Reviewer에게 요청이 전달되며 다음과 같이 Files 탭에서 변경사항을 확인하고 관련 Comment를 남길 수 있다.

 

 

7. Brach 전략 수립하기

 

Git 브랜치 전략 채택

현재 master 브랜치 내의 코드는 쉽게 접근하여 코드 변경을 수행할 수 있는 상태이므로 이에 대한 보완이 필요하다. 소위 “Git 브랜치 전략”업데이트 할 수 있는 보안적으로 취약한 상태이다.

Git은 버전 제어를 사용하여 코드를 공유하고 관리하는 방법을 유연하게 제공하며 팀은 이러한 유연성과 일관된 방식으로 코드를 공동 작업하고 공유해야 하는 필요성 사이의 균형을 찾아야 한다.

팀 구성원은 다른 팀원과 공유되는 Git 브랜치를 통해 코드 변경 사항항을 게시, 공유, 검토 및 반복하는 작업을 수행한다. 이러한 팀을 위한 브랜치 전략을 채택한다. 더 효율적으로 협업하고 버전 제어에 대한 관리 시간을 줄이고 코드를 개발하는 데 더 많은 시간을 할애할 수 있도록 한다.

다음 브랜치 전략은 Microsoft에서 Git을 사용하는 방법을 기반으로 하며 자세한 내용은 Microsoft에서 Git을 사용하는 방법을 참조한다.

브랜치 전략을 단순하게 유지한다. 다음 세 가지 개념으로 전략을 빌드한다.

  • 새로운 모든 기능과 버그 수정에 feature 브랜치를 사용한다.

  • Pull Request를 사용하여 feature 브랜치를 master 브랜치에 병합한다.

  • 고품질의 최신 master 브랜치를 유지한다..

이러한 개념을 확장하고 모순을 피하는 전략을 통해 팀은 일관되고 따르기 쉬운 버전 제어 워크플로를 얻을 수 있다.

 

 

Git 브랜치 전략 구성

 

Azure Repo > files로 이동하여 master 브랜치에서 colors.txt를 선택하고 Edit을 선택한다.

Pink를 추가하고 Commit을 선택한다.

다시 Commit을 선택한다.

파일이 수정되고 하나의 Commit이 생성되었다.

이제 master 브랜치를 보호할 수 있도록 구성을 해보겠다.

Azure Repo > Branches로 이동하여 master 브랜치를 선택하고 추가 옵에서 branch policies를 선택하고 Edit을 선택한다.

Branch Policies - Require a minimum number of reviewers를 “1”로 설정하고 데모의 편의성으 위해해 Allow requestors to approve their own changes를 체크한다.

이제 다시 Azure Repo > files로 이동하여 master 브랜치에서 colors.txt를 선택하고 Edit을 선택한다. 파일 변경 후 Commit을 시도하면 “TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.” 에러가 발생함을 확인할 수 있다. 즉, 이 브랜치에 대한 푸시는 허용되지 않았으며 이 브랜치의 업데이트는 Pull Request를 통해서만 가능함을 알 수 있다.

이제 구성된 환경을 토대로 코드 변경 및 Pull Request를 통한 master 브랜치로의 병합을 시도해 보겠다.

 

 

Git 브랜치 전략 구성 증

소스 현행화

터미널로 이동하여 다음 명령을 통해 feature 브랜치로의 소스를 현행화 한다.

먼저 현재 브랜치를 확인하고 새로운 브랜치를 생성하여 작업을 준비한다.

 

 

소스 수정 및 commit, push

colors.txt 파일을 열어 Yellow를 추가하고 저장한 후 git add, commit 및 push를 수행한다.

 

 

Pull Request 작성

리모트 리포지토리를 새로고침하여 푸시 결과를 확인한다.

Create a pull request를 선택 후 Reviewers에 자신을 추가하고 Pull Request를 생성한다.

정상적으로 master 브랜치에 병합이 이루어진 결과를 확인할 수 있다.

참고로 Reviewers를 지정하지 않으면 사전에 구성한 브랜치 정책으로 인해 Pull Request 작성이 불가함을 확인할 수 있다.

Pull Request 검토자는 다음과 같이 코드의 변경사항을 비교할 수도 있고 필요 시, 의견을 남길 수도 있다.

Repos > Commits를 선택하여 두 브랜치의 내용을 비교하여 살펴본다.

master 브랜치에 Merged 커밋이 추가되어 있으며 커밋 이력이 일치하고 있음을 확인할 수 있다.

# master

# feat-1-colors