Git 뉴비를 위한 기초 사용법 - 시작하기

이번 포스팅에서는 너도 쓰고 나도 쓰고 우리 모두 쓰고 있는 Git의 기초에 대해서 포스팅 하려고한다. 필자는 Git을 대학교 때 처음 접했는데 처음에는 “왠 이상한 클라우드에 소스코드를 올려놓는다” 정도로만 이해하고 사용했던 기억이 난다. 하지만 Git의 기능은 단순히 코드 공유에서 끝나지 않는 버전 관리 도구이므로 Git을 잘 쓰면 실무에서 펼쳐지는 다이나믹한 상황에 유연하게 대처할수도 있다.

하지만 Git의 모든 기능을 이 포스팅에서 전부 다루기에는 지면이 부족하니, 이번에는 Git을 사용하기 위한 기본적인 명령어인 add, commit, push, pull, fetch에 대한 설명만 진행하도록 하겠다.

Git은 누가, 왜 만들었나요?

Git은 2005년 리누스 토르발즈가 자기가 쓰려고 만든 분산 버전 관리 시스템이다. 일단 이 리누스 토르발즈라는 핀란드 형부터가 개발자라면 대부분 알고 있을 정도로 유명하다.

아실 만한 분들은 다 아시겠지만 이 형은 오픈소스 커널인 리눅스(Linux)를 만든 사람이다. 리눅스 커널로 만든 유명한 운영체제는 데비안 계열의 우분투(Ubuntu), 레드햇 계열의 센트OS(CentOS) 등이 있다. 이 운영체제들은 서버에서도 많이 사용되고, 터미널의 기본 기능도 튼실해서 개발 친화적이기 때문에 개발자라면 대부분 알고 있는 운영체제이다. 참고로 안드로이드 OS도 리눅스 커널을 기반으로 만든 운영체제다.

뭐 어쨌든 이 형은 이 쪽 업계에서는 상당히 유명한데, 뭐 프로그래밍을 잘하거나 리눅스 커널 만든 걸로도 유명하지만 이런 걸로 더 유명하다.

세계 그래픽 카드 점유율 1위 기업한테 엿을 먹이는 패기

이게 대략 2012년 쯤인데, 어떤 포럼 연설에서 실제로 이렇게 엔비디아 엿먹으라고 했다. 당시에 엔비디아 옵티머스 칩을 사용하는 컴퓨터에서 리눅스로 만든 OS가 제대로 안굴러가는 이슈가 있었는데, 엔비디아가 지적재산권을 이유로 오픈소스 드라이버를 공개를 안했었기 때문에 리눅스의 설치가 힘들었던 것이다. 당시의 대화는 대략 이랬다.

[청중]
아 님… 엔비디아 옵티머스 칩 쓰는 노트북에 리눅스 까는게 너무 힘들어요ㅜㅜ 좋은 방법 없을까요?

[리누스]
…
난 우리가 하드웨어 제조업체들과 겪었던 최악의 문제 중 하나가 엔비디아라는 것을 이렇게 공개적으로 지적할 수 있어서 기쁘네요! 이건 조금 슬픈 일인데, 엔비디아는 안드로이드 시장에 많은 칩을 팔고 있지만 이 회사는 우리가 경험한 회사 중 진짜 최악입니다.

그러니까 엔비디아… 엿이나 먹어라

리누스는 이런 형이다. 참고로 리눅스 커널이 오픈소스라고 함부로 커밋했다가는 이 형한테 욕먹고 현타가 올 수도 있으니 마음 단단히 먹자. 이 형이 바로 이 업계의 고든 램지다.

근데 왜 이 형이 Git을 만들게 되었냐?

