[Github으로 따라하는 버전 관리] Git 기초

Git 잘해보이는 햄찌

Git

소프트웨어 개발을 할 때, 여러 사람이 참여하는 방식으로 개발의 효율을 올린다. 팀원들이 개발 도중에는 수정된 내역을 다른 팀원들이 바로 확인하고, 또 서비스에서는 배포된 소프트웨어의 버전 관리를 통해 개발의 효율성을 높일 수 있을 것이다. Git은 소프트웨어 버전관리 시스템(VCS, Version Control System)의 한 종류다. "프로그램의 소스코드를 관리하는 프로그램"인 것이다.

​

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 : gihub.com, gitlab 등

​

Repository

Github 상에서 우리의 프로그램을 담는 저장소를 뜻한다. Repository에서는 우리 코드를 저장할 수 있을 뿐만 아니라 Commit History, Pull request 등 협업을 위한 여러 작업을 할 수 있다. 개발하는 프로젝트를 담는 폴더라고 생각하면 된다.

​

Commit

제출한다는 뜻을 갖고 있는 Commit은 Git에서는 버전을 저장하는 것을 의미한다. Commit history를 통해 어떻게 바뀌었는지를 확인할 수 있고, Browse files를 통해 그 파일이 생겼던 시점으로도 돌아갈 수 있다.

​

Issues

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

​

Clone

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

​

Git Config

로컬 환경에서 작업 후 commit을 진행할 때, 누가 해당 커밋을 했는지 기록하고 확인하게 해주는 git 명령어가 git config이다.

git config -- global user.name brightstar git config -- global user.email chogus99@naver.com

 

Push

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

원격 저장소(github) : main | origin, main | head

로컬 저장소(컴퓨터)

 

Pull

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

​

Fetch & Merge

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

fetch는 원격 저장소에 있는 내용을 로컬 저장소로 가져온다. 이를 통해 로컬 저장소와 원격 저장소와의 차이를 비교할 수 있다. 이를 통해 충돌되는 상황은 발생하지 않는지, 충돌한다면 이를 어떻게 해결하면 좋을지를 확인한 후 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에 올린다고 한다.

working directory : 우리가 실제 작업하는 파일

 

Git checkout

commit을 잘해왔다면 해당 commit history로 돌아가서 코드 상의 버그를 해결할 수 있다. commit history에 있는 버전들을 활용해 debug를 한다는 말이다. 이 때 활용하는 명령어가 git checkout이다. git checkout을 활용해 기존의 commit history로 저장소를 변경한 후 오류를 수정한 다음 다시 commit을 통해 버전을 업데이트한다.

​

Git remote

로컬 저장소에서 시작한 프로젝트를 원격 저장소와 연결하는 명령어이다. 로컬 저장소에서 작업한 프로젝트를 새로운 원격저장소에 push를 하기 위해 git remote를 쓴다. 이 때 사용하는 명령어는 git remote add 이다.

Head : 현재 working directory의 버전

origin(내가 설정한 remote name) : 마지막 버전이 어디었는지

push를 통해 로컬과 원격 저장소의 버전을 서로 맞춰준다.