[Git] VisualStudioCode 내장 Git 활용

개발자들은 깃허브를 통해 본인의 프로필, 포트폴리오 등을 만들기도하고

 

업무를보고 형상관리를 한다고 한다

 

개발자에게 필수라고 말하는 깃허브를 잘 다뤄보고자 공부해야겠다는 생각을 했고

 

부스트코스에 github 강의가 있어 학습해보았고 내용을 정리해 봤다

 

이 강의에서는 비주얼 스튜디오 내장 깃을 이용해서 진행했다

 

 

# Git 기초

1) Git

소프트웨어 개발을 할 때, 여러 사람이 참여하는 방식으로 개발의 효율을 올리곤 한다

이때 중요한 점은 팀원들이 개발 도중에는 수정된 내역을 다른 팀원이 바로 확인하고

또 서비스에서는 배포된 소프트웨어의 버전 관리를 통해 개발의 효율성을 높일 수 있을 것이다

git은 소프트웨어 버전관리 시스템(VCS, Version Control System)의 한 종류 이다

"프로그램의 소스코드를 관리하는 프로그램"인 것이다

 

 

2) Git server & Git client

git은 여러가지 버전 관리 시스템 중에서도 분산된 환경을 통해 소스코드를 관리한다

분산 환경 시스템에는 중앙서버와 클라이언트가 존재하게 된다

이때 코드를 모아놓게되는 원격 컴퓨터를 remote server

그 코드들의 사본을 받아 개발하는 개인/지역 컴퓨터를 local client라고 해보자

git에서도 git server와 git client가 존재한다

git client는 git server의 사본을 가지고 각자의 로컬 환경에서 개발을 할 수 있다

git client와 git server의 종류는 아래와 같다

 

git client : git CLI(Command-line interface), Visual Studio Code에 내장되어 있는 git

 

git server : github.com, gitlab 등등

 

 

3) Repository

github상에서 우리의 프로그램을 담는 저장소를 말한다

repository에서는 우리 코드를 저장할 수 있을 뿐 아니라 커밋 히스토리,

pull request등 협업을 위한 여러 작업을 할 수 있다

개발하는 프로젝트를 담는 폴더라고 생각하면 된다

 

 

4) Commit

제출하다는 뜻을 갖고 있는 commit은 git 에서는 버전을 저장하는 것을 의미한다

빈 repository에 file을 여러번 업로드를 하고 이를 각각 commit 해본다

그러면 기존의 파일이 계속 업로드되고 어떤게 업로드 되었는지 확인 할 수 도 있다

우리는 commit history을 통해 이를 확인할 수 있고 어떻게 바뀌었는지도 알 수가 있다

 

 

5) Issues

우리는 개발을 하면서 여러 소통을 해야할 때가 많다

여기에는 bug가 발생해 debug을 해야하거나 새로운 기능을 만들어야하는 것도 포함될 것이다

이런 상황의 대부분은 코드를 보고 의견을 교환하며 해결해야하는 경우가 많다

issues는 repository에서 이러한 기능을 수행한다

issues에서는 'issue 생성'을 통해 해결하고 싶은 문제를 업로드하고 의견을 달 수 있다

이 때 해당 이슈가 어떤 것인지 알려주는 labels

해당 이슈를 처리할 사람이 누구인지 Assignee으로 지정할 수 있다

 

 

6) Clone

github의 repository의 내용을 내 컴퓨터(로컬) 환경에 복제하는 것을 말한다

이를 통해 로컬환경에서 github의 파일들을 받아서 개발을 할 수 있다

 

 

7) Git Config

로컬 환경에서 작업 후 commit을 진행할 때 누가 해당 커밋을 했는지 기록하고 확인할 필요가 있다

해당 작업을 수행하는 git 명령어가 git config 이다

 

git config --global user.name vuddus526
git config --global user.email vuddus526@naver.com

 

이는 git config에 global 옵션을 더해 해당 값을 기본값으로 활용하며 사용자의 이름, 사용자 이메일을 등록한다

 

git 최초설정

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

Git - Git Configuration

 

 

8) Push

열심히 로컬 환경에서 개발을 하며 중간중간 commit을 진행하고 난 이후

우리는 원격 저장소인 github에 업로드 할려고 한다 이때 활용하는 git 명령어가 git push이다

push가 되면 로컬 환경에서 개발한 코드 뿐 아니라 그동안 개발하면

중간중간 commit했던 이력들 또한 업로드 된다

 

 

9) Pull

우리가 로컬에서 개발을 하던 와중 다른 팀원이 본인의 작업물을 push 함으로

원격저장소에 변화가 생겼다

이때 원격저장소의 내용을 현재 내 로컬환경에 반영하고 합쳐 개발을 계속하고자 한다

이때 활용하는 명령어가 git pull 이다

git pull은 fetch와 merge가 동시에 진행이 된다

 

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EC%A0%80%EC%9E%A5%EC%86%8C

Git - 리모트 저장소

 

 

10) Fetch & Merge

git pull에서 했던 얘기를 다시 하자면