리누스는 리눅스 커널을 만들 당시에 BitKeeper라는 분산 버전 관리 시스템을 사용했는데, 이 Bitkeeper라는 서비스는 원래 유료였지만 리눅스 커뮤니티에는 무료로 제공해주고 있었다. 근데 이 커뮤니티의 개발자 한명이 BitKeeper의 통신 프로토콜을 리버스 엔지니어링해서 해킹하는 사건이 발생했고, Bitkeeper는 무료로 리눅스 커뮤니티에 서비스를 제공하던 것을 철회한 것이다.

근데 이걸 쓰지 말라고 막은 게 아니라 그냥 무료에서 유료로 돌린 거다. 근데 이 형이 돈내기는 싫었는지 그냥 자기가 분산 버전 관리 시스템을 2주 만에 뚝딱! 만들었는데 그게 바로 Git이다. (2달 아니고 2주 맞다…)

리누스가 Git을 처음 커밋했던 내용은 Github의 Git 미러 저장소에서 확인해볼 수 있는데 여기서도 리누스 형의 성격이 드러난다.

GIT - the stupid content tracker

“git” can mean anything, depending on your mood.

- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. The fact that it is a mispronounciation of “get” may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- “global information tracker”: you’re in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- “goddamn idiotic truckload of sh*t”: when it breaks

Linus Torvalds git/git/README.md

음, 이게 리누스가 한 첫번째 커밋의 README.md 파일의 일부를 가져온 것인데, Git은 그냥 아무 의미 없는 세글자 알파벳이라고 한다. 그냥 유닉스 명령어 중에 git이라는 명령어가 없어서 정했다고 한다. 기분이 좋으면 “global information tracker”라고 하고 기분이 구리면 “goddamn idiotic truckload of sh*t”이라고 하랜다. (진짜 이 세상 쿨함이 아니다.)

정리하자면 Git은 핀란드의 어떤 천재 형이 쓰던 버전 관리 도구가 갑자기 유료가 되서 2주만에 만들어낸 시스템이고, 지금은 전 세계적으로 널리 사용되고 있는 분산 버전 관리 시스템이다.

기초적인 개념 알아보기

Git은 분산 버전 관리 시스템이기 때문에 리모트 서버에 있는 소스를 수정하려면 로컬 환경으로 소스를 클론(Clone)하는 과정이 필요하다. 말 그대로 모든 소스를 복사하여 사용자의 컴퓨터로 받아오는 것이다.

이후 Git은 로컬 환경의 파일을 추적하고 있다가 사용자가 소스를 수정하면 그 변경 사항을 감지한다. 그 후 사용자는 자신이 리모트 서버에 변경 사항을 반영하고 싶은 파일이나 소스 코드의 라인을 고른 뒤 리모트 서버에 업로드한다.

맨 위의 `origin/master`는 리모트 서버의 버전, 맨 밑의 `master`는 필자 컴퓨터의 버전을 의미한다.

자 일단 Git에 대한 기본적인 개념은 이게 끝이다. 리모트 서버에 있는 파일을 내 컴퓨터로 복붙한 다음 수정해서 다시 리모트 서버로 업데이트한다는 것. 이때 사용자가 자신이 변경한 로컬의 소스를 서버의 소스에 업로드하는, 즉 서버로 밀어올리는 행위를 Push라고 부르고 사용자가 서버의 소스를 자신의 클라이언트로 가져오는 행위를 Pull 또는 Fetch라고 하는 것이다. 쉽지 않은가?

하지만 처음 Git을 접하면 평소에 접해보지 못했던 remote, origin, repository와 같은 용어들이 튀어 나오기 때문에 당황할 수 있다. 그럼 이 용어들이 무엇을 뜻하는지부터 간단하게 알아보자.

Remote / Origin

우선 Remote는 말 그대로 리모트 서버 자체를 의미한다. 이 리모트 서버라는 개념이 잘 이해가 안되시는 분은 우리가 자주 사용하는 구글 드라이브나 N드라이브와 같은 클라우드 스토리지를 사용하는 것을 떠올리시면 된다. 전 세계 어딘가에 있는 서버에 우리의 소스를 저장하는 것이다.

