27. Visual Studio Code 및 GitHub에서 Git으로 버전 제어하기

<참조> https://azuredevopslabs.com/labs/azuredevops/github/#task-2-staging-changes

 

 

 

 

 

이번 글에서는 "VIsual Studio Code와 GitHub에서 풀 요청 작업하기"를 다루려고 했으나 이 Lab의 선행 조건으로 본 Lab이 지정되어 있어 부득이 하게 먼저 본 Lab을 작성하게 되었다. 사실  Azure DevOps의 내용은 전혀 포함되지 않았지만 Azure DevOps Labs 내 등록되어 있으니 함께 살펴보기로 하겠다. 제목에서도 알 수 있듯이 이전에 다뤘던 VIsual Studio Code와 Azure DevOps에서 Git으로 버전 제어하기와 겹치는 내용이 많은데 비교해 가며 검토하는 것도 좋을 듯 하다.

 

 

 

 

 

개요

Git은 분산 버전 관리 시스템이다. Git 리포지토리는 로컬 (예 : 개발자 컴퓨터)에 있을 수 있다. 각 개발자는 개발자 컴퓨터에 소스 리포지토리의 복사본을 가지고 있다. 개발자는 개발자 컴퓨터에서 각 변경 사항을 커밋하고 네트워크 연결이 안된 상태에서도 이력과 비교와 같은 버전 제어 작업을 수행할 수 있다.

 

 

 

 

 

 

 

선행 조건

• C# 확장이 설치된 Visual Studio Code

• Git for Windows 2.21.0 이상

 

 

 

 

실습 1: 랩 환경 구성하기

 

과제 1: 비주얼 스튜디오 코드 구성하기

1. Visual Studio Code를 연다. 이 과제에서는 GitHub와 통신하는데 사용되는 Git 자격 증명을 안전하게 저장하도록 Git 자격 증명 도우미를 구성한다. 자격 증명 도우미(credential helper)와 Git ID를 이미 구성한 경우 다음 과제로 건너 뛸 수 있다.

 

2. 메인 메뉴에서 Terminal | New Terminal를 선택하고 터미널 창을 연다.

 

3. 아래 명령을 실행하여 자격증명 도우미를 구성한다.

git config --global credential.helper wincred

 

4. 아래 명령은 Git 커밋에 대한 사용자 이름과 이메일을 구성한다. 원하는 사용자 이름과 이메일로 매개 변수를 바꾸고 실행한다. 

git config --global user.name "John Doe"  git config --global user.email johndoe@example.com

 

 

과제 2: 기존 리포지토리 Fork하기

1. 브라우저 탭에서 https://github.com/Microsoft/PartsUnlimitedE2E GitHub 프로젝트로 이동한다. 

 

2. Fork를 클릭한다. 그러면 원래 저장소에 영향을주지 않고 작업 할 수 있도록 전체 저장소가 지정한 계정으로 복사된다.

3. Fork 받을 GitHub 계정을 선택한다. Fork는 신속하게 이루어진다. 

 

 

과제 3: 기존 리포지토리 복제하기

1. 이제 GitHub 브라우저 탭이 포크된 버전의 리포지토리에 열려 있어야 한다. 

 

2. Git 저장소의 로컬 사본을 얻는 것을 “복제”라고 한다. 모든 주류 개발 도구는 이를 지원하며 GitHub에 연결하여 최신 소스를 내려 받을 수 있다. Clone or download 드롭다운에서 Copy to clipboard 버튼을 클릭한다.

3. Visual Studio Code 인스턴스를 연다.

 

4. Ctrl|Shift+P를 눌러하여 Command Palette를 연다. 명령 팔레트는 3rd 확장에서 제공하는 작업을 포함하여 다양한 작업에 쉽고 편리하게 액세스 할 수 있는 방법을 제공한다.

 

5. Git: Clone 명령을 실행한다. "Git"을 타이핑하여 숏리스트에 올리면 도움이 될 수 있다.

 

6. Repo에서 복사한 URL을 붙여넣고 Enter를 누른다.

 

7. 리포지토리를 복제할 로컬 경로를 선택한다.

 

 

8. 메시지가 표시되면 GitHub 계정에 로그인 한다.

 

9. 복제가 완료되면 Open을 클릭한다. 프로젝트를 열 때 발생하는 경고는 무시할 수 있다. 솔루션이 빌드 가능한 상태가 아닐 수도 있지만 Git 작업에 집중하고 프로젝트 자체를 빌드할 필요가 없으므로 괜찮다.

 

 

 

 

 

 

실습 2: 카밋으로 작업 저장하기

