just do it

branch

우리가  큰 개발 프로젝트를 진행한다고 가정해봅시다. 큰 개발 프로젝트를 진행할 땐 여러 개발 팀 혹은 팀원으로 나뉘어 동시에 개발을 합니다. 예를 들어, 머신러닝 개발 프로젝트를 하는 팀에서는 데이터를 전처리하고 저장을 하는 팀, 모델을 개발하는팀, 모델을 서빙하는 팀이 있을 수 있겠죠. 각 팀 안에서는 버그를 수정하거나 새로운 기능을 개발을 해야하는 일이 많을 것입니다.  각 팀별로 버전을 관리할 필요성이 있습니다. 이럴 때, 각 팀에서는 개발 프로젝트의 소스코드를 바탕으로 개발을 해나가야할 것입니다.  이후 개발이 완성되면 프로젝트에 병합을 시켜 새로운 버전울 생성하여 다른 팀원들과 충돌 나지 않으면서 프로젝트를 진행할 수 있겠죠.

브랜치(branch)는 프로젝트을 바탕으로 독립적으로 개발을 할 수 있을 수 있는 저장소(작업영역)입니다. 저장소를 처음 만들 때, 동시에 만들어지며 프로젝트 version을 관리하는 branch를 master branch라 합니다. 이후 기능 개발 시 master branch를 바탕으로 하거나 혹은 다른 branch를 바탕으로 또 다른 branch를 생성해 독립적으로 개발을 진행할 수 있습니다.

Merge into current branch

master branch를 바탕으로 새로운 기능 개발 혹은 버그를 고친다고 할 때 새로운 branch를 만들어 진행합니다. 이후 개발을 다 마치고 이를 master branch에 병합하여 새로운 버전을 만들고자 합니다. 이 때 우리는 Merge into current branch를 활용합니다. Merge into current branch를 통해 master branch에 해당 기능 branch을 병합합니다. 이후 필요하지 않은 branch는 delete를 할 수 있습니다. 

Conflict

앞서 살펴본 협업을 진행하다 보면, 완벽하게 중복을 피할 수 있을까요?! 곰곰히 생각해보면 앞서서 했던 방식들이 중복을 근본적으로 피하게 해주진 않는 것 같아요. 결국 같은 파일의 같은 줄을 수정했다면 충돌은 피할 수 없습니다. 이 때, 어떻게 하면 충돌을 해결 할 수 있을까요? 원격 저장소의 내용을 내려 받았을 때, 충돌이 발생 한 경우 세 가지 경우 중 하나를 선택 하여 다시 commit해서 통합된 버전을 만드는 것인데요. 선택지는 다음과 같습니다.

1. 원격 저장소의 코드를 수용하는 경우 (남이 만든 코드를 반영)
2. 지역 저장소의 코드를 반영하는 경우 (내가 만든 코드를 반영)
3. 두 가지를 모두 반영하는 경우 (두 가지를 다 고려하여 수정)

다음 강의에서는 VScode의 기능을 통해 편리하게 위와 같은 방식의 해결책을 보여줍니다.

Pull request

프로그램을 개발하고 반영하는 일련의 과정들을 겪으면서, 이제 정말 개발할 준비가 된 것 같습니다. master 브랜치에 질서 정연하게 push만 하면 되는 거잖아요? 됐습니다! 어.. 하지만 제가 만든 내용들이 잘 작동하지 않거나 한번 검토가 필요할 때 바로 반영하기는 겁이나네요, 어떻게 하는 것이 좋을까요?? 바로 Pull request(줄여서 PR)을 활용하시면 됩니다. Pull request란 직접 master 브랜치에 push하는 것이 아닌 master 브랜치로 부터 새로운 브랜치를 만든 다음 개발 내역을 해당 브랜치에 적용하고, 그 내용이 master에 반영되기 전 검토를 해달라는 요청을 보내어 팀원들과 리뷰를 마친 후 반영 하는 방식입니다. 그 과정이 아주 엄격하게 관리 될 수도 있고, 아니면 간단한 리뷰를 통해서도 가능합니다. 