이때 이 서버를 제공해주는 대표적인 업체가 Github, Bitbucket, GitLab과 같은 회사들이다. 이 회사들이 Git을 만든 게 아니라 Git이라는 시스템에 필요한 리모트 서버와 Git을 좀 더 편리하게 사용할 수 있는 기능들을 제공하는 것이다.

Git을 사용할 때는 내가 어떤 리모트 서버에 변경 사항을 업로드 할 것인지 정해야하는데, 반드시 하나의 리모트 서버만 사용할 수 있는 것이 아니기 때문에 내가 사용하는 리모트 서버의 이름을 정해줘야한다. 이때 주로 사용하는 관례적인 이름이 바로 Origin이다.

보통은 한 개의 리모트 서버만 운용하는 경우가 대다수이기 때문에 많은 사람들이 Remote와 Origin을 혼용해서 부르곤 한다.

Repository

레파지토리(Repository, Repo)는 저장소라는 뜻으로, 리모트 서버 내에서 구분되는 프로젝트 단위라고 생각하면 된다. 우리가 구글 드라이브를 사용할 때도 하나의 디렉토리에 모든 파일을 다 때려넣지않고 몇 개의 디렉토리를 만들고 용도에 따라 파일을 나눠서 구분하는 것과 동일하다.

일반적으로 한 개의 레파지토리는 하나의 프로젝트를 의미하지만 경우에 따라서 레파지토리 하나에 여러 개의 프로젝트를 구성하기도 한다.

https://github.com/user/repository.git
https://user@bitbucket.org/group-name/repository.git

레파지토리를 클론받을 때는 해당 레파지토리를 가리키는 URL이 필요한데, 레파지토리의 이름은 URL의 맨 마지막에 .git 확장자를 가지는 방식으로 표현된다.

Branch

브랜치는 일종의 독립된 작업을 진행하기 위한 작업 공간의 개념이다. 맨 처음 Git을 초기화했을 때 기본적으로 master라는 이름의 브랜치가 하나 생성된다. 그 후 개발하는 기능 또는 버그 픽스에 따라서 브랜치를 새로 생성하고 거기서 작업한 후에 나중에 다시 master로 합치는 것이다.

master 브랜치에서 다른 브랜치를 분리한 모습

이 브랜치 개념은 Git에 익숙하지 않은 분들에게 잠깐 설명하고 넘어가기에는 직관적으로 이해가 잘 안될 수 있는 개념이기 때문에 추후 다른 포스팅에서 다시 설명하겠다. 일단 지금은 이 3가지 정도만 기억해두자.

1. Git을 초기화하면 기본적으로 master 브랜치가 생긴다. 이 친구가 메인 브랜치 역할을 한다.
2. 브랜치는 어떤 브랜치에서 분리시키는 것이고, 분리된 브랜치는 분리될 당시의 부모 브랜치 상태를 그대로 가지고 있다.
3. 개발자는 각각의 브랜치에서 개발을 진행한 뒤 나중에 다시 master 브랜치로 변경 사항을 합친다.

필수 명령어들을 알아보자

만약 여러분이 혼자서만 프로젝트의 버전 관리를 한다면 단순히 리모트 서버의 레파지토리에서 소스를 받아와서 변경한 후 다시 리모트 서버로 업로드하는 과정만으로도 프로젝트를 진행하는데는 사실 아무 문제가 없다.

하지만 Git은 애초에 혼자서 개발하는 상황보다는 여럿이서 함께 소스를 수정하며 개발하는 협업 상황을 상정하고 만들었기 때문에 협업에서 발생할 수 있는 여러가지 곤란한 상황들을 타파하기 위한 많은 기능을 가지고 있다.

Git은 기본적으로 CLI(Command Line Tools)을 통해 사용하고 commit, fetch, branch와 같은 여러가지 명령어를 사용하여 이 기능들을 사용할 수 있게 해준다.

그럼 이번에는 Git을 사용하여 버전을 관리하기 위해 기본적으로 알아야 하는 몇 가지 명령어를 한번 살펴보자.