우리가 로컬 환경에서 작업하던중 원격저장소의 내용을 팀원이 수정했다

이때 우리가 개발한 내용을 원격저장소에 push를 할려고 하면 거절된다

그 이유는 원격저장소에는 팀원의 수정사항이 반영이 되어 있고, 이때 우리의 push를 받는 다면

팀원의 수정사항이 overwrite이 되는 상황이기 때문이다

이럴 땐 앞서 배운 것 처럼 pull을 통해 해결 할 수 있지만 fetch와 merge라는 과정으로 나눠서 진행할 수 있다

fetch는 원격저장소에 있는 내용을 로컬 저장소로 가져온다

이를 통해 로컬 저장소와 원격 저장소와의 차이를 비교할 수 있다

이를 통해 충돌되는 상황은 발생하지 않는 지, 충돌한다면 이를 어떻게 해결하면 좋을지를 확인 한 후

merge를 통해 두 브랜치를 병합한다

 

 

11) Init & Add

앞에서는 github의 repository를 먼저 만들고 clone하는 과정을 거쳐 원격저장소로부터

로컬 저장소를 구성할 수 있었다

그렇다면 반대로 로컬에서 개발하고 git을 이용해 형상관리를 하고

원격저장소에 업로드 할 수 있지 않을까?

이때 로컬저장소에 필요한 명령어가 git init이다

git init을 통해 로컬 저장소를 git을 통해 관리할 수 있게 된다

 

commit은 버전을 기록할 때 활용한다

commit을 할 때 여러 파일의 수정사항을 기록해도 좋지만

한 commit에 한 개의 파일의 수정사항만 저장할 수 있다면 다른 팀원들이 commit history를 볼 때

조금 더 수월하게 볼 수 있을 것 이다

이때 활용하는 명령어가 git add이다

git add는 git commit에 포함될 파일을 지정한다

git add를 통해 하나의 파일을 지정하면 해당 파일을 stage에 올려 해당 파일만 커밋 할 수 있다

 

https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EC%88%98%EC%A0%95%ED%95%98%EA%B3%A0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EA%B8%B0

Git - 수정하고 저장소에 저장하기

 

 

12) checkout

우리가 프로젝트를 진행하던 중 코드 상에 버그가 있어 코드가 실행이 되지 않는 다는 것을 알게 되었다

이때 우리가 할 수 있는 것은 무엇일까

우리가 commit을 잘해왔다면 해당 commit hisoty로 돌아갈 수 있다

그렇게 된다면 commit history에 있는 버전들을 활용해 조금 더 빠르게 debug를 할 수도 있다

이때 활용하는 명령어가 git checkout이다

git checkout을 활용해 기존의 commit hisotry로 저장소를 변경한 후 오류를 수정한 다음

다시 commit을 통해 버전을 업데이트 한다

 

일반 적으로 시간여행할 때는 checkout

복귀할때는 master에서 checkout branch를 해준다

 

 

13) Remote

로컬 저장소에서 시작한 프로젝트를 원격저장소와 연결과 관련된 명령어다

강의에서 나온 내용은 로컬 저장소에서 작업한 프로젝트를 새로운 원격저장소에

push를 하기 위해 git remote를 쓰고 이때 사용하는 명령어는 git remote add 이다

 

 

# Git을 통해 협업하기

1) Branch

우리가  큰 개발 프로젝트를 진행한다고 가정해보자

큰 개발 프로젝트를 진행할 땐 여러 개발 팀 혹은 팀원으로 나뉘어 동시에 개발을 한다

예를 들어 머신러닝 개발 프로젝트를 하는 팀에서는 데이터를 전처리하고 저장을 하는 팀,

모델을 개발하는팀, 모델을 서빙하는 팀이 있을 수 있다

각 팀 안에서는 버그를 수정하거나 새로운 기능을 개발을 해야하는 일이 많을 것이다

각 팀별로 버전을 관리할 필요성이 있다

이럴 때 각 팀에서는 개발 프로젝트의 소스코드를 바탕으로 개발을 해나가야할 것이다

이후 개발이 완성되면 프로젝트에 병합을 시켜 새로운 버전울 생성하여 다른 팀원들과 충돌 나지 않으면서

프로젝트를 진행할 수 있다

브랜치(branch)는 프로젝트를 바탕으로 독립적으로 개발을 할 수 있을 수 있는 저장소(작업영역)이다

저장소를 처음 만들 때 동시에 만들어지며 프로젝트 version을 관리하는 branch를 master branch라 한다

이후 기능 개발 시 master branch를 바탕으로 하거나 혹은 다른 branch를 바탕으로 또 다른 branch를 생성해

독립적으로 개발을 진행할 수 있다

 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

Git - 브랜치란 무엇인가

 

 

2) Merge into current branch

master branch를 바탕으로 새로운 기능 개발 혹은 버그를 고친다고 할 때 새로운 branch를 만들어 진행한다 이후 개발을 다 마치고 이를 master branch에 병합하여 새로운 버전을 만들고자 한다

이 때 우리는 Merge into current branch를 활용한다