파일을 변경하면 Git은 로컬 저장소에 변경 사항을 기록한다. 변경 사항을 스테이징하여 커밋하려는 변경 사항을 선택할 수 있다. 커밋은 항상 로컬 Git 리포지토리에 대해 이루어 지므로 커밋이 완벽하거나 다른 사람과 공유 할 준비가 되어있는 것에 대해 걱정할 필요가 없다. 계속 작업하면서 더 많은 커밋을 수행할 수 있으며 다른 사람이 공유받을 준비가 된 경우 해당 변경 사항을 그 사람에게 푸시 할 수 있다.

하나의 커밋 내에는 무엇이 있을까?

Git 커밋은 다음과 같이 구성된다.

• 커밋으로 변경된 파일. Git은 커밋 내에는 repo의 모든 파일 변경 사항의 내용을 유지한다. 이를 통해 신속하게 유지하고 지능적인 병합이 가능하도록 해준다.
• 부모(parent) 커밋에 대한 참조. Git은 이러한 참조를 사용하여 코드 히스토리를 관리한다.
• 커밋을 설명하는 메시지. 우리는 커밋을 생성할 때 메시지를 Git에 제공한다. 이 메시지에는 설명을 기술하되 요점을 담는 것이 좋다. 

 

과제 1: 변경 사항 커밋하기

1. Explorer탭에서 /PartsUnlimited-aspnet45/src/PartsUnlimitedWebsite/Models/CartItem.cs를 연다. 

 

2. 파일에 주석을 추가한다. 단지 변경이 목적이므로 어떤 주석이던 중요하지 않다. Ctrl+S를 눌러 파일을 저장한다.

 

3. 소스 제어 탭을 선택하여 솔루션에 대한 변경 사항을 확인한다.

 

4. “My commit”의 커밋 메시지를 입력하고 Ctrl+Enter를 눌러 로컬로 커밋한다.

 

5. 변경 사항을 자동으로 스테이징하고 직접 커밋할지 묻는 메시지가 표시되면 Always을 클릭한다. 나중에 랩에서 staging을 논의 할 것이다.

 

7. 메시지가 표시되면 GitHub 계정에 로그인한다.

 

 

 

과제 2: 변경 사항 스테이징하기

스테이징 변경 사항을 사용하면 다른 파일에서 작성된 변경 사항을 전달하면서 커밋에 특정 파일을 선택적으로 추가 할 수 있다.

 

1. Visual Studio Code로 돌아간다. 

 

2. 앞서 작성한 주석을 편집하여 파일을 저장하고 열린 CartItem.cs 클래스를 업데이트 한다.

 

3. Category.cs도 연다.

 

4. Category.cs에 새 주석을 추가하면 변경 사항을 가지는 두 개의 파일이 존재하게 된다. 파일을 저장한다.

 

5. Source Control 탭에서 CartItem.cs의 Stage Changes 버튼을 클릭한다.

 

6. 이렇게하면 CartItem.cs가 Category.cs를 빼고 커밋 할 수 있도록 준비된다.

 

7. “Added comments”라고 커멘트를 입력한다. More Actions 드롭다운에서 Commit Staged를 선택한다.

 

8. 커밋된 변경 내용을 서버와 동기화하려면 Synchronize Changes 버튼을 클릭한다. 단계적 변경 사항만 커밋 되었으므로 다른 변경 사항은 여전히 로컬에 보류 중이다.

 

 

 

 

 

 

실습 3: 이력 검토하기

 

Git은 각 커밋에 저장된 부모 참조 정보를 사용하여 개발에 대한 전체 이력을 관리한다. 이 커밋 이력을 검토하여 용이하게 파일 변경시기를 확인하고 터미널을 사용하거나 사용 가능한 많은 Visual Studio Code 확장 중 하나를 사용하여 코드 버전 간 차이를 확인할 수 있다. GitHub 포털을 사용하여 변경 사항을 검토 할 수도 있다.

Git의 Branches and Merges 기능은 풀 요청(Pull Request)을 통해 작동하므로 개발 커밋 이력이 반드시 연대순으로 표시되는 것은 아니다. 이력을 사용하여 버전을 비교할 때 두 시점 사이의 파일 변경 대신 두 커밋 사이의 파일 변경을 고려해라. 마스터 브랜치 파일에 대한 최근 변경 사항은 2주 전에 기능 브랜치에서 생성된 커밋에서 나왔지만 어제 병합되었을 수도 있다.

 

 

과제 1: 파일 비교하기

1. Source Control 탭에서 CartItem.cs을 선택한다.

 

2. 이루어진 변경 사항을 쉽게 찾을 수 있도록 비교보기가 열린다. 이 경우에는 한 개의 주석 뿐이다.

 

3. GitHub 브라우저 탭으로 돌아간다. 

 

 

과제 2: 파일 비교하기