리모트 서버와 연동하기

clone

clone은 말 그대로 리모트 서버의 레파지토리에서 클라이언트로 파일을 복붙하는 행위를 말한다. 이때 클론을 수행하기 위해서는 어떤 레파지토리에서 파일을 가져올 것인지에 대한 정보가 필요한데, 이 정보는 위에서 설명했듯이 URL로 표현한다. HTTPS 프로토콜이나 SSH 프로토콜을 사용하여 소스를 클론할 수 있는데, 보통 HTTPS를 많이 사용한다.

보통 Github과 같은 리모트 서버 제공업체들은 레파지토리를 쉽게 클론할 수 있도록 눈에 잘 띄는 버튼을 만들어 놓고 해당 레파지토리의 URL을 제공하는 경우가 많다. 사용자는 단지 저 URL을 복사한 다음 Git의 clone 명령어를 사용해서 레파지토리를 클론하기만 하면 된다.

$ cd ~/dev/evan # 원하는 작업 디렉토리로 이동
$ git clone https://github.com/evan-moon/test-repo.git

원하는 작업 디렉토리로 이동한 뒤 clone 명령어를 사용하여 레파지토리를 클론하게되면 현재 위치에 레파지토리 이름과 동일한 디렉토리가 생성되고 그 내부에 리모트 서버의 소스가 전부 복사된다. 위 예제의 경우 ~/dev/evan 디렉토리 내부에 test-repo 디렉토리가 생성되고 해당 레파지토리의 소스가 복사될 것이다.

이제 이 복사된 소스를 맘대로 수정하거나 파괴해도 리모트 서버에 업로드만 하지 않는다면, 같은 리모트 서버를 보고 있는 다른 사람이 영향을 받을 일은 절대 없기 때문에 안심하고 맘대로 만지작거려도 된다.

pull

pull 명령어는 리모트 서버의 최신 소스를 가져와서 로컬 소스에 병합(Merge)해주는 명령어이다. 만약 우리가 처음 소스를 클론한 후에 다른 사람이 리모트 서버를 상태를 갱신했더라도 리모트 서버가 우리에게 그 변경된 사항을 알려주지는 않기 때문에 우리가 직접 서버에 문의를 날려야 하는 것이다.

또한 pull은 단순히 리모트 서버에서 로컬로 소스를 가져온다의 개념보다는 가져와서 합친다의 개념이기 때문에 브랜치끼리도 pull을 통해 소스를 합칠 수 있다.

$ git pull # 현재 내 로컬 브랜치와 같은 이름을 가진 리모트 서버 브랜치가 타겟
$ git pull origin master # origin 리모트 서버의 master 브랜치가 타겟

오픈소스에 관심이 많은 분이라면 Pull Request라는 단어를 들어보았을 것이다. 이 Pull Request는 “내가 작업한 브랜치를 가져가서 합쳐줘~“라는 의미이다.

필자는 처음에 이게 왜 Merge Request가 아니라 Pull Request인지 이해가 잘 안갔었는데, 나중에 와서 생각해보니 최종적으로 두 브랜치의 소스를 합치는 행위를 하는 주체가 요청을 한 사람이 아니고 요청을 받은 사람이기 때문에 요청을 받은 사람이 브랜치를 가져가서 합친다는 관점에서 보면 적절한 네이밍인 것 같다는 생각을 했었다.

fetch

fetch는 리모트 서버의 최신 이력을 내 클라이언트로 가져오되 병합은 하지 않는 명령어이다.

$ git fetch

fetch 명령어를 사용하면 다른 사람들이 리모트 서버에 새로 업데이트한 모든 내역을 받아올 수 있다. 이제 그 내역을 보고 내 로컬에 있는 버전이 리모트 서버에 있는 버전보다 이전 버전이라면 pull 명령어를 사용하여 내 컴퓨터의 소스 코드를 갱신하면 된다.