Git이란?

Git은 형상 관리 도구 중 하나로, 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.

출처 : 위키백과

• Git은 소프트웨어 개발에서 소스 코드를 효과적으로 관리할 수 있도록 하는 무료, 공개 소프트웨어입니다.
• Git은 프로젝트 폴더 내에서 작업을 기록하고, 버전 관리를 통해 체계적인 개발이 가능하도록 합니다.

Github란?

깃허브(Github)는 분산 버전 관리 툴인 깃(Git)를 사용하는 프로젝트를 지원하는 웹호스팅 서비스이다.

출처 : 위키백과

github는 버전 관리와 협업을 위한 코드 웹 호스팅 플랫폼으로, 언제, 어디서나 협업 프로젝트를 쉽게 진행할 수 있도록 돕는 역할을 합니다!

Git server & Git client

git은 여러가지 버전 관리 시스템 중에서도, 분산된 환경을 통해 소스코드를 관리합니다. 분산 환경 시스템에는 중앙서버와 클라이언트가 존재하게 됩니다. 이때 코드를 모아놓게되는 원격 컴퓨터를 remote server 그 코드들의 사본을 받아 개발하는 개인/지역 컴퓨터를 local client라고 해봅시다. Git에서도 git server와 git client가 존재합니다. git client는 git server의 사본을 가지고 각자의 로컬 환경에서 개발을 할 수 있습니다. git client와 git server의 종류는 아래와 같습니다.

git client

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

git server 

ex) github.com, gitlab등등

Repository

github상에서 우리의 프로그램을 담는 저장소를 말합니다. Repository에서는 우리 코드를 저장할 수 있을 뿐 아니라 커밋 히스토리, pull request등 협업을 위한 여러 작업을 할 수 있습니다. 개발하는 프로젝트를 담는 폴더라고 생각하시면 됩니다.

Commit

제출하다는 뜻을 갖고 있는 commit은 git 에서는 버전을 저장하는 것을 의미합니다. 이번 강의에서는 빈 repository에 file을 여러번 업로드를 하고 이를 각각 commit 해봅니다. 우리는 commit history을 통해 이를 확인할 수 있고 어떻게 바뀌었는지도 알 수가 있습니다.

Git issues

우리는 개발을 하면서 여러 소통을 해야할 때가 많죠. 여기에는 bug가 발생해 debug을 해야하거나 새로운 기능을 만들어야하는 것도 포함될 것입니다. 이런 상황의 대부분은 코드를 보고 의견을 교환하며 해결해야하는 경우가 많습니다. issues는 repository에서 이러한 기능을 수행합니다. issues에서는 'issue 생성'을 통해 해결하고 싶은 문제를 업로드하고 의견을 달 수 있습니다. 이 때 해당 이슈가 어떤 것인지 알려주는 labels, 해당 이슈를 처리할 사람이 누구인지 Assignee으로 지정할 수 있습니다. 

Git clone

github의 repository의 내용을 내 컴퓨터(로컬) 환경에 복제하는 것을 말합니다. 이를 통해 로컬환경에서 github의 파일들을 받아서 개발을 할 수 있습니다.

Git config

로컬 환경에서 작업 후 commit을 진행할 때, 누가 해당 커밋을 했는지 기록하고 확인할 필요가 있겠죠? 해당 작업을 수행하는 git 명령어가 git config 입니다. 수업에서 알려주신 명령어는 아래와 같습니다.

git config -- global user.name egoing
git config -- global user.email egoing@gmail.com

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

Git push

열심히 로컬 환경에서 개발을 하며 중간중간 commit을 진행하고 난 이후 우리는 원격 저장소인 github에 업로드 할려고 합니다. 이때 활용하는 git 명령어가 git push입니다. push가 되면 로컬 환경에서 개발한 코드 뿐 아니라 그동안 개발하면 중간중간 commit했던 이력들 또한 업로드 됩니다. 