1. GitHub 브라우저 탭으로 전환한다. 커밋 탭에서 GitHub의 최신 커밋을 검토 할 수 있다.

 

2. 최근 커밋이 맨 위에 있어야 한다. 가장 최근의 것을 클릭한다.

 

3. View file을 통해 이 커밋에 의해 적용된 변경 사항을 검토 할 수 있다. 파일보기를 클릭한다.

 

 

4. 시간이 지남에 따라 이 파일에 대한 커밋을 추적하기 위해 History를 클릭한다.

 

5. 두 번째 커밋에 대한 Browse repository at this point in the history 버튼을 클릭한다. 이것은 이 랩에서 처음으로 푸시한 커밋이었다.

 

6. 이제 이 커밋이 푸시 될 때 리포지토리의 상태를 검토 할 수 있다. 상단의 드롭 다운을 통해 브랜치간에 편리하게 전환 할 수 있다.

 

 

 

 

 

 

실습 4: 브랜치 작업하기

 

Branches 탭에서 GitHub 리포지토리의 작업을 관리 할 수 ​​있다. 또한 가장 관심있는 브랜치를 추적하도록 보기를 사용자 정의하여 팀이 변경한 사항을 파악할 수 있다.

브랜치에 변경 사항을 커밋해도 다른 브랜치에는 영향을 미치지 않으며 변경 내용을 기본 프로젝트에 병합하지 않고도 다른 브랜치와 브랜치를 공유 할 수 있다. 또한 새로운 브랜치를 생성하여 기능 또는 버그 수정에 대한 변경 사항을 마스터 브랜치 및 기타 작업에서 분리할 수도 있다. 브랜치가 경량이므로 브랜치 간 전환이 빠르고 쉽다. Git은 브랜치로 작업 할 때 소스의 여러 복사본을 만들지 않고 커밋에 저장된 이력 정보를 사용하여 브랜치에서 작업을 시작할 때 파일을 다시 만든다. Git 워크 플로우는 기능 및 버그픽스 관리를 위한 브랜치를 생성하고 사용해야 한다. 코드 공유 및 PR을 통해 코드를 검토하는 등의 나머지 Git 워크 플로우는 모두 브랜치를 통해 작업한다. 브랜치에서 작업을 분리하면 현재 브랜치를 변경하여 작업중인 내용을 매우 간단하게 변경할 수 있다.

 

과제 1: 로컬 리포지토리에 새로운 브랜치 생성하기

1. Visual Studio Code로 돌아간다.

 

2. 왼쪽 하단에서 master 브랜치를 클릭한다.

 

3. Create new branch from….를 선택한다.

 

4. 새 브랜치의 이름을 "dev"로 입력하고 Enter를 누른다.

 

5. 참조 브랜치로 master를 선택한다.

 

6. 이제 해당 브랜치에서 작업을 하게 되었다.

 

 

과제 2: 브랜치 작업하기

Git은 작업중인 브랜치를 추적하고 브랜치를 체크아웃 할 때 파일이 지점의 최신 커밋과 일치하는지 확인한다. 브랜치를 사용하면 동일한 로컬 Git 리포지토리에서 여러 버전의 소스 코드를 동시에 사용할 수 있다. Visual Studio Code를 사용하여 브랜치를 게시, 체크 아웃 및 삭제할 수 있다.

 

1. 브랜치 옆에 있는 Publish changes 버튼을 클릭한다.

 

2. GitHub 브라우저 탭에서 Branches 탭을 선택한다.

 

3. 새로 푸시된 dev 브랜치가 표시되어야 한다.  Delete this branch 버튼을 클릭하여 삭제한다.

 

4. Visual Studio Code로 돌아간다.

 

5. dev 브랜치를 클릭한다.

 

6. 두 가지 dev 브랜치가 나열되어 있다. 로컬(dev) 브랜치는 서버 브랜치를 삭제할 때 삭제되지 않기 때문에 리스트에 존재한다. 서버 (origin/dev)는 정리되지 않았기 때문에 존재한다. master 브랜치를 선택하여 체크아웃 한다.

 

7. Ctrl+Shift+P를 눌러 Command Palette를 연다.

 

8. “Git: Delete” 라고 타이핑하여 Git: Delete Branch가 표시되면 선택한다.

 

9. 삭제할 로컬 브랜치는 하나뿐이므로 그것을 선택한다. 

 

10. master 브랜치를 클릭한다.

 

11. 로컬 dev 브랜치는 사라졌지만 리모트 origin/dev는 여전히 표시된다.

 

12. Ctrl+Shift+P를 눌러 Command Palette를 연다.

 

13. “Git: Fetch”를 타이핑 하여 Git: Fetch (Prune)가 표시되면 선택한다. 이 명령은 로컬 스냅 샷에서 원본 브랜치를 업데이트하고 더 이상 존재하지 않는 브랜치는 삭제한다.

 