그럼 이 명령어가 pull의 하위 호환이 아닌가? 라는 생각이 들 수도 있는데, pull과 fetch는 조금 용도가 다르긴 하다. pull 같은 경우는 일단 묻지도 따지지도 않고 바로 리모트 서버의 최신 소스를 가져와서 내 로컬 소스에 합쳐버리기 때문에 조금 위험하긴 하다. 뭐 예를 들면 지금 리모트 서버의 최신 소스가 버그가 있는 상태일 수도 있지 않은가?

그래서 필자같은 경우 보통 로컬 소스와 리모트 소스의 변경 사항을 미리 비교해보고 싶을 때 fetch를 사용한다. 그리고 fetch를 잘 이용하면 이런 얌생이도 가능하다.

#!/bin/bash

git fetch --all -p; git branch -vv | grep ": gone]" | awk '{ print $1 }' | xargs -n 1 git branch -d

이 쉘스크립트는 필자가 예전에 만들어 놨던 친구이다. fetch를 통해 리모트 서버의 최신 내용을 받아온 뒤, branch 명령어를 사용하여 리모트 서버에서는 삭제되었지만 로컬에는 남아있는 브랜치를 찾아서 싹 다 지워주는 스크립트이다. 참고로 로컬에는 있지만 리모트에서 삭제된 브랜치는 브랜치 이름 뒤에 : gone이라는 문구가 붙어있기 때문에 구분이 가능하다.

$ git branch -vv
* master fa0cec5 [origin/master] 마스터 브랜치에욤
  test   1f3578f [origin/test: gone] 리모트에선 죽은 브랜치
  test2  fa0cec5 로컬에서 만들어지고 리모트에 업데이트는 안된 브랜치

fetch 명령어와 branch 명령어의 특성을 잘 이용하면 이런 꿀 스크립트를 만들 수도 있다.

변경 사항을 리모트 서버에 업데이트하기

자, 지금까지는 리모트 서버의 내용을 로컬과 연동하는 명령어를 살펴봤다면 이제는 내 로컬에서 변경한 소스를 리모트 서버로 업로드하는 명령어들을 살펴볼 차례이다. 필자는 이 과정을 설명할 때 보통 택배로 예를 주로 드는 편이기 때문에 이 포스팅에서도 택배를 포장하고 배송하는 과정에 빗대어서 설명을 진행하겠다.

add

원하는 변경사항만 골라 담는 add 명령어

자, 평화로운 중*나라에서 중고 거래를 했다고 생각해보자. 물론 집에 있는 모든 물건을 보내는 혜자같은 분도 계시겠지만 일반인이라면 그러지 않기 때문에 우리는 상대방한테 물건을 보내기 전에 어떤 물건을 보낼 것인지 부터 정해야한다. 이때 add 명령어가 어떤 물건들을 포장할 것인지 고르는 과정을 담당한다.

$ git add . # 현재 디렉토리의 모든 변경사항을 스테이지에 올린다
$ git add ./src/components # components 디렉토리의 모든 변경사항을 스테이지에 올린다
$ git add ./src/components/Test.vue # 특정 파일의 변경사항만 스테이지에 올린다
$ git add -p # 변경된 사항을 하나하나 살펴보면서 스테이지에 올린다

이때 선택된 변경 사항들은 스테이지(Stage)라고 불리는 공간으로 이동하게 된다. 이때 git add <경로> 명령어는 해당 경로 안에 있는 변경 사항을 전부 스테이지에 올리게 되는데, 이게 영 불안하다 싶은 사람은 -p 옵션을 줌으로써 변경 사항을 하나하나 확인하면서 스테이지에 올릴 수도 있다.

이렇게 스테이지에 담긴 변경 사항들은 git status 명령어를 사용하여 확인해볼 수 있고, status 명령어에 추가적으로 -v 옵션을 사용하면 어떤 파일의 어떤 부분이 변경되었는지도 함께 볼 수 있다.

