PlanB의 백엔드 엔지니어링

만들어진 디렉토리에서 git init을 이용해 로컬 저장소를 만들어 여러가지 명령어들을 이용해 Untracked 파일들을 인덱스로 staging하여 Tracked로 바꾸기도 하고, commit으로 변경 이력을 등록하기도 했습니다. git push는 로컬 저장소에 Commit해둔 변경 이력을 원격 저장소로 반영하는 일인데, 원격 저장소를 생성해 두지 않았다면 remote를 설정할 수 없으니 이번엔 원격 저장소를 생성하도록 해 봅시다.

저장소 만들기

원격 저장소 생성과 관리를 도와주는 서비스는 GitHub, GitLab, BitBucket 등이 있습니다. 우리는 이들 중 가장 보편적으로 사용하는 GitHub를 사용해 보도록 합시다.

GitHub에 계정을 만들고, 우측 상단의 + 버튼을 클릭해 드롭다운의 New repository를 선택합니다.

Repository name을 입력하고, 초록색 'Create repository' 버튼을 클릭합니다. 그러면 저장소가 생성됩니다.

git remote add [name] [url]

git init으로 생성한 로컬 저장소는, 원격 저장소와의 연결을 위해 remote를 설정해 주어야 합니다. remote의 이름은 git의 관례 상 origin을 사용하며, 다른 이름을 사용해도 상관 없습니다.

$ git remote add some https://github.com/~/~.git

이 경우 some이라는 이름의 remote가 설정됩니다. remote -v 명령으로 원격 저장소에 대한 정보들을 확인해 봅시다.

$ git remote -v
some    https://github.com/~/~.git (fetch)
some    https://github.com/~/~.git (push)

git clone [url]

원격 저장소의 정보를 가져와 로컬 저장소를 생성하려면, git clone을 사용합니다. 만들어 둔 원격 저장소에서 초록색의 'Clone or download' 메뉴를 확인할 수 있을 것입니다.

해당 URL을 복사해서, clone 명령의 파라미터로 넘겨주도록 합시다.

$ git clone https://github.com/~/~.git

이제 clone 명령을 수행한 위치에 해당 원격 저장소의 이름과 동일한 디렉토리가 생성될 것입니다. remote가 설정되어 있는 로컬 저장소가 생성된 것입니다. remote -v 명령으로 현재 프로젝트에 등록된 원격 저장소를 확인해 보면, 실제로 origin이라는 이름의 remote가 자동으로 등록되어 있는 것을 볼 수 있습니다.

$ git remote -v
origin    https://github.com/~/~.git (fetch)
origin    https://github.com/~/~.git (push)

이전에 Commit에 대한 글에서 이야기했듯, 작업 트리(Working tree)의 변경 이력을 저장소로 등록하려면 인덱스를 거쳐 commit해 줘야 합니다. 여기서의 저장소는 로컬 저장소로, 변경 이력을 원격 저장소에 적용하기 위해선 push라는 과정이 하나 더 필요합니다.

git status

만들어 두었던 저장소에 파일 하나를 추가하고, 콘솔에서 해당 디렉토리로 이동한 후 git status 명령어를 입력합니다.

$ touch sample.txt
$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    sample.txt

nothing added to commit but untracked files present (use "git add" to track)
$

git status 명령어는 현재 작업 트리의 상태를 보여줍니다. 여기서는 만들어진 sample.txt를 Untracked files로 분류하고 있습니다. 이전에 File status lifecycle에서 이야기했던 것처럼, 새로 만들어진 파일을 Git이 관리하게(Tracked로 변경) 하려면 파일을 index로 옮겨 한 번 커밋해 주어야 합니다.

git add [files ...]

$ git add sample.txt

git add 명령어를 입력하는 경우, 파일들은 수정 여부에 따라 Staged 상태로 변경됩니다.(Unmodified -> Staged는 불가능하기 때문) 다시 git status를 입력하면, 파일이 인덱스에 추가(staging)되었음을 확인할 수 있습니다.

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   sample.txt

참고로 현재 디렉토리 위치를 포함하여 하위의 모든 변경사항을 인덱스로 옮기려면 git add 뒤의 path를 와일드카드로 입력하면 됩니다.