Git pull

우리가 로컬에서 개발을 하던 와중 다른 팀원이 본인의 작업물을 push 함으로 원격저장소에 변화가 생겼습니다. 이때 원격저장소의 내용을 현재 내 로컬환경에 반영하고 합쳐 개발을 계속하고자 합니다. 이때 활용하는 명령어가 git pull입니다. git pull은 fetch와 merge가 동시에 진행이 됩니다.

Git fetch & merge

git pull에서 했던 얘기를 다시 해볼게요. 우리가 로컬 환경에서 작업하던중 원격저장소의 내용을 팀원이 수정했습니다. 이때 우리가 개발한 내용을 원격저장소에 push를 할려고 하면 거절됩니다. 그 이유는 원격저장소에는 팀원의 수정사항이 반영이 되어 있고, 이때 우리의 push를 받는 다면 팀원의 수정사항이 overwrite이 되는 상황이기 때문이죠. 이럴 땐 어떻게 해야할까요? 앞서 배운 것 처럼 pull을 통해 해결 할 수 있지만 fetch와 merge라는 과정으로 나눠서 진행할 수 있습니다.

fetch는 원격저장소에 있는 내용을 로컬 저장소로 가져옵니다. 이를 통해 로컬 저장소와 원격 저장소와의 차이를 비교할 수 있습니다. 이를 통해 충돌되는 상황은 발생하지 않는 지, 충돌한다면 이를 어떻게 해결하면 좋을지를 확인 한 후 merge를 통해 두 브랜치를 병합합니다. 브랜치와 merge의 경우, 이후 강의를 통해 조금 더 배워보실 수 있습니다.

Git init

지난 수업까지는 github의 repository를 먼저 만들고 clone하는 과정을 거쳐 원격저장소로부터 로컬 저장소를 구성할 수 있었습니다. 그렇다면 반대로 로컬에서 개발하고 git을 이용해 형상관리를 하고 원격저장소에 업로드 할 수 있지는 않을까요? 이때 로컬저장소에 필요한 명령어가 git init입니다. git init을 통해 로컬 저장소를 git을 통해 관리할 수 있게 됩니다. 

Git add

commit은 버전을 기록할 때 활용합니다. commit을 할 때 여러 파일의 수정사항을 기록해도 좋지만, 한 commit에 한 개의 파일의 수정사항만 저장할 수 있다면 다른 팀원들이 commit history를 볼 때 조금 더 수월하게 볼 수 있을 것 입니다. 이때 활용하는 명령어가 git add입니다. git add는 git commit에 포함될 파일을 지정합니다. git add를 통해 하나의 파일을 지정하면 해당 파일을 stage에 올린다 합니다. 

Git checkout

우리가 프로젝트를 진행하던 중 코드 상에 버그가 있어 코드가 실행이 되지 않는 다는 것을 알게 되었습니다. 이때, 우리가 할 수 있는 것은 무엇일까요? 우리가 commit을 잘해왔다면 해당 commit hisoty로 돌아갈 수 있습니다. 그렇게 된다면 commit history에 있는 버전들을 활용해 조금 더 빠르게 debug를 할 수도 있습니다. 이때 활용하는 명령어가 git checkout입니다. git checkout을 활용해 기존의 commit hisotry로 저장소를 변경한 후 오류를 수정한 다음 다시 commit을 통해 버전을 업데이트 합니다. (checkout은 head를 바꾼다.)

Git remote

로컬 저장소에서 시작한 프로젝트를 원격저장소와 연결과 관련된 명령어입니다. 강의에서 나온 내용은 로컬 저장소에서 작업한 프로젝트를 새로운 원격저장소에 push를 하기 위해 git remote를 씁니다. 이때 사용하는 명령어는 git remote add 입니다.