$ git add ./soruce
$ git status

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   source/_drafts/git-tutorial.md

commit

변경 사항들을 포장하는 commit 명령어

add를 사용하여 원하는 변경사항을 스테이지에 올렸다면 이제 스테이지에 있는 변경 사항들을 포장할 차례이다. 이때 이 포장하는 행위를 commit이라고 한다. 커밋은 Git에서 상당히 중요한 부분을 차지하는 행위인데, 바로 Git이 하나의 커밋을 하나의 버전으로 정의하기 때문이다. 그렇기 때문에 특정 버전으로 어플리케이션을 변경이라는 기준도 당연히 바로 이 커밋이 된다.

$ git log --graph

* commit 20f1ea9 (HEAD -> master, origin/master, origin/HEAD)
| Author: Evan Moon <bboydart91@gmail.com>
|
|     회원가입 기능 개발 끝!
|
* commit ca693fd
| Author: Evan Moon <bboydart91@gmail.com>
|
|     회원가입 비밀번호 입력 폼 추가
|
* commit f9b6e2d
| Author: Evan Moon <bboydart91@gmail.com>
|
|     회원가입 이메일 입력 폼 추가
|

위의 그래프 상에서 필자의 어플리케이션의 현재 상태는 어떤 커밋일까?

그래프 상에서 HEAD가 20f1ea9 회원가입 기능 개발 끝! 커밋에 위치해 있으므로 현재 필자의 어플리케이션은 회원가입 기능까지 개발이 완료된 상태라는 것을 알 수 있다.

그리고 그래프를 자세히 보면 각각의 커밋들은 20f1ea9과 같은 고유한 해쉬 값을 가지고 있는데, 이 해쉬 값을 사용하여 어떠한 커밋으로든 자유자재로 이동할 수 있다. 예를 들면 회원가입 비밀번호 입력 폼 추가 커밋의 해쉬 값을 사용하여 git checkout ca693fd 명령어로 회원가입 비밀번호 입력 폼이 추가된 시점으로 이동할 수 있다는 것이다. 즉, 시간여행이 가능하다!

이러한 커밋의 기능을 제대로 활용하기 위해서 커밋은 반드시 실행 가능한 단위로 해야한다. 더 쉽게 말하자면 특정 커밋으로 버전을 변경했을 때 어플리케이션이 제대로 실행되지 않고 에러가 발생하면 안된다는 것이다.

그리고 위의 예제에서 볼 수 있듯이 커밋에는 메세지를 담을 수 있다. 이 메세지는 이 커밋으로 인한 변경 사항이 무엇인지 직접적으로 표현해주는 유일한 수단이므로 좋은 커밋 메세지를 작성하기 위한 고민은 필수다. 다행히도 이미 많은 개발자 분들이 좋은 커밋 메세지를 어떻게 작성해야 하는지에 대해 포스팅을 해주셨기 때문에 구글에서 한번 검색해보면 수두룩하게 나온다.

참고로 커밋 메세지는 꼭 영어여야 할 필요는 없다. 조직에 따라서 커밋 메세지를 영어로만 작성하도록 강제하는 룰이 있을 수는 있지만, 사실 커밋 메세지는 결국 커뮤니케이션 수단이므로 언제 누가 보더라도 알아보기 쉽게만 작성하면 장땡이다. 그러니까 영어가 익숙하지 않은데도 불구하고 굳이 영어를 고집할 필요는 없다. 오히려 같이 협업하는 팀원들이 영어에 익숙하지 않다면 그 또한 불필요한 커뮤니케이션 비용이 될 수 있다.

또한 커밋은 아직 리모트 서버에 파일을 전송하는 것이 아니라 사용자의 클라이언트 내에서 수행되는 과정이므로 인터넷에 연결이 되어 있지 않아도 변경 사항을 커밋하는 것은 아무런 지장이 없다.(비행기에서 코딩할 때도 커밋까지는 가능하다!)