$ git add .
$ git add directory/.
$ git add *
$ git add directory/*

git commit -m [message]

수정 사항을 인덱스로 옮겼으니 이제 정말로 commit하는 일만 남았습니다.

$ git commit -m "First commit!"

git commit에 들어갈 수 있는 옵션은 아래처럼 정말 많습니다.

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
       [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
       [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
       [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
       [--date=<date>] [--cleanup=<mode>] [--[no-]status]
       [-i | -o] [-S[<keyid>]] [--] [<file>…​]

필수로 들어가야 하는 건 위의 -m 옵션으로, 해당 커밋에 대한 메시지를 의미합니다. 메시지 없이는 커밋이 되지 않습니다. 이전 글에서 이야기했듯 하나의 커밋에는 40자리 hex로 이루어진 고유 이름이 붙습니다. 이렇게 새롭게 생성된 파일을 커밋하고 나면, Untracked 파일들이 Tracked가 되고, Unmodified 상태로 git의 관리를 받기 시작함과 동시에, Index에 존재하던 변경 이력들이 커밋 정보들과 함께 HEAD로 이동합니다.

Index 생략하기

커밋은 Staging area(Index)에 올라와 있는 변경 사항들을 대상으로 진행됩니다. Staging area는 커밋할 파일을 정리한다는 점에서 매우 유용하지만 복잡하기만 하고 필요하지 않은 때도 있습니다. git commit 명령에 -a 옵션을 추가하면, Tracked&Modified 상태의 파일을 자동으로 Staging Area에 넣어 커밋합니다. 그래서 git add 명령을 실행하는 수고를 덜 수 있습니다.

$ git commit -a "Commit!"

Git의 로컬 저장소를 만드는 방법은 두 가지입니다. 기존 프로젝트를 Git 저장소로 만드는 방법이 있고 다른 서버에 있는 원격 저장소를 Clone하는 방법이 있습니다.

기존 프로젝트를 Git 저장소로 만들기

기존 프로젝트를 Git으로 관리하고 싶을 때, 프로젝트의 디렉토리로 이동해서 아래과 같은 명령을 실행합니다.

$ git init
Initialized empty Git repository in /Users/mingyu/Desktop/test/.git/

이 명령은 .git이라는 하위 디렉토리를 숨겨진 채로 만듭니다. .git 디렉토리에는 저장소에 필요한 뼈대 파일이 들어 있습니다. 이 명령만으로는 git이 아직 프로젝트의 어떤 파일도 관리하지 않습니다(모두 Untracked 상태이므로). working tree의 파일을 index로 스테이징하고, commit하는 과정이 필요합니다.

원격 저장소를 clone하기

원격 서버에 이미 존재하는 Git 저장소를 복사하고 싶을 때 git clone 명령을 사용합니다. git clone을 실행하면 프로젝트 히스토리를 전부 받아옵니다. 그래서 서버의 디스크가 망가져도 클라이언트 저장소 중에서 아무거나 하나 가져다가 복구하면 됩니다. Git도 오픈 소스로 관리되고 있으니, git 프로젝트를 clone해 보겠습니다.

$ git clone https://github.com/git/git.git

이 명령은 git이라는 디렉토리를 만들고 .git이라는 하위 디렉토리를 숨겨진 채로 만듭니다. 그리고 저장소의 데이터를 모두 가져와서, 자동으로 코드를 히스토리 중 가장 최신 상태로 만들어 둡니다. 아래와 같이 clone에 옵션을 주면, 다른 디렉토리 이름으로 clone할 수 있습니다.

$ git clone https://github.com/git/git.git mygit

init과 clone의 차이

git init은 기존 프로젝트에 git을 초기화하는 명령으로, 로컬 저장소가 생기며 원격 저장소에 대한 정보(remote)는 없습니다. 반대로 git clone은 원격 저장소의 정보를 불러와 로컬 저장소를 생성하는 것이므로 원격 저장소에 대한 정보가 있습니다. 따라서 remote -v 명령으로 현재 프로젝트에 등록된 원격 저장소를 확인해 보면, 실제로 origin이라는 이름의 remote가 자동으로 등록되어 있습니다.

$ git remote -v
origin    https://github.com/git/git.git (fetch)
origin    https://github.com/git/git.git (push)

따라서 git init으로 저장소를 만들게 되면, git remote를 이용해 원격 저장소에 대한 정보를 설정해 주어야 합니다. [Git] 원격 저장소 만들기에서 remote 설정에 대해 알아볼 수 있습니다.

저장소, 커밋, 작업 트리와 인덱스 개념을 알았으니 이제 실제로 Git을 설치하고 초기 설정을 진행해 봅시다. Git bash를 사용하도록 하겠습니다.

Mac에서 설치

Mac이라면 Homebrew를 통해 간편하게 설치할 수 있습니다.

> brew install git

Windows에서 설치

Git for Windows를 설치합니다.

git config

이제 git bash를 열고, git의 사용 환경을 적절하게 설정해 주도록 합시다. git config라는 명령어를 사용합니다. Git은 이 설정에 따라 동작하고, 이때 사용하는 설정 파일은 세 가지나 됩니다.

• /etc/gitconfig : 시스템의 모든 사용자와 모든 저장소에 적용되는 설정입니다. git config --system 옵션으로 이 파일을 읽고 쓸 수 있다.
• ~/.gitconfig : 특정 사용자에게만 적용되는 설정입니다. git config --global 옵션으로 이 파일을 읽고 쓸 수 있습니다.
• .git/config : 이 파일은 Git 디렉토리에 있고 특정 저장소(혹은 현재 작업 중인 프로젝트)에만 적용됩니다. 이와 같은 각 설정의 우선순위는 역순이며, 따라서 .git/config가 /etc/gitconfig보다 우선됩니다.

윈도우용 Git은 $HOME 디렉토리(%USERPROFILE% 환경변수)에 있는 .gitconfig 파일을 찾습니다. 보통 C:\Documents and Settings\%USERNAME% 또는 C:\Users\%USERNAME%입니다.

가장 먼저 해야 하는 것은 사용자 이름과 이메일 주소를 설정하는 것입니다. Git은 매 커밋마다 이 정보를 사용하고, 한 번 커밋한 후에는 정보를 변경할 수 없습니다. Github과 같은 Git 호스팅 서비스에 가입되어 있다면 해당 정보를 사용하고, 아직 가입하지 않았다면 나중에라도 필요할 때가 올테니, 가입해 두시기 바랍니다.

> git config --global user.name "JoMingyu"
> git config --global user.email "city7310@naver.com"

--global 옵션으로 설정한 것은 딱 한 번만 하면 됩니다. 해당 시스템에서 해당 사용자가 사용할 때에는 global 정보를 사용합니다. 만약 프로젝트마다 다른 이름과 이메일 주소를 사용하고 싶으면 --global 옵션을 빼고 명령을 실행하면 됩니다. git config --list 명령을 실행하면 설정한 모든 것들을 보여줍니다.

> git config --list
credential.helper=osxkeychain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
user.name=JoMingyu
user.email=city7310@naver.com

Git에서는 우리가 작업하고 있는 폴더를 작업 트리(Work tree)라고 부릅니다. 그리고 커밋을 실행하기 전의, 저장소와 작업 트리 사이에 존재하는 공간을 인덱스(Index)라고 합니다.

Commit이 실제로 동작할 땐, Work tree에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 인덱스에 파일 상태를 기록하게 되어 있습니다. 인덱스에 파일 상태를 기록하는 것을 스테이징(Staging)이라 부릅니다. 따라서 저장소에 변경 사항을 기록할 때는, 기록하고자 하는 모든 변경 사항들이 인덱스에 존재해야 합니다.

10개의 파일을 수정했지만 7개만 저장소에 commit하고 싶다면, 해당 7개의 파일을 선택하는 작업이 스테이징 과정입니다. 이렇게 인덱스가 중간에 있는 덕분에 작업 트리 안에 있는 커밋이 필요 없는 파일들을 포함하지 않도록 조절할 수 있고, 원하는 일부 변경 사항만 인덱스에 등록해 커밋할 수 있습니다.

인덱스에 파일 상태를 기록하는 것을 Staging이라고 부르기 때문에, 인덱스는 Staging Area라고도 불립니다.

File Status Lifecycle

Work tree의 모든 파일은 Tracked(관리 대상)과 Untracked(관리 대상이 아님)으로 나뉩니다. Tracked 파일은 이미 한 번 이상 커밋되어 스냅샷에 포함돼 있던 파일입니다. Tracked 파일은 다시 Unmodified(수정하지 않음)와 Modified(수정함), 그리고 Staged(커밋하면 저장소에 기록되는) 상태 중 하나로 관리됩니다. 그리고 나머지 파일은 모두 Untracked 파일입니다. 따라서 Untracked 파일은 '추가' 단위로 관리되고, Tracked 파일은 삭제를 포함한 '수정' 단위로 git에서 관리됩니다. Untracked 파일이라는 개념을 이용해 특정 디렉토리나 파일을 Git의 관리 목록에서 제외(gitignore)할 수도 있습니다. 처음 저장소를 Clone하면 모든 파일은 Tracked이면서 Unmodified인 상태가 됩니다. 이와 같은 것들을 Git에선 File status lifecycle이라고 부릅니다.

Git을 비롯한 소스코드 관리 시스템에서 굉장히 중요하게 생각하는 변경 이력은 commit에 의해 관리됩니다. 로컬 저장소에서 파일의 변경 사항을 repository에 기록하려면 commit이라는 과정이 필요합니다. commit을 하게 되면 이전 커밋 상태부터 현재 상태까지의 변경 이력이 기록된 커밋이 만들어지며, 각각의 커밋은 40자리 hex로 이루어진 고유 이름이 붙습니다. 특정 커밋으로 돌아가거나, 특정 커밋까지 reset하는 등의 기능을 이 고유 이름을 통해 수행합니다. 아래는 Github에서 진행중인 프로젝트의 커밋 로그 중 일부입니다.

대체적으로 버그 수정, 기능 추가 등 특별한 의미가 있는 업데이트를 작업 별로 구분하여 각각 커밋합니다. 이렇게 되면 나중에 이력을 보고 특정 변경 내용을 찾기 쉽습니다. Commit은 생각보다 중요한 작업이기 때문에 커밋 메시지를 필수로 입력해야 합니다. 메시지가 없으면 커밋이 실행되지 않습니다.

사실 commit은 모든 변경 사항에 대해 수행하는 것이 아니라, 저장소와 작업 트리 사이의 인덱스라는 공간에 올라와 있는 파일들만 기록합니다. 작업 트리와 인덱스에 대해서는 여기에서 알아볼 수 있습니다.

Git에서 저장소(repository)는 말 그대로 파일이나 폴더를 저장해 두는 곳입니다. 그런데 git repository의 한 가지 장점은 모든 변경 이력이 남는다는 점입니다. Git은 remote repository와 local repository로 두 종류의 저장소를 제공합니다.

• 원격 저장소(Remote repository) : 파일이 원격 저장소 전용 서버에서 관리되며, 여러 사람이 함께 공유하기 위함
• 로컬 저장소(Local repository) : 파일이 개인 PC에서 관리되며, 개인 전용 저장소

따라서 하나의 원격 저장소에서 파생된 여러 개의 로컬 저장소가 있을 수 있습니다. PC에 로컬 저장소를 만드는 방법은 저장소를 새로 만들거나, 이미 만들어져 있는 원격 저장소를 복사(clone)해올 수 있습니다. Git의 수많은 기능들은 이 저장소에서 출발합니다.

파일을 편집 전 상태로 되돌리고 싶다면, 편집하기 전에 파일을 미리 복사해 두면 됩니다. 파일이나 디렉토리명 뒤에 고유한 ID를 붙여주는 방식이죠. 하지만 이런 방식은 번거롭고, 실수할 가능성도 많습니다. 공유된 파일을 여러 명이 동시에 편집해 생기는 문제도 있습니다. 이런 문제를 해결하기 위해 만들어진 것이 Git과 같은 버전 관리, 소스코드 형상 관리 시스템입니다.

Git은 소스코드를 효과적으로 관리하기 위해 개발된 분산형 버전 관리 시스템입니다. 소스코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나, 특정 시점으로 되돌아갈 수 있는 등 오픈소스 프로젝트의 환경에 맞게끔 만들어져 있습니다. 다른 사람이 편집한 내용과 충돌한다면, 덮어쓰기 전에 직접 수정할 수 있도록 관리해 주기도 합니다. Git으로 파일을 관리하면, 업데이트 이력이 Git에 저장되니 매번 편집 전에 파일을 복사해 두지 않아도 되겠죠.

운영체제 Linux를 만든 리누스 토발즈도 리눅스 커널의 소스 코드를 관리해야 했습니다. 그리고 이를 위해 BitKeeper를 사용하고 있었습니다. 그러나 유료로 전환되는 바람에 화가 나서 분산형 버전 관리 시스템(VCS)인 Git을 만들게 됩니다.

사람들이 Git을 사용하는 이유는 굉장히 여러가지가 있습니다. Git은 모든 변경 사항들을 기록하기 때문에 파일을 편집 전 상태로 쉽게 되돌릴 수도 있고, push/pull 형태로 소스코드를 팀원 간에 쉽게 공유할 수도 있습니다. 개발 조직에게 있어 소스코드 형상 관리는 생산성을 높이기 위한 아주 강력한 솔루션입니다.

Git은 분산형 버전 관리 시스템입니다. 그리고 수많은 사람들이 사용하는 GitHub는 이 Git을 사용하는 프로젝트를 지원하는 서비스입니다. 가장 인기있는 오픈소스 프로젝트 관리 도구기도 합니다. Git이 텍스트 명령어 입력 방식인 데 반해, 깃허브는 GUI를 제공합니다.