14. 화면 맨 아래에서 Output 창을 선택하여 이러한 작업이 정확하게 어떠한 작업을 수행하는 것인지 확인할 수 있다.

 

15. 출력 콘솔에 Git 로그가 표시되지 않으면 소스로 Git을 선택해야 할 수도 있다.

 

16. master 브랜치를 클릭한다.

 

17. origin/dev 브랜치가 더 이상 목록에 없어야 한다.

 

 

 

 

 

실습 5: GitHub에서 브랜치 관리하기

Visual Studio Code에서 사용할 수 있는 모든 기능과 더불어 GitHub 포털에서도 리포지토리를 관리 할 수 있다.

 

 

과제 1: 새로운 브랜치 생성하기

1. GitHub 브라우저 탭으로 전환한다. 

 

2. Code 탭 root로 돌아간다.

 

3. 브랜치 드롭 다운에서 브랜치 이름 "release"를 입력한다. Create branch: release를 클릭한다. 그러면 새 브랜치가 만들어지고 전환된다.

 

4. 새로 작성된 릴리스 브랜치가 선택되었는지 확인할 수 있다.

 

5. Visual Studio Code로 돌아간다.

 

6. Ctrl+Shift+P를 눌러 Command Palette를 연다.

 

7. “Git: Fetch”를 타이핑 하여 Git: Fetch가 표시되면 선택한다. 이 명령은 로컬 스냅 샷에서 원본 브랜치를 업데이트한다.

 

8. master 브랜치를 클릭한다.

 

9. origin/release를 선택하다. 이렇게 하면 release 라는 새로 로컬 브랜치가 생성되고 그 브랜치로 체크 아웃될 것이다. 

 

 

과제 2: 브랜치 삭제하기

1. GitHub 브라우저 탭으로 돌아가 Branches 탭으로 이동한다.

 

2. release 브랜치에 대한 Delete 버튼을 클릭한다.

 

3. 하지만 조금 더 오래 유지해야만 할 지도 모른다. 삭제를 취소하려면 Restore을 클릭한다.

 

 

과제 3: 릴리즈에 태킹하기

1. 딱히 그리 보이지 않을 수도 있으나 프로덕트 팀은 이 버전의 사이트가 v1.1에 꼭 필요한 것으로 결정했다. 이를 표시하려면 Code 탭으로 돌아가 Releases를 선택한다.

 

2. Create a new release를 클릭한다. 

 

3. tag와 release names에는 “v1.1” 으로 Description 란은 “Great release!”라고 입력한 후 Publish release를 클릭한다.

 

4. 이번 릴리스에서 프로젝트에 태그를 지정했다. 다양한 이유로 커밋에 태그를 지정할 수 있으며 GitHub는 권한을 관리 할 뿐만 아니라 이를 편집 및 삭제하는 유연성을 제공한다.

 

5. Tags 옵션을 선택하여 이름별로 태그를 검토한다.

 

 

 

 

 

실습 6: GitHub에서 브랜치 관리하기

팀 프로젝트에서 Git 리포지토리를 만들어 프로젝트의 소스 코드를 관리 할 수 있다. 각 Git 리포지토리에는 프로젝트의 다른 작업과 분리할 수 있는 고유한 퍼미션 및 브랜치가 있다.

 

 

과제 1: 새로운 리포지토리 생성하기

1. New 드롭 다운에서 New repository를 선택한다. 

 

2. Repository name을 "New Repo"로 설정한다. README.md라는 파일을 작성하는 옵션도 있다. 이것은 누군가 브라우저에서 리포지토리를 탐색 할 때 렌더링되는 기본 마크 다운 파일이다. 또한 .gitignore 파일을 사용하여 저장소를 사전 구성 할 수 있다. 이 파일은 이름 지정 패턴 및/또는 경로를 기반으로 소스 제어에서 무시할 파일을 지정한다. 작성중인 프로젝트 유형에 따라 무시할 공통 패턴 및 경로를 포함하는 여러 템플릿이 있다. Create repository를 클릭한다.

 

3. 이게 전부다. 레포지토리가 준비되었다. 이제 Visual Studio 또는 선택한 도구를 사용하여 복제 할 수 있다.

 

 

과제 2: 리포지토리 이름 변경하기 및 삭제하기

1. 때로는 repo의 이름을 변경거나 삭제해야 할 때도 있다. Settings로 이동한다.

 

2. 여기에서 저장소 이름을 업데이트 할 수 있다.

 

3. settings 보기의 Danger Zone 섹션에서 Delete this repository를 클릭한다.

 

4. 전체 저장소 이름을 입력하고 옵션을 클릭하여 저장소를 삭제한다.