Merge into current branch를 통해 master branch에 해당 기능 branch을 병합한다

이후 필요하지 않은 branch는 delete를 할 수 있다

 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88

Git - 브랜치와 Merge 의 기초

 

 

3) Git으로 협업하기

동료들과 함께 같은 저장소(Repository)를 바라보고 개발을 진행하고 있는 상황을 한번 재현해 보자

김왼손씨와 이오른씨가 같은 저장소(Repository)에 작업을 했다고 가정하자

김왼손씨는 오후에 약속이 있어서 아침 일찍 출근한 뒤 열심히 개발을 진행하고 개발 내용들을 각각 add하여 commit으로 나누어 저장 한 후 원격 저장소에 push한 후 퇴근 했다

이오른씨는 느긋하게 하루를 시작하려 오후에 출근해 김왼손씨와 같이 여러 파일을 수정하고 commit한 후 원격 저장소에 push! 하려는 그 때! 원격저장소는 오른씨의 push를 "reject" 해버린다

그 이유는 왼손씨가 개발한 내용들이 오른씨의 개발 내역에는 포함 되어 있지 않았기 때문이다

이대로 push가 진행 된다면 자칫 왼손씨가 개발한 부분에 오른씨의 개발 내용이 곂치게 되면서 덮어써져 날아가버릴 것이 분명해보인다

이럴경우! 오른씨는 앞서 배웠던 "pull" 기능을 통해서 원격 저장소에 새롭게 추가된 개발 내역을 현재 개발하고 있는 지역 저장소로 끌어 올 수 있다

또한 "pull"은 단계적으로 적용이 가능하다는 사실을 배웠다

바로 "fetch"와 "merge"인데 fetch를 사용해서 원격 저장소의 "변경 내용"을 다운로드 받고 merge를 사용해서 해당 변경 내용을 현재 지역 저장소로 반영 하는 절차를 거치게 된다

 

 

4) Conflict

앞서 살펴본 협업을 진행하다 보면 완벽하게 중복을 피할 수 있을까?

곰곰히 생각해보면 앞서서 했던 방식들이 중복을 근본적으로 피하게 해주진 않는 것 같다

결국 같은 파일의 같은 줄을 수정했다면 충돌은 피할 수 없다.

이 때, 어떻게 하면 충돌을 해결 할 수 있을까?

원격 저장소의 내용을 내려 받았을 때 충돌이 발생 한 경우 세 가지 경우 중 하나를 선택 하여

다시 commit해서 통합된 버전을 만드는 것인데 선택지는 다음과 같다

 

1. 원격 저장소의 코드를 수용하는 경우 (남이 만든 코드를 반영)

2. 지역 저장소의 코드를 반영하는 경우 (내가 만든 코드를 반영)

3. 두 가지를 모두 반영하는 경우 (두 가지를 다 고려하여 수정)

 

https://opentutorials.org/course/3840

GIT CLI - Branch & Conflict - 생활코딩

 

 

5) Pull request

프로그램을 개발하고 반영하는 일련의 과정들을 겪으면서 이제 정말 개발할 준비가 된 것 같다

master 브랜치에 질서 정연하게 push만 하면 되니까 하지만 내가 만든 내용들이 잘 작동하지 않거나

한번 검토가 필요할 때 바로 반영하기는 겁이난다 어떻게 하는 것이 좋을까?

바로 Pull request(줄여서 PR)을 활용하시면 된다

Pull request란 직접 master 브랜치에 push하는 것이 아닌 master 브랜치로 부터 새로운 브랜치를 만든 다음 개발 내역을 해당 브랜치에 적용하고 그 내용이 master에 반영되기 전 검토를 해달라는 요청을 보내어 팀원들과 리뷰를 마친 후 반영 하는 방식이다

그 과정이 아주 엄격하게 관리 될 수도 있고 아니면 간단한 리뷰를 통해서도 가능하다

 

 

6) Pull request에서 발생한 Conflict

코드를 작업하면서 발생 했던 conflict들이 pull request에서도 발생 할 수 있다

바로 같은 파일을 수정한 2개의 브랜치가 순서대로 merge되는 상황이 그렇다

앞에서 봤던 왼손씨와 오른씨의 개발과정을 기억나는가?

다시 두분의 이름을 빌려 예시를 들어 보자

왼손씨가 a.py를 수정하고 "left" 라는 브랜치에 push한 후 PR을 만들었다

하지만 공교롭게도 오른씨도 a.py를 수정하고 "right"라는 브랜치를 만들어 PR을 주었다

이때 먼저 왼손씨의 코드를 리뷰하고 master branch에 "left" 브랜치가 merge되는 순간!

"right"브랜치에서 conflict가 발생하게 된다

이때 까지 배운 개념들을 활용하면 이런 문제를 해결 해 볼 수 있다

침착하게 최신화된 master 브랜치를 "right" 브랜치에 pull 한 다음 다시 push 하면 해결 할 수 있다

 

https://opentutorials.org/course/4587/29480

수업소개 - 생활코딩