ADO-git-handson# git branch -a
* master
remotes/origin/master
ADO-git-handson#
현재 master 브랜치에서 작업이 이루어 지고 있으며 로컬, 리모트 모두 하나의 브랜치만 존재함을 알 수 있다.
이 구조는 Git을 처음으로 접하여 이런 저런 명령을 수행하거나, 단순한 개인 실습을 수행하는데 별 문제 없지만 실무에서의 현실에서는 master 브랜치를 단일로 유지 및 관리하는 것은 바람직 하지 않다.
실무 협업 환경에서는 소위 Git 브랜치 전략을 채택하여 보다 보안적으로 안전하게 버전 제어를 사용하여 코드를 공유하고 관리 하는 관행이 필요하다.
Git 브랜치 전략 채택
현재 master 브랜치 내의 코드는 인증 정보만 있으면 누구나 바로 복제 및 코드 변경이 가능한 상태이므로 이에 대한 보완이 필요하다. 소위 “Git 브랜치 전략”업데이트 할 수 있는 보안적으로 취약한 상태이다.
다시 터미널에서 README.md 파일을 열고 임의의 메시지를 추가 입력한다. 참고로 필자의 경우에는 # Now we can modify this file directly on the master brancch :( 라고 입력했다. 그리고 나서 git status 명령을 수행한다.
vi README.md cat README.md git status
ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master brancch :(
ADO-git-handson#
ADO-git-handson# git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
ADO-git-handson#
이제 다시 다음과 같이 git add, commit 및 push 명령을 수행하여 리모트 브랜치로 병합한다.
Git은 버전 제어를 사용하여 코드를 공유하고 관리하는 방법을 유연하게 제공하며 팀은 이러한 유연성과 일관된 방식으로 코드를 공동 작업하고 공유해야 하는 필요성 사이의 균형을 찾아야 한다.
팀 구성원은 다른 팀원과 공유되는 Git 브랜치를 통해 코드 변경 사항항을 게시, 공유, 검토 및 반복하는 작업을 수행한다. 이러한 팀을 위한 브랜치 전략을 채택한다. 더 효율적으로 협업하고 버전 제어에 대한 관리 시간을 줄이고 코드를 개발하는 데 더 많은 시간을 할애할 수 있도록 한다.
이러한 개념을 확장하고 모순을 피하는 전략을 통해 팀은 일관되고 따르기 쉬운 버전 제어 워크플로를 얻을 수 있다.
Git 브랜치 전략 구성
이제 master 브랜치를 보호할 수 있도록 구성을 해보겠다.
Azure Repo > Branches로 이동하여 master 브랜치를 선택하고 추가 옵션에서 branch policies를 선택한다.
Branch Policies - Require a minimum number of reviewers를 “1”로 설정하고 데모의 편의성을을 위해 Allow requestors to approve their own changes를 체크한다.
현재 시나리오에서는 간단히 하기 위해서 “Allow requestors to approve their own changes ”를 활성화하여 본인이 직접 Pull Request를 요청하고 검토 후 처리하지만 실무에서는 1명 이상의 다른 검토자를 지정하고 코드 검토 및 승인할 수 있도록 하는 관행이 필요하다.
이제 다시 터미널에서 README.md 파일을 열고 메시지 내의 오타를 수정한다. “brancch:에서 “c”를 하나 제거하여 저장한다.
vi README.md README.md
ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master branch :(
ADO-git-handson#
이제 다시 다음 명령을 수행하여 리모트 브랜치로 병합한다.
git commit -am "Modify README.md correcting the typeo in the comment" git push
ADO-git-handson# git commit -am "Modify README.md correcting the typeo in the comment"
[master 437b06c] Modify README.md correcting the typeo in the comment
1 file changed, 1 insertion(+), 1 deletion(-)
ADO-git-handson# git push
Password for 'https://zerobig-devops4demo@dev.azure.com':
ADO-git-handson# git push
Password for 'https://zerobig-devops4demo@dev.azure.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 302 bytes | 7.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (32 ms)
remote: Validating commits... (1/1) done (0 ms)
remote: Storing packfile... done (29 ms)
remote: Storing index... done (31 ms)
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
! [remote rejected] master -> master (TF402455: Pushes to this branch are not permitted; you must use a pull request to update this branch.)
error: failed to push some refs to 'https://zerobig-devops4demo@dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo'
ADO-git-handson#
생성한 feature 브랜치의 로그를 조회해보면 master 브랜치와 동일한 커밋 이력을 가지고 있으며, 동일한 커밋에 HEAD가 포인팅 되어 있음을 확인할 수 있다. 따라서 master 브랜치의 파일 내용과 동일한 상태로 현행화 되어 있음을 알 수 있다.
ADO-git-handson# git checkout -b feature
Switched to a new branch 'feature'
ADO-git-handson# git branch
* feature
master
ADO-git-handson# git log --oneline --graph
* 85354b7 (HEAD -> feature, origin/master, origin/HEAD, master) Modify README.md adding the comment
* c986055 Add a README.md
ADO-git-handson#
Git 브랜치 정책 및 Git Flow 관련 공식 문서 본 글에서는 간략하게 feature 브랜치를 생성하여 작업 후 master 브랜치에 Pull Request 하는 시나리오로 구성했다. Git 브랜치 정책과 관련한 상세 내용을 확인하려면 다음 2개의 문서를 확인한다. - GitHub : 우리 팀에 맞는 Git Branch 전략 선택하기 - Azure DevOps : 분기 및 분기 정책 정보
이제 다시 터미널에서 README.md 파일을 열고 메시지 내의 오타를 수정한다. “brancch:에서 “c”를 하나 제거하여 저장한다.
vi README.md README.md
ADO-git-handson# vi README.md
ADO-git-handson# cat README.md
Hello~ GIT~:)
# Now we can modify this file directly on the master branch :(
ADO-git-handson#
이제 다시 다음 명령을 수행하여 리모트 브랜치로 병합한다.
git commit -am "Modify README.md correcting the typeo in the comment" git push --set-upstream origin feature
ADO-git-handson# git commit -am "Modify README.md correcting the typeo in the comment"
[feature a093d0f] Modify README.md correcting the typeo in the comment
1 file changed, 1 insertion(+), 1 deletion(-)
ADO-git-handson#
ADO-git-handson# git push
fatal: The current branch feature has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin feature
ADO-git-handson# git push --set-upstream origin feature
Password for 'https://zerobig-devops4demo@dev.azure.com':
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes | 14.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Analyzing objects... (3/3) (39 ms)
remote: Validating commits... (1/1) done (73 ms)
remote: Storing packfile... done (36 ms)
remote: Storing index... done (48 ms)
To https://dev.azure.com/zerobig-devops4demo/20240809_AzureDevOps_Git_Demo/_git/20240815_AzureDevOps_Git_Demo
* [new branch] feature -> feature
Branch 'feature' set up to track remote branch 'feature' from 'origin'.
ADO-git-handson#
리모트 리포지토리를 새로고침하여 푸시 결과를 확인한다.
feature 브랜치의 업데이트를 감지하고 Pull Request를 시행하도록 메시지가 전시되었음을 확인할 수 있다.
우선 새로운 브랜치 feature를 선택하고 결과를 확인한다.
feature 브랜치의 README.md 파일에는 오타가 수정되어 반영되어 있음을 확인할 수 있다.
Create a pull request를 선택한다.
Reviewer를 추가하고 Create를 선택한다.
참고로 위에서 본인이 직접 Pull Request를 요청하고 검토 후 처리하지할 수 있도록 정책을 구성했으므로 자신을 Reviewer로 지정 가능하지만 여기서는 다른 검토자를 지정하였다. 당연히 사전에 프로젝트에 멤버로 추가 되어 있어야 한다. 멤버 추가에 대한 내용은 이 문서 를 참조한다.
검토자에게 다음과 같은 검토 요청 관련 메일이 수신 된다. View pull request를 선택하여 해당 페이지로 이동한다.
검토자는 해당 페이지에서 각 탭을 선택하여 Pull Request에 대한 자세한 내용들을 확인할 수 있다. File 탭을 선택한다.
파일 변경 전후의 내용을 직관적으로 비교 및 검토 할 수 있으며, 필요 시 검토 의견을 남길 수 있다. 내용이 적합하지 않을 경우, 보완 요청 의견을 남기고 Reject 을 수행할 수도 있다.
Repos > Files를에서 master 브랜치로 이동하면 변경 사항이 적용된 병합 결과를 확인할 수 있다.
Repos > Commits를 선택하여 master와 feature 두 브랜치의 내용을 비교하여여 살펴본다.
# feature
마지막 커밋 아이디 a093.. 임을 확인한다.
# master
마지막 커밋 아이디 defb..임을 확인한다. 즉, 하나의 커밋이 더 추가 되어 있음을 확인할 수 있다. 병합 옵션에 따라 결과가 달라 지는데 이 글에서는 기본값으로 진행하였다.
Pull Request를 생성 후 브랜치 병합 과정에서 프로젝트 상황에 따라 다양한 방식의 병합 옵션을 검토할 수 있다. Azure DevOps Repos의 Merge Type에 대한 추가 내용은 이 문서를 참조한다. 병합 기본 옵션 값은 Merge (no-fast forward )”이다. 모든 커밋을 보전하며 비선형 기록으로 병합한다. 이 전략은 개발자가 토픽 브랜치에서 작업한 방식과 브랜치가 발전한 방향에 대한 완전한 통찰력을 제공하기 때문에 유용하지만 브랜치 기록에 커밋이 많으면 매우 장황할 수 있다. 병합 옵션에 대한 자세한 내용은 이 문서를 참고한다.
7. 브랜치 정리 및 새로 작업 준비하기
작업 브랜치(feature) 정리
이제 Pull Request 작업이 완료 되었으므로 필요 시 다음과 같이 feature 브랜치를 삭제할 수 있다.
참고로 feature 브랜치는 다음과 같이 Pull Request 병합 과정에서도 선택하여 제거가 가능하다.
더불어, 로컬의 터미널 상에서도 다음과 같은 명령을 수행하여 삭제가 가능하다.
먼저 현재 작업 브랜치를 확인하고 해당 브랜치가 feature 브랜치라면 master 브랜치로 이동한다.
git branch git checkout master
ADO-git-handson# git branch
* feature
master
ADO-git-handson# git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
다음 명령을 수행하여 로컬 feature 브랜치를 삭제한다. 해당 명령 수행 후 전체 브랜치 현황을 보면 리모트에 feature 브랜치는 아직 존재함을 알 수 있다.
git branch --delete feature git branch --all
ADO-git-handson# git branch --delete feature
warning: deleting branch 'feature' that has been merged to
'refs/remotes/origin/feature', but not yet merged to HEAD.
Deleted branch feature (was a093d0f).
ADO-git-handson# git branch --all
* master
remotes/origin/HEAD -> origin/master
remotes/origin/feature
remotes/origin/master
다시 다음 명령을 수행하여 리모트 feature 브랜치를 삭제한다. 해당 명령 수행 후 전체 브랜치 현황을 보면 리모트에 feature브랜치가 삭제 된 것을 확인 할 수 있다.