사실 필자는 Git 뉴비일 때 이 커밋이라는 단어가 조금 헷갈렸었는데, 많은 개발자 분들이 commit과 push를 같은 의미로 사용하기 때문이었다. 하지만 이 두 명령어는 엄연히 다른 역할을 하기 때문에 되도록이면 구분해서 사용하도록 하자.

push

변경 사항들을 리모트 서버로 배송하는 push 명령어

커밋을 통해 포장된 변경 사항들은 push 명령어를 사용하여 리모트 서버로 업로드 된다. 이때는 커밋된 변경 사항들을 실제 리모트 서버에 전송하는 것이기 때문에 반드시 네트워크에 연결이 되어있어야 한다. 그리고 푸쉬할 때 반드시 A 로컬 브랜치는 A 리모트 브랜치에만 푸쉬해야 한다는 룰 따윈 없기 때문에 커밋들을 리모트 서버로 푸쉬할 때는 Git에게 “어떤 리모트 서버의 어떤 브랜치로 푸쉬할 것인지”도 함께 알려줘야 한다.

$ git push origin master # origin 리모트 서버의 master 브랜치로 푸쉬해줘!

근데 이게 브랜치 이름이 master정도면 그래도 브랜치 이름을 매번 입력해줄만 하지만 feature/SD-0000-request-api-refactoring 정도 되면 브랜치 이름을 매번 입력한다는 것이 귀찮을 수도 있다.

그래서 Git은 브랜치를 자동으로 추적할 수 있는 기능 또한 제공해준다.

$ git push --set-upstream origin master

--set-upstream 옵션을 사용하고 처음 한번만 브랜치 이름을 입력해주면 그 이후로는 git push 명령어만 입력해도 자동으로 처음 입력했던 브랜치로 변경 사항을 푸쉬할 수 있다.

이렇게 해서 리모트 서버의 레파지토리에서 소스를 내 컴퓨터에 받아온 뒤 파일을 변경하고, 그 변경 사항을 리모트 서버에 다시 업데이트하는 clone -> 파일 수정 -> add -> commit -> push과정을 한번 살펴보았다.

마치며

사실 블로그 포스팅 한개로 Git에 대한 것들을 모두 설명한다는 것은 힘들기 때문에 다음 포스팅에서는 branch, checkout, merge, revert와 같이 버전을 실제로 관리하기 위해 사용하는 명령어와 그 개념에 대한 내용을 포스팅하려고 한다.

Git은 현업에서 굉장히 많이 사용되고 있지만 정작 대학이나 학원같은 교육 기관에서는 약간 쩌리 취급 받는 것 같기도 하다. 뭐 사실 대학에서는 좀 더 원론적인 공학을 배우는 거지 코딩을 알려주는 곳은 아니기도 하고, 학원 같은 경우는 버전 관리 시스템을 가르칠 시간에 코딩을 알려주는 게 더 취업에 유리하니 그럴 수도 있을 것 같다. (요즘에는 대학에 강사 분들이 오셔서 Git에 대해 강의하는 경우도 있다고 한다.)

어쨌든 Git을 잘쓰면 다른 개발자가 개발한 모듈 중에 하나만 내 브랜치로 가져와야 한다거나, 커밋이 꼬여서 소스가 지워졌다거나하는 등 프로젝트를 진행할 때 발생하는 슬픈 상황들을 잘 헤결할 수도 있기 때문에 팀원들에게 이쁨받는 개발자가 될 수(도) 있다.

이상으로 Git 뉴비를 위한 기초 사용법 - 시작하기 포스팅을 마친다.

• Git은 누가, 왜 만들었나요?

• 기초적인 개념 알아보기

  • Remote / Origin
  • Repository
  • Branch
• 필수 명령어들을 알아보자

• 리모트 서버와 연동하기

  • clone
  • pull
  • fetch

• 변경 사항을 리모트 서버에 업데이트하기

  • add
  • commit
  • push
• 마치며