diff --git a/book/C-git-commands/1-git-commands.asc b/book/C-git-commands/1-git-commands.asc index 68d77e0c..db4c5529 100644 --- a/book/C-git-commands/1-git-commands.asc +++ b/book/C-git-commands/1-git-commands.asc @@ -1,480 +1,1037 @@ [appendix] +////////////////////////// == Git Commands +////////////////////////// +== Git 명령어 +////////////////////////// Throughout the book we have introduced dozens of Git commands and have tried hard to introduce them within something of a narrative, adding more commands to the story slowly. However, this leaves us with examples of usage of the commands somewhat scattered throughout the whole book. +////////////////////////// +이 책에서 Git 명령어를 많이 설명하지만, Git을 설명하기 위해서 중간마다 설명하는 것뿐이다. 설명을 방해할 수 있기 때문에 명령어 중심으로 살펴보지 않는다. 이 장에서는 여기저기 흩어져 있는 명령어 사용법을 한눈에 볼 수 있도록 정리한다. +////////////////////////// In this appendix, we'll go through all the Git commands we addressed throughout the book, grouped roughly by what they're used for. We'll talk about what each command very generally does and then point out where in the book you can find us having used it. +////////////////////////// +책 전체에서 언급했던 Git 명령어를 전부 살펴보는데 명령어를 용도에 따라 그룹으로 묶어 놓았다. 해당 명령어를 어디에 쓰는지 설명하고 어디에서 찾아볼 수 있는지도 표기한다. - +////////////////////////// === Setup and Config +////////////////////////// +=== 설치와 설정 +////////////////////////// There are two commands that are used quite a lot, from the first invocations of Git to common every day tweaking and referencing, the `config` and `help` commands. +////////////////////////// +정말 많이 사용하는 명령어가 두 개 있다. 바로 `config`와 `help` 명령이다. 이 명령은 매일 사용한다. ==== git config -Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This invovles everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories. +////////////////////////// +Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This involves everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories. +////////////////////////// +Git에는 설정할 수 있는 값이 수백 가지에 달한다. 사용자의 취향에 따라 다르게 동작하도록 설정할 수 있다. 이 명령으로 사용자 이름이나 터미널 색깔, 편집기 등을 설정한다. 저장소마다 다르게 혹은 글로벌하게 설정할 수 있는데 각각 설정파일이 다르다. +////////////////////////// The `git config` command has been used in nearly every chapter of the book. +////////////////////////// +`git config` 명령은 이 책의 모든 장에서 사용한다. +////////////////////////// In <<_first_time>> we used it to specify our name, email address and editor preference before we even got started using Git. +////////////////////////// +Git을 처음 사용할 때 이름, 이메일 주소, 편집기는 어떻게 설정하는지는 <<_first_time>>에서 설명한다. +////////////////////////// In <<_git_aliases>> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time. +////////////////////////// +어떻게 단축 명령어를 만드는지는 <<_git_aliases>>에 있다. 매번 긴 옵션을 줄줄 입력하지 않아도 된다. +////////////////////////// In <<_rebasing>> we used it to make `--rebase` the default when you run `git pull`. +////////////////////////// +`git pull` 명령을 실행할 때 `--rebase` 옵션으로 동작하게 하는 방법은 <<_rebasing>>에 있다. +////////////////////////// In <<_credential_caching>> we used it to set up a default store for your HTTP passwords. +////////////////////////// +HTTP 패스워드를 저장하는 방법은 <<_credential_caching>>를 보면 된다. +////////////////////////// In <<_keyword_expansion>> we showed how to set up smudge and clean filters on content coming in and out of Git. +////////////////////////// +Git에 데이터를 넣고 꺼낼 때 사용하는 Smudge와 Clean 필터를 설정하는 방법은 <<_keyword_expansion>>에 있다. +////////////////////////// Finally, basically the entirety of <<_git_config>> is dedicated to the command. +////////////////////////// +마지막으로 `git config` 명령 자체에 대한 설명은 <<_git_config>>에 있다. ==== git help +////////////////////////// The `git help` command is used to show you all the documentation shipped with Git about any command. While we're giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run `git help `. +////////////////////////// +`git help` 명령은 Git에 포함된 문서를 보여준다. 이 장에서는 많이 사용하는 것만 간단히 설명한다. `git help `라고 실행하면 해당 명령어에 어떤 옵션이 있고 어떻게 사용하는지 알려준다. +////////////////////////// We introduced the `git help` command in <<_git_help>> and showed you how to use it to find more information about the `git shell` in <<_setting_up_server>>. +////////////////////////// +`git help` 명령은 <<_git_help>>에 소개한다. `git shell`을 서버에 설정하는 방법은 <<_setting_up_server>>에서 보여준다. - +////////////////////////// === Getting and Creating Projects +////////////////////////// +=== 프로젝트 가져오기와 생성하기 +////////////////////////// There are two ways to get a Git repository. One is to copy it from an existing repository on the network or elsewhere and the other is to create a new one in an existing directory. +////////////////////////// +Git 저장소는 두 가지 방법으로 만든다. 네트워크 어딘가에 있는 저장소를 복사해오거나 기존 프로젝트 디렉토리에서 저장소를 새로 생성할 수 있다. ==== git init +////////////////////////// To take a directory and turn it into a new Git repository so you can start version controlling it, you can simply run `git init`. +////////////////////////// +프로젝트 디렉토리로 가서 `git init`이라고 실행한다. 디렉토리에 Git 저장소가 새로 만들어지고 프로젝트를 버전 관리할 수 있다. -We first introduce this in [[_getting_a_repo]], where we show creating a brand new repository to start working with. +////////////////////////// +We first introduce this in <<_getting_a_repo>>, where we show creating a brand new repository to start working with. +////////////////////////// +<<_getting_a_repo>>에서 로컬에 저장소를 만드는 방법을 설명한다. +////////////////////////// We talk briefly about how you can change the default branch from ``master'' in <<_remote_branches>>. +////////////////////////// +``master''에서 다른 브랜치로 변경하는 방법은 <<_remote_branches>>에 소개한다. +////////////////////////// We use this command to create an empty bare repository for a server in <<_bare_repo>>. +////////////////////////// +<<_bare_repo>>를 보면 Bare 저장소를 만드는 방법이 나와 있다. +////////////////////////// Finally, we go through some of the details of what it actually does behind the scenes in <<_plumbing_porcelain>>. +////////////////////////// +마지막으로 `git init` 명령을 실행하면 내부에서 어떤 일이 일어나는 지 <<_plumbing_porcelain>>에서 설명한다. ==== git clone +////////////////////////// The `git clone` command is actually something of a wrapper around several other commands. It creates a new directory, goes into it and runs `git init` to make it an empty Git repository, adds a remote (`git remote add`) to the URL that you pass it (by default named `origin`), runs a `git fetch` from that remote repository and then checks out the latest commit into your working directory with `git checkout`. +////////////////////////// +`git clone`은 사실 다른 명령어를 몇 개 실행한다. 디렉토리를 만들고 디렉토리로 들어가고 나서 `git init` 명령으로 빈 Git 저장소를 만든다. 그다음 입력한 URL을 `origin`이라는(기본값) 이름의 리모트로 추가하고(`git remote add`) `git fetch` 명령으로 리모트 저장소에서 데이터를 가져온다. 마지막으로 최종 커밋을 워킹 디렉토리에 Checkout한다(`git checkout`). +////////////////////////// The `git clone` command is used in dozens of places throughout the book, but we'll just list a few interesting places. +////////////////////////// +`git clone` 명령은 이 책 어디에서나 볼 수 있는 명령이지만 가장 설명이 잘된 몇 곳을 소개한다. +////////////////////////// It's basically introduced and explained in <<_git_cloning>>, where we go through a few examples. +////////////////////////// +이 명령은 <<_git_cloning>>에서 설명했고 바로 따라 할 수 있는 예제도 보여준다. +////////////////////////// In <<_git_on_the_server>> we look at using the `--bare` option to create a copy of a Git repository with no working directory. +////////////////////////// +`--bare` 옵션을 주고 워킹 디렉토리 없는 Git 저장소를 복사하는 방법을 <<_git_on_the_server>>에서 다룬다. +////////////////////////// In <<_bundling>> we use it to unbundle a bundled Git repository. +////////////////////////// +Bundle 파일로 된 Git 저장소를 다시 풀 수도 있는데 <<_bundling>>에서 소개한다. +////////////////////////// Finally, in <<_cloning_submodules>> we learn the `--recursive` option to make cloning a repository with submodules a little simpler. +////////////////////////// +마지막으로 `--recursive` 옵션으로 Clone할 때 서브모듈까지 Clone하는 방법은 <<_cloning_submodules>>에서 설명한다. +////////////////////////// Though it's used in many other places through the book, these are the ones that are somewhat unique or where it is used in ways that are a little different. +////////////////////////// +이 명령은 여기에 정리한 부분 이외에서도 많은 곳에서 사용했지만, 차근차근 잘 설명한 곳으로 정리했다. - +////////////////////////// === Basic Snapshotting +////////////////////////// +=== 스냅샷 다루기 +////////////////////////// For the basic workflow of staging content and committing it to your history, there are only a few basic commands. +////////////////////////// +Stage하고 Commit하는 정도의 아주 기본적인 워크플로우는 명령어 몇 개만 알면 된다. ==== git add +////////////////////////// The `git add` command adds content from the working directory into the staging area (or ``index'') for the next commit. When the `git commit` command is run, by default it only looks at this staging area, so `git add` is used to craft what exactly you would like your next commit snapshot to look like. +////////////////////////// +`git add` 명령은 워킹 디렉토리에서 Staging Area(``index'')로 컨텐트를 추가하는 명령어다. `git commit` 명령은 오로지 Staging Area만 바라보기 때문에 `git add` 명령으로 커밋할 스냅샷을 잘 다듬어야 한다. +////////////////////////// This command is an incredibly important command in Git and is mentioned or used dozens of times in this book. We'll quickly cover some of the unique uses that can be found. +////////////////////////// +이 명령은 매우 중요한 명령어라서 이 책에서 수십 번도 더 언급한다. 여기서 어떻게 사용하는지 잘 설명한 곳을 찾아보자. +////////////////////////// We first introduce and explain `git add` in detail in <<_tracking_files>>. +////////////////////////// +`git add`는 <<_tracking_files>>에서 자세히 설명한다. +////////////////////////// We mention how to use it to resolve merge conflicts in <<_basic_merge_conflicts>>. +////////////////////////// +이 명령는 충돌 시에도 필요하다. <<_basic_merge_conflicts>>에서 어떻게 사용하는지 설명한다. +////////////////////////// We go over using it to interactively stage only specific parts of a modified file in <<_interactive_staging>>. +////////////////////////// +<<_interactive_staging>>에서 수정한 파일 일부분을 대화형으로 Stage하는 방법을 보여준다. +////////////////////////// Finally, we emulate it at a low level in <<_tree_objects>>, so you can get an idea of what it's doing behind the scenes. +////////////////////////// +마지막으로 이 명령이 내부적으로 어떻게 동작하는지 이해할 수 있도록 <<_tree_objects>>에서 저수준 명령어로 따라 하는 예를 보여준다. ==== git status +////////////////////////// The `git status` command will show you the different states of files in your working directory and staging area. Which files are modified and unstaged and which are staged but not yet committed. In it's normal form, it also will show you some basic hints on how to move files between these stages. +////////////////////////// +`git status` 명령은 워킹 디렉토리와 Staging Aread의 상태를 보여준다. +Modified 상태이거나 Unstaged 상태인 파일이 무엇인지 Staged 상태이지만 아직 커밋하지 않은 파일은 무엇인지 보여준다. Staging Area에 파일을 넣고 꺼내는 방법에 대한 힌트도 보여준다. +////////////////////////// We first cover `status` in <<_checking_status>>, both in it's basic and simplified forms. While we use it throughout the book, pretty much everything you can do with the `git status` command is covered there. +////////////////////////// +`git status` 명령은 <<_checking_status>>에서 간결하게 설명한다. 이 명령은 이 책에서 아주 많이 사용했지만 여기 설명을 벗어나지 않는다. ==== git diff +////////////////////////// The `git diff` command is used when you want to see differences between any two trees. This could be the difference between your working environment and your staging area (`git diff` by itself), between your staging area and your last commit (`git diff --staged`), or between two commits (`git diff master branchB`). +////////////////////////// +`git diff` 명령은 두 트리 개체의 차이를 보고 싶을 때 사용한다. 워킹 디렉토리와 Staging Area를 비교할 수 있고(`git diff`) Staing Area와 마지막 커밋을 비교할 수 있다(`git diff --staged`). 그리고 두 커밋을 비교할 수 있다(`git diff master branchB`). +////////////////////////// We first look at the basic uses of `git diff` in <<_git_diff_staged>>, where we show how to see what changes are staged and which are not yet staged. +////////////////////////// +`git diff`는 <<_git_diff_staged>>에서 처음 설명한다. Staged 상태인 내용이 무엇이고 반대 상태인 내용은 무엇인지 비교하는 법을 설명한다. +////////////////////////// We use it to look for possible whitespace issues before committing with the `--check` option in <<_commit_guidelines>>. +////////////////////////// +<<_commit_guidelines>>에서 `--check` 옵션으로 공백문자가 잘못 입력되지 않았는지 확인하는 방법을 소개한다. +////////////////////////// We see how to check the differences between branches more effectively with the `git diff A...B` syntax in <<_what_is_introduced>>. +////////////////////////// +<<_what_is_introduced>>에서 두 브랜치를 효율적으로 비교할 수 있는 `git diff A...B` 문법을 설명한다. -We use it to filter out whitespace differences with `-w` and how to compare different stages of conflicted files with `--theirs`, `--ours` and `--base` in <<_advanced_merging>>. +////////////////////////// +We use it to filter out whitespace differences with `-b` and how to compare different stages of conflicted files with `--theirs`, `--ours` and `--base` in <<_advanced_merging>>. +////////////////////////// +<<_advanced_merging>>을 보면 `-b` 옵션으로 공백문자는 무시하고 비교하는 것과 `--theirs`, `--ours`, `--base` 옵션으로 충돌 난 파일의 상태를 비교하는 방법이 나와 있다. +////////////////////////// Finally, we use it to effectively compare submodule changes with `--submodule` in <<_starting_submodules>>. +////////////////////////// +마지막으로 <<_starting_submodules>>에서 서브모듈의 변경 내용을 비교하는 `--submodule` 옵션도 설명한다. ==== git difftool +////////////////////////// The `git difftool` command simply launches an external tool to show you the difference between two trees in case you want to use something other than the built in `git diff` command. +////////////////////////// +`git difftool` 명령은 단순히 외부 diff 도구를 실행해준다. `git diff`는 Git에 들어 있는 기능을 사용하는 것이고 외부 diff 도구로 두 트리를 비교하고 싶을 때 사용한다. -We only briefly mention this in <<_git_difftool>>. +////////////////////////// +We only briefly mention this in <<_git_diff_staged>>. +////////////////////////// +이 명령은 <<_git_diff_staged>>에서 설명한다. ==== git commit -The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanant snapshot in the database and then moves the branch pointer on the current branch up to it. +////////////////////////// +The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it. +////////////////////////// +`git commit` 명령은 `git add`로 Staging Area에 넣은 모든 파일을 커밋한다. 데이터베이스에는 하나의 스냅샷으로 기록된다. 그리고 현 브랜치가 새 커밋을 가리키게 한다. +////////////////////////// We first cover the basics of committing in <<_committing_changes>>. There we also demonstrate how to use the `-a` flag to skip the `git add` step in daily workflows and how to use the `-m` flag to pass a commit message in on the command line instead of firing up an editor. +////////////////////////// +커밋에 대한 기본적인 내용은 <<_committing_changes>>에서 다룬다. `-a` 플래그를 주고 `git add`를 건너뛰고 바로 커밋하는 것과 `-m`으로 커밋 메시지를 파라미터로 넘기는 방법도 보여준다. +////////////////////////// In <<_undoing>> we cover using the `--amend` option to redo the most recent commit. +////////////////////////// +가장 최근 커밋을 수정하는 `--amend` 옵션은 <<_undoing>>에서 설명한다. +////////////////////////// In <<_git_branches_overview>>, we go into much more detail about what `git commit` does and why it does it like that. +////////////////////////// +<<_git_branches_overview>>을 보면 `git commit`이 무엇을 하는지 왜 그렇게 하는지 설명한다. +////////////////////////// We looked at how to sign commits cryptographically with the `-S` flag in <<_signing_commits>>. +////////////////////////// +`-S` 플래그로 커밋에 서명하는 방법은 <<_signing_commits>>에서 설명한다. +////////////////////////// Finally, we take a look at what the `git commit` command does in the background and how it's actually implemented in <<_git_commit_objects>>. +////////////////////////// +마지막으로 <<_git_commit_objects>>에서 `git commit` 명령이 내부적으로 하는 일이 무엇이고 실제로 어떻게 구현돼 있는지 설명한다. ==== git reset +////////////////////////// The `git reset` command is primarily used to undo things, as you can possibly tell by the verb. It moves around the `HEAD` pointer and optionally changes the `index` or staging area and can also optionally change the working directory if you use `--hard`. This final option makes it possible for this command to lose your work if used incorrectly, so make sure you understand it before using it. +////////////////////////// +`git reset` 명령은 되돌리는(Undo) 명령이다. 단어가 의미하는 그대로라고 생각하면 된다. `HEAD` 포인터를 옮기는 것과 관련돼 있고 Staging Area(`index`)를 되돌릴 수 있고 `--hard` 옵션을 주면 워킹 디렉토리도 되돌린다. `--hard` 옵션을 잘못 사용하면 작업물을 잃어버릴 수도 있기 때문에 이 명령을 잘 이해하고 있어야 한다. +////////////////////////// We first effectively cover the simplest use of `git reset` in <<_unstaging>>, where we use it to unstage a file we had run `git add` on. +////////////////////////// +`git reset`은 무엇보다도 `git add`로 추가한 파일을 Unstage하는 사용한다. <<_unstaging>>에서 설명한다. +////////////////////////// We then cover it in quite some detail in <<_git_reset>>, which is entirely devoted to explaining this command. +////////////////////////// +<<_git_reset>>에서 이 명령을 전체적으로 자세히 설명한다. +////////////////////////// We use `git reset --hard` to abort a merge in <<_abort_merge>>, where we also use `git merge --abort`, which is a bit of a wrapper for the `git reset` command. +////////////////////////// +`git reset --hard` 명령으로 충돌 시 Merge를 취소할 수 있다. `git merge --abort`로도 같은 일을 할 수 있는데 이 명령은 `git reset` 명령어의 Wrapper다. 이 내용은 <<_abort_merge>>에서 설명한다. ==== git rm +////////////////////////// The `git rm` command is used to remove files from the staging area and working directory for Git. It is similar to `git add` in that it stages a removal of a file for the next commit. +////////////////////////// +`git rm` 명령은 Staging Area나 워킹 디렉토리에 있는 파일을 삭제하는 데 사용한다. `git add` 명령과 비슷하게 파일의 삭제를 Stage하는 기능이다. +////////////////////////// We cover the `git rm` command in some detail in <<_removing_files>>, including recursively removing files and only removing files from the staging area but leaving them in the working directory with `--cached`. +////////////////////////// +<<_removing_files>>에서 `git rm` 명령을 자세히 설명한다. Staging Area와 워킹 디렉토리 모두에서 파일을 삭제하는 방법과 `--cached` 옵션을 주고 Staging Area에 있는 파일만 지우고 워킹 디렉토리의 파일은 남겨두는 방법도 설명한다. +////////////////////////// The only other differing use of `git rm` in the book is in <<_removing_objects>> where we briefly use and explain the `--ignore-unmatch` when running `git filter-branch`, which simply makes it not error out when the file we are trying to remove doesn't exist. This can be useful for scripting purposes. +////////////////////////// +대부분은 <<_removing_objects>>에서 설명한 대로 쓰지만, 이 책에서는 다르게 사용한 예도 있다. `git filter-branch` 명령을 실행할 때 `git rm` 명령에 `--ignore-unmatch` 옵션을 주고 사용한다. 이 옵션은 삭제하려는 파일이 없을 때 에러가 나지 않게 해준다. 스크립트를 작성할 때는 유용하다. ==== git mv -The `git mv` command is a thin convience command to move a file and then run `git add` on the new file and `git rm` on the old file. +////////////////////////// +The `git mv` command is a thin convenience command to move a file and then run `git add` on the new file and `git rm` on the old file. +////////////////////////// +`git mv` 명령은 파일을 옮기고(이름을 변경하고) 나서 새 파일에 `git add` 명령을 실행하고 이전 파일에는 `git rm`을 실행시켜주는 명령이다. +////////////////////////// We only briefly mention this command in <<_git_mv>>. +////////////////////////// +이 명령은 <<_git_mv>>에서 다룬다. ==== git clean +////////////////////////// The `git clean` command is used to remove unwanted files from your working directory. This could include removing temporary build artifacts or merge conflict files. +////////////////////////// +`git clean` 명령은 워킹 디렉토리에서 필요없는 파일을 삭제하는 명령이다. 이 명령으로 충돌로 생긴 파일이나 빌드 아티팩트 파일을 삭제할 때 편리하다. +////////////////////////// We cover many of the options and scenarios in which you might used the clean command in <<_git_clean>>. +////////////////////////// +이 명령을 사용하는 상황과 필요한 옵션은 <<_git_clean>>에서 다룬다. +////////////////////////// === Branching and Merging +////////////////////////// +=== Branch와 Merge +////////////////////////// There are just a handful of commands that implement most of the branching and merging functionality in Git. +////////////////////////// +여기서 소개하는 명령어만 알면 Branch를 사용하고 Merge하는 일은 능히 할 수 있다. ==== git branch +////////////////////////// The `git branch` command is actually something of a branch management tool. It can list the branches you have, create a new branch, delete branches and rename branches. +////////////////////////// +`git branch` 명령은 브랜치를 관리하는 도구다. 이 명령은 브랜치를 모두 보여주고 브랜치를 새로 만들고 브랜치를 삭제하고 브랜치 이름을 변경한다. +////////////////////////// Most of <<_git_branching>> is dedicated to the `branch` command and it's used throughout the entire chapter. We first introduce it in <<_create_new_branch>> and we go through most of it's other features (listing and deleting) in <<_branch_management>>. +////////////////////////// +<<_git_branching>>에서 `branch` 명령을 설명하는데 이 명령을 한 장에 걸쳐서 설명한다. 브랜치를 만드는 것은 <<_create_new_branch>>에서 설명하고 브랜치를 보여주거나 삭제하는 기능은 <<_branch_management>>에서 설명한다. +////////////////////////// In <<_tracking_branches>> we use the `git branch -u` option to set up a tracking branch. +////////////////////////// +`git branch -u` 명령으로 트래킹 브랜치를 만드는 것을 <<_tracking_branches>>에서 보여준다. +////////////////////////// Finally, we go through some of what it does in the background in <<_git_refs>>. +////////////////////////// +내부적으로 어떤 일이 벌어지는지는 <<_git_refs>>에서 설명한다. ==== git checkout +////////////////////////// The `git checkout` command is used to switch branches and check content out into your working directory. +////////////////////////// +`git checkout` 명령은 브랜치를 변경하고 해당 파일을 워킹 디렉토리로 복사한다. +////////////////////////// We first encounter the command in <<_switching_branches>> along with the `git branch` command. +////////////////////////// +`git branch` 명령을 설명하면서 이 명령도 설명한다(<<_switching_branches>>). +////////////////////////// We see how to use it to start tracking branches with the `--track` flag in <<_tracking_branches>>. +////////////////////////// +<<_tracking_branches>>에서 `--track` 옵션을 주고 트래킹 브랜치를 만드는 방법을 설명한다. +////////////////////////// We use it to reintroduce file conflicts with `--conflict=diff3` in <<_checking_out_conflicts>>. +////////////////////////// +이 명령에 `--conflict=diff3`을 주면 충돌 표시된 파일을 재현할 수 있다(<<_checking_out_conflicts>>). +////////////////////////// We go into closer detail on it's relationship with `git reset` in <<_git_reset>>. +////////////////////////// +`git reset` 명령과 관련된 내용은 <<_git_reset>>에서 설명한다. +////////////////////////// Finally, we go into some implementation detail in <<_the_head>>. +////////////////////////// +마지막으로 `git checkout`이 어떻게 구현됐는지는 <<_the_head>>를 참고한다. ==== git merge +////////////////////////// The `git merge` tool is used to merge one or more branches into the branch you have checked out. It will then advance the current branch to the result of the merge. +////////////////////////// +`git merge`는 다른 브랜치를 현재 Checkout된 브랜치에 Merge하는 명령이다. Merge하고 나서 현재 브랜치가 Merge된 결과를 가리키도록 옮긴다. +////////////////////////// The `git merge` command was first introduced in <<_basic_branching>>. Though it is used in various places in the book, there are very few variations of the `merge` command -- generally just `git merge ` with the name of the single branch you want to merge in. +////////////////////////// +`git merge` 명령은 <<_basic_branching>>에서 설명한다. 이 책의 여러 곳에서 `merge` 명령을 사용하지만 <<_basic_branching>>에서 설명한 것에서 크게 벗어나지 않는다. `git merge ` 명령을 실행하면 해당 브랜치가 Merge된다. +////////////////////////// We covered how to do a squashed merge (where Git merges the work but pretends like it's just a new commit without recording the history of the branch you're merging in) at the very end of <<_public_project>>. +////////////////////////// +<<_public_project>>의 끝 부분에서 Squash해서 Merge하는 방법도 설명한다. Merge하는 브랜치의 히스토리는 무시하고 새 커밋을 하나 만들어 Merge하는 방법이다. -We went over a lot about the merge process and command, including the `-Xignore-all-whitespace` command and the `--abort` flag to abort a problem merge in <<_advanced_merging>>. +////////////////////////// +We went over a lot about the merge process and command, including the `-Xignore-space-change` command and the `--abort` flag to abort a problem merge in <<_advanced_merging>>. +////////////////////////// +<<_advanced_merging>>에서는 `-Xignore-space-change` 옵션을 사용하는 방법이나 `--abort` 플래그로 Merge를 중단하는 방법 등을 설명한다. +////////////////////////// We learned how to verify signatures before merging if your project is using GPG signing in <<_signing_commits>>. +////////////////////////// +Merge하기 전에 서명을 검사하는 방법도 설명한다. GPG 서명은 <<_signing_commits>>에서 설명한다. +////////////////////////// Finally, we learned about Subtree merging in <<_subtree_merge>>. +////////////////////////// +마지막으로 Subtree를 Merge하는 것은 <<_subtree_merge>>에서 배운다. ==== git mergetool +////////////////////////// The `git mergetool` command simply launches an external merge helper in case you have issues with a merge in Git. +////////////////////////// +`git mergetool` 명령은 외부 Merge 도구를 실행해 준다. Merge하다가 문제가 생겼을 때 사용한다. +////////////////////////// We mention it quickly in <<_basic_merge_conflicts>> and go into detail on how to implement your own external merge tool in <<_external_merge_tools>>. +////////////////////////// +<<_basic_merge_conflicts>>에서 살짝 맛을 보여주고 <<_external_merge_tools>>에서 자신의 외부 Merge 도구를 설정하는 방법을 설명한다. ==== git log +////////////////////////// The `git log` command is used to show the reachable recorded history of a project from the most recent commit snapshot backwards. By default it will only show the history of the branch you're currently on, but can be given different or even multiple heads or branches from which to traverse. It is also often used to show differences between two or more branches at the commit level. +////////////////////////// +`git log` 명령은 프로젝트 히스토리를 시간의 역순으로 보여준다. 넘겨준 Ref를 따라 히스토리를 보여주는데 Ref를 한 개가 아니라 여러 개 넘길 수도 있다. Ref를 넘겨 주지 않으면 HEAD가 가리키는 브랜치의 히스토리를 보여준다. 또 이 명령으로 여러 브랜치들 사이의 차이를 커밋 단위로 볼 수 있다. +////////////////////////// This command is used in nearly every chapter of the book to demonstrate the history of a project. +////////////////////////// +이 책에서 프로젝트 히스트리를 보여줄 때마다 이 명령을 사용한다고 봐도 된다. +////////////////////////// We introduce the command and cover it in some depth in <<_viewing_history>>. There we look at the `-p` and `--stat` option to get an idea of what was introduced in each commit and the `--pretty` and `--oneline` options to view the history more concisely, along with some simple date and author filtering options. +////////////////////////// +<<_viewing_history>>에서 이 명령을 깊게 다뤘다. `-p` 와 `--stat` 옵션을 주면 각 커밋 사이에 상긴 변화를 확인할 수 있다. `--pretty`와 `--oneline` 옵션을 주면 히스토리를 좀 더 깔끔하게 볼 수 있다. 이 옵션은 Author나 날짜를 중심으로 히스토리를 보여준다. +////////////////////////// In <<_create_new_branch>> we use it with the `--decorate` option to easily visualize where our branch pointers are located and we also use the `--graph` option to see what divergent histories look like. +////////////////////////// +<<_create_new_branch>>을 보면 `--decorate` 옵션을 주고 히스토리에 브랜치 포인터가 함께 보이도록 하는 방법이 나온다. `--graph` 옵션을 추가하면 히스토리가 어떻게 진행됐는지도 볼 수 있다. +////////////////////////// In <<_private_team>> and <<_commit_ranges>> we cover the `branchA..branchB` syntax to use the `git log` command to see what commits are unique to a branch relative to another branch. In <<_commit_ranges>> we go through this fairly extensively. +////////////////////////// +<<_private_team>>과 <<_commit_ranges>>에서 `branchA..branchB` 문법을 사용하는 방법을 설명한다. `branchB`에만 있고 `branchA`에는 없는 커밋만 걸러서 볼 수 있다. <<_commit_ranges>>에서 이 문법을 다양하게 조합하는 방법을 설명한다. +////////////////////////// In <<_merge_log>> and <<_triple_dot>> we cover using the `branchA...branchB` format and the `--left-right` syntax to see what is in one branch or the other but not in both. In <<_merge_log>> we also look at how to use the `--merge` option to help with merge conflict debugging as well as using the `--cc` option to look at merge commit conflicts in your history. +////////////////////////// +<<_merge_log>>와 <<_triple_dot>>에서 `branchA...branchB` 포멧을 사용하는 방법을 설명한다. 이 문법은 서로 한 쪽에만 속한 커밋만 보여준다. `--left-right` 옵션을 주면 각각 어느 쪽에 속한 것인지도 보여준다. <<_merge_log>>에서는 충돌을 해결할 때 유용한 `--merge` 옵션도 설명한다. `--cc` 옵션을 사용하면 충돌을 히스토리에 보여준다. -In <<_git_notes>> we use the `--notes=` option to display notes inline in the log output, and in <<_git_reflog>> we use the `-g` option to view the Git reflog through this tool instead of doing branch traversal. +////////////////////////// +In <<_git_reflog>> we use the `-g` option to view the Git reflog through this tool instead of doing branch traversal. +////////////////////////// +`-g` 옵션을 사용하면 브랜치를 오간 기록인 Reflog도 함께 보여준다. 이것은 <<_git_reflog>>에서 설명한다. +////////////////////////// In <<_searching>> we look at using the `-S` and `-L` options to do fairly sophisticated searches for something that happened historically in the code such as seeing the history of a function. +////////////////////////// +<<_searching>>에서는 `-S`와 `-L` 옵션을 소개한다. 이 옵션을 사용하면 특정 코드에 대한 히스토리만 찾아볼 수 있다. 특정 함수의 히스토리를 보고 싶을 때 사용하면 유용하다. +////////////////////////// In <<_signing_commits>> we see how to use `--show-signature` to add a validation string to each commit in the `git log` output based on if it was validly signed or not. +////////////////////////// +<<_signing_commits>>에서 `--show-signature` 옵션을 사용하는 방법을 설명한다. `git log` 명령에 이 옵션을 사용하면 커밋의 서명 정보까지도 보여준다. ==== git stash -The `git stash` command is used to temporarily store uncomitted work in order to clean out your working directory without having to commit unfinished work on a branch. +////////////////////////// +The `git stash` command is used to temporarily store uncommitted work in order to clean out your working directory without having to commit unfinished work on a branch. +////////////////////////// +`git stash` 명령은 아직 커밋하지 않은 일을 저장하는 데 사용된다. 작업 중인 워킹 디렉토리를 저장한다. +////////////////////////// This is basically entirely covered in <<_git_stashing>>. +////////////////////////// +<<_git_stashing>>에서 설명한다. ==== git tag -The `git tag` command is used to give a permanant bookmark to a specific point in the code history. Generally this is used for things like releases. +////////////////////////// +The `git tag` command is used to give a permanent bookmark to a specific point in the code history. Generally this is used for things like releases. +////////////////////////// +`git tag` 명령은 히스토리에서 특정부분을 북마크하는 기능이다. 일반적으로 배포할 때 사용한다. +////////////////////////// This command is introduced and covered in detail in <<_git_tagging>> and we use it in practice in <<_tagging_releases>>. +////////////////////////// +이 명령은 <<_git_tagging>>에서 자세히 설명하고 <<_tagging_releases>>에 보면 구체적인 사례도 보여준다. +////////////////////////// We also cover how to create a GPG signed tag with the `-s` flag and verify one with the `-v` flag in <<_signing>>. +////////////////////////// +태그에 GPG 서명을 하려면 `-s` 플래그를 주면 되고 `-v` 플래그를 주면 서명을 검증할 수 있다. <<_signing>>에서 다룬다. - +////////////////////////// === Sharing and Updating Projects +////////////////////////// +=== 공유하고 업데이트하기 +////////////////////////// There are not very many commands in Git that access the network, nearly all of the commands operate on the local database. When you are ready to share your work or pull changes from elsewhere, there are a handful of commands that deal with remote repositories. +////////////////////////// +Git에는 네트워크가 필요한 명령어가 많지 않다. 거의 로컬 데이터베이스만으로 동작한다. 코드를 공유하거나 가져올 때 필요한 명령어가 몇 개 있다. 이런 명령어는 모두 리모트 저장소를 다루는 명령어다. ==== git fetch +////////////////////////// The `git fetch` command communicates with a remote repository and fetches down all the information that is in that repository that is not in your current one and stores it in your local database. +////////////////////////// +`git fetch` 명령은 로컬 데이터베이스에 있는 것을 뺀 리모트 저장소의 모든 것을 가져온다. +////////////////////////// We first look at this command in <<_fetching_and_pulling>> and we continue to see examples of it use in <<_remote_branches>>. +////////////////////////// +<<_fetching_and_pulling>>에서 이 명령을 설명하고 <<_remote_branches>>에 보면 참고할 수 있는 예제가 더 있다. +////////////////////////// We also use it in several of the examples in <<_contributing_project>>. +////////////////////////// +<<_contributing_project>>에도 좋은 예제가 많다. +////////////////////////// We use it to fetch a single specific reference that is outside of the default space in <<_pr_refs>> and we see how to fetch from a bundle in <<_bundling>>. +////////////////////////// +Ref를 한 개만 가져오는 방법은 <<_pr_refs>>에서 설명하고 번들에서 가져오는 방법은 <<_bundling>>에서 설명한다. -We set up highly custom refspecs in order to make `git fetch` do something a little different than the default in <<_getting_notes>> and <<_refspec>>. +////////////////////////// +We set up highly custom refspecs in order to make `git fetch` do something a little different than the default in <<_refspec>>. +////////////////////////// +Fetch하는 기본 Refspec을 수정하는 방법은 <<_refspec>>에서 설명한다. 원하는 대로 수정할 수 있다. ==== git pull +////////////////////////// The `git pull` command is basically a combination of the `git fetch` and `git merge` commands, where Git will fetch from the remote you specify and then immediately try to merge it into the branch you're on. +////////////////////////// +`git pull` 명령은 `git fetch`와 `git merge` 명령을 순서대로 실행하는 것뿐이다. 그래서 해당 리모트에서 Fetch하고 즉시 현 브랜치로 Merge를 시도한다. -We introduce it quicking in <<_fetching_and_pulling>> and show how to see what it will merge if you run it in <<_inspecting_remote>>. +////////////////////////// +We introduce it quickly in <<_fetching_and_pulling>> and show how to see what it will merge if you run it in <<_inspecting_remote>>. +////////////////////////// +<<_fetching_and_pulling>>에서 이 명령을 사용하는 방법을 다뤘고 정확히 무엇을 Merge하는 지는 <<_inspecting_remote>>에서 설명한다. +////////////////////////// We also see how to use it to help with rebasing difficulties in <<_rebase_rebase>>. +////////////////////////// +<<_rebase_rebase>>에서 그 어렵다는 Rebase를 다루는 방법을 설명한다. +////////////////////////// We show how to use it with a URL to pull in changes in a one-off fashion in <<_checking_out_remotes>>. +////////////////////////// +저장소 URL을 주고 한 번만 Pull해 올 수 있다는 것을 <<_checking_out_remotes>>에서 설명한다. +////////////////////////// Finally, we very quickly mention that you can use the `--verify-signatures` option to it in order to verify that commits you are pulling have been GPG signed in <<_signing_commits>>. +////////////////////////// +`--verify-signatures` 옵션을 주면 Pull할 때 커밋의 PGP 서명을 검증한다. PGP 서명은 <<_signing_commits>>에서 설명한다. ==== git push +////////////////////////// The `git push` command is used to communicate with another repository, calculate what your local database has that the remote one does not, and then pushes the difference into the other repository. It requires write access to the other repository and so normally is authenticated somehow. +////////////////////////// +`git push` 명령은 리모트에는 없지만, 로컬에는 있는 커밋을 계산하고 나서 그 차이만큼만 Push한다. Push를 하려면 원격 저장소에 대한 쓰기 권한이 필요하고 인증돼야 한다. +////////////////////////// We first look at the `git push` command in <<_pushing_remotes>>. Here we cover the basics of pushing a branch to a remote repository. In <<_pushing_branches>> we go a little deeper into pushing specific branches and in <<_tracking_branches>> we see how to set up tracking branches to automatically push to. In <<_delete_branches>> we use the `--delete` flag to delete a branch on the server with `git push`. +////////////////////////// +<>에서 `git push` 명령으로 브랜치를 원격 저장소에 Push하는 방법을 설명한다. 조금 깊게 브랜치를 하나씩 골라서 Push하는 방법은 <<_pushing_branches>>에서 설명한다. 자동으로 Push하도록 트래킹 브랜치를 설정하는 방법은 <<_tracking branches>>에서 설명한다. `git push --delete` 명령으로 원격 서버의 브랜치를 삭제하는 방법은 <<_delete_branches>>에서 설명한다. +////////////////////////// Throughout <<_contributing_project>> we see several examples of using `git push` to share work on branches through multiple remotes. +////////////////////////// +<<_contributing_project>>에서는 `git push`를 주구장창 사용한다. 리모트를 여러 개 사용해서 브랜치에 작업한 내용을 공유하는 것을 보여준다. +////////////////////////// We see how to use it to share tags that you have made with the `--tags` option in <<_sharing_tags>>. +////////////////////////// +`--tags` 옵션을 주고 태그를 Push하는 방법은 <<_sharing_tags>>에서 설명한다. -In <<_sharing_notes>> we use it in a slightly less common way to share references for commit notes -- references that sit outside of the normal refs namespace. - +////////////////////////// In <<_publishing_submodules>> we use the `--recurse-submodules` option to check that all of our submodules work has been published before pushing the superproject, which can be really helpful when using submodules. +////////////////////////// +서브모듈의 코드를 수정했을 때는 `--recurse-submodules` 옵션이 좋다. 프로젝트를 Push할 때 서브모듈에 Push할 게 있으면 서브모듈부터 Push하므로 매우 편리하다. 이 옵션은 <<_publishing_submodules>>에서 설명한다. +////////////////////////// In <<_other_client_hooks>> we talk briefly about the `pre-push` hook, which is a script we can setup to run before a push completes to verify that it should be allowed to push. +////////////////////////// +<<_other_client_hooks>>에서 `pre-push` 훅에 대해서 설명했다. 이 훅에 Push해도 되는지 검증하는 스크립트를 설정하면 규칙에 따르도록 Push를 검증할 수 있다. +////////////////////////// Finally, in <<_pushing_refspecs>> we look at pushing with a full refspec instead of the general shortcuts that are normally used. This can help you be very specific about what work you wish to share. +////////////////////////// +일반적인 이름 규칙에 따라서 Push하는 것이 아니라 Refspec을 사용해서 원하는 이름으로 Push하는 것도 가능하다. 이것은 <<_pushing_refspecs>>에서 설명한다. ==== git remote +////////////////////////// The `git remote` command is a management tool for your record of remote repositories. It allows you to save long URLs as short handles, such as ``origin'' so you don't have to type them out all the time. You can have several of these and the `git remote` command is used to add, change and delete them. +////////////////////////// +`git remote` 명령은 원격 저장소 설정인 리모트의 관리 도구다. 긴 URL 대신 ``origin''처럼 이름을 짧게 지을 수 있다. 그리고 URL대신 짧은 리모트 이름을 사용한다. `git remote` 명령으로 이 리모트를 여러 개 만들어 관리할 수 있다. +////////////////////////// This command is covered in detail in <<_remote_repos>>, including listing, adding, removing and renaming them. +////////////////////////// +이 리모트를 조회하고 추가하고 삭제하고 수정하는 방법은 <<_remote_repos>>에서 잘 설명한다. +////////////////////////// It is used in nearly every subsequent chapter in the book too, but always in the standard `git remote add ` format. +////////////////////////// +이 명령은 `git remote add ` 형식으로 사용하고 이 책에서 자주 사용된다. ==== git archive +////////////////////////// The `git archive` command is used to create an archive file of a specific snapshot of the project. +////////////////////////// +`git archive` 명령은 프로젝트 스냅샷을 아카이브 파일로 만들어 준다. +////////////////////////// We use `git archive` to create a tarball of a project for sharing in <<_preparing_release>>. +////////////////////////// +<<_preparing_release>>에서 설명하는데 프로젝트를 Tarball로 만들어 공유할 때 사용한다. ==== git submodule +////////////////////////// The `git submodule` command is used to manage external repositories within a normal repositories. This could be for libraries or other types of shared resources. The `submodule` command has several sub-commands (`add`, `update`, `sync`, etc) for managing these resources. +////////////////////////// +`git submodule` 명령은 저장소 안에서 다른 저장소를 관리하는 데 사용한다. 라이브러리나 특정 형식의 리소스 파일을 서브모듈로 사용할 수 있다. `submodule` 명령에 있는 `add`, `update`, `sync` 등의 하위 명령어로 서브모듈을 관리할 수 있다. +////////////////////////// This command is only mentioned and entirely covered in <<_git_submodules>>. +////////////////////////// +이 명령은 <<_git_submodules>>에서 설명한다. +////////////////////////// === Inspection and Comparison +////////////////////////// +=== 보기와 비교 ==== git show +////////////////////////// The `git show` command can show a Git object in a simple and human readable way. Normally you would use this to show the information about a tag or a commit. +////////////////////////// +`git show` 명령은 Git 개체를 사람이 읽을 수 있도록 요약해서 보여준다. 태그나 커밋 정보를 보고 싶을 때 이 명령을 사용한다. +////////////////////////// We first use it to show annotated tag information in <<_annotated_tags>>. +////////////////////////// +<<_annotated_tags>>을 보면 Annotated 태그의 정보를 보여주는 예제가 나온다. +////////////////////////// Later we use it quite a bit in <<_revision_selection>> to show the commits that our various revision selections resolve to. +////////////////////////// +<<_revision_selection>>에서 이 명령을 사용하는 것을 보여준다. +////////////////////////// One of the more interesting things we do with `git show` is in <<_manual_remerge>> to extract specific file contents of various stages during a merge conflict. +////////////////////////// +Merge하다가 충돌이 났을 때 특정 버전의 파일 내용을 `git show`로 꺼내 볼 수 있다. <<_manual_remerge>>에서 이 점을 설명한다. ==== git shortlog +////////////////////////// The `git shortlog` command is used to summarize the output of `git log`. It will take many of the same options that the `git log` command will but instead of listing out all of the commits it will present a summary of the commits grouped by author. +////////////////////////// +`git shortlog` 명령은 `git log` 명령의 결과를 요약해서 보여 준다고 생각하면 된다. 옵션도 `git log` 명령의 것과 매우 비슷하다. 이 명령은 Author 별로 커밋을 묶어서 보여준다. +////////////////////////// We showed how to use it to create a nice changelog in <<_the_shortlog>>. +////////////////////////// +이 명령은 Changelog 파일을 만들 때 유용한 데 <<_the_shortlog>>에서 보여준다. ==== git describe -The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA but more understandable. +////////////////////////// +The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA-1 but more understandable. +////////////////////////// +`git describe` 명령은 커밋과 관련된 정보를 잘 조합해서 사람이 읽을 수 있는 문자로 결과를 만든다. 커밋 SHA-1처럼 식별 가능하고 사람이 이해할 수 있는 정보가 필요할 때 사용한다. +////////////////////////// We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a string to name our release file after. - +////////////////////////// +<<_build_number>>와 <<_preparing_release>>에서 `git describe` 명령을 설명한다. 이 명령으로 배포 파일의 이름을 짓는다. === Debugging +////////////////////////// Git has a couple of commands that are used to help debug an issue in your code. This ranges from figuring out where something was introduced to figuring out who introduced it. +////////////////////////// +Git에는 디버깅용 명령어도 있다. 누가 버그를 만들었는지 언제 어디서 생겼는지 찾아내는 데 도움이 된다. ==== git bisect +////////////////////////// The `git bisect` tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search. +////////////////////////// +`git bisect`는 굉장히 유용하다. 이진 탐색 알고리즘을 사용해서 버그나 문제가 생긴 커밋을 쉽게 찾을 수 있다. +////////////////////////// It is fully covered in <<_binary_search>> and is only mentioned in that section. +////////////////////////// +이 명령은 <<_binary_search>>에서 잘 설명한다. ==== git blame +////////////////////////// The `git blame` command annotates the lines of any file with which commit was the last one to introduce a change to each line of the file and what person authored that commit. This is helpful in order to find the person to ask for more information about a specific section of your code. +////////////////////////// +`git blame`은 파일의 각 라인을 누가 마지막으로 수정했는지 보여준다. 그래서 특정 코드에 대해 궁금한 게 있을 때 누구에게 물어야 할지 바로 알 수 있다. +////////////////////////// It is covered in <<_file_annotation>> and is only mentioned in that section. +////////////////////////// +이 명령은 <<_file_annotation>>에서 다룬다. ==== git grep +////////////////////////// The `git grep` command can help you find any string or regular expression in any of the files in your source code, even older versions of your project. +////////////////////////// +소스 코드에서 스트링이나 정규표현식을 찾을 수 있다. `git grep` 명령을 사용하면 예전 소스 코드까지 찾는다. +////////////////////////// It is covered in <<_git_grep>> and is only mentioned in that section. +////////////////////////// +<<_git_grep>>에서 이 명령을 설명한다. +////////////////////////// === Patching +////////////////////////// +=== Patch하기 -A few commands in Git are centered around the concept of thinking of commits in terms of the changes they introduce, as thought the commit series is a series of patches. These commands help you manage your branches in this manner. +////////////////////////// +A few commands in Git are centered around the concept of thinking of commits in terms of the changes they introduce, as though the commit series is a series of patches. These commands help you manage your branches in this manner. +////////////////////////// +커밋 묶음을 Patch 묶음처럼 다루는 것이 편할 때가 있다. 이럴 때를 위해서 Git에는 커밋 몇 개만 추출하고 적용하고 관리하는 명령어가 있다. ==== git cherry-pick +////////////////////////// The `git cherry-pick` command is used to take the change introduced in a single Git commit and try to re-introduce it as a new commit on the branch you're currently on. This can be useful to only take one or two commits from a branch individually rather than merging in the branch which takes all the changes. +////////////////////////// +`git cherry-pick` 명령은 커밋 하나만 가져올 때 사용한다. 현 브랜치의 새 커밋으로 적용된다. 이 명령은 브랜치를 통째로 Merge하기 보다 커밋 한두 개 정도만 Merge하고 싶을 때 좋다. +////////////////////////// Cherry picking is described and demonstrated in <<_rebase_cherry_pick>>. +////////////////////////// +이 명령으로 커밋을 고르는 것은 <<_rebase_cherry_pick>>에서 설명한다. ==== git rebase +////////////////////////// The `git rebase` command is basically an automated `cherry-pick`. It determines a series of commits and then cherry-picks them one by one in the same order somewhere else. +////////////////////////// +`git rebase` 명령은 `check-pick`을 여러 번 실행해 주는 것과 같다. 연결된 커밋을 그 순서대로 한방에 Cherry-pick해온다. +////////////////////////// Rebasing is covered in detail in <<_rebasing>>, including covering the collaborative issues involved with rebasing branches that are already public. +////////////////////////// +Rebase는 <<_rebasing>>에서 설명한다. 이미 공개한 브랜치를 Rebase할 때 생기는 문제도 다룬다. -We use it in practice during an example of splitting your history into two seperate repositories in <<_replace>>, using the `--onto` flag as well. +////////////////////////// +We use it in practice during an example of splitting your history into two separate repositories in <<_replace>>, using the `--onto` flag as well. +////////////////////////// +<<_replace>>에서는 히스토리를 두 저장소로 분리하는 것을 보여주는데 여기서 `--onto` 옵션을 사용한다. +////////////////////////// We go through running into a merge conflict during rebasing in <<_rerere>>. +////////////////////////// +<<_rerere>>에서 Rebase하면서 발생한 충돌을 어떻게 해결하는지 보여준다. +////////////////////////// We also use it in an interactive scripting mode with the `-i` option in <<_changing_multiple>>. +////////////////////////// +`-i` 옵션을 주고 이 명령을 실행하면 대화형으로 실행할 수 있다. <<_changing_multiple>>에서 설명한다. ==== git revert +////////////////////////// The `git revert` command is essentially a reverse `git cherry-pick`. It creates a new commit that applies the exact opposite of the change introduced in the commit you're targeting, essentially undoing or reverting it. +////////////////////////// +`git revert` 명령은 `git cherry-pick` 명령의 반대로 볼 수 있다. 해당 커밋을 되돌리는 커밋을 새로 생성한다. +////////////////////////// We use this in <<_reverse_commit>> to undo a merge commit. +////////////////////////// +<<_reverse_commit>>에서 Merge 커밋을 되돌리는 것을 보여준다. === Email +////////////////////////// Many Git projects, including Git itself, are entirely maintained over mailing lists. Git has a number of tools built into it that help make this process easier, from generating patches you can easily email to applying those patches from an email box. +////////////////////////// +메일링 리스트로 관리하는 프로젝트가 많이 있다. Git 프로젝트 자체도 그렇다. Git에는 이메일로 작업하기 쉽게 만들어 주는 도구가 들어 있다. Patch를 생성해서 이메일을 보내고 메일 박스에서 Patch를 적용하는 과정을 도와준다. ==== git apply +////////////////////////// The `git apply` command applies a patch created with the `git diff` or even GNU diff command. It is similar to what the `patch` command might do with a few small differences. +////////////////////////// +`git apply` 명령은 `git diff` 명령으로 생성한 Patch를 적용하는 명령이다. GNU diff 명령으로 생성한 Patch도 가능하다. 약간의 차이는 있지만 `patch` 명령어랑 비슷하다. +////////////////////////// We demonstrate using it and the circumstances in which you might do so in <<_patches_from_email>>. +////////////////////////// +이 명령을 사용하는 상황과 어떻게 사용하는지 <<_patches_from_email>>에서 설명한다. ==== git am +////////////////////////// The `git am` command is used to apply patches from an email inbox, specifically one that is mbox formatted. This is useful for receiving patches over email and applying them to your project easily. +////////////////////////// +`git am` 명령으로 이메일 인박스에 든 mbox 포맷의 Patch를 적용할 수 있다. 이메일로 패치를 주고받을 때 유용하다. +////////////////////////// We covered usage and workflow around `git am` in <<_git_am>> including using the `--resolved`, `-i` and `-3` options. +////////////////////////// +`git am`을 언제 어떻게 사용하는지는 <<_git_am>>에서 다룬다. `--resolved`, `-i`, `-3` 옵션 사용법을 설명한다. +////////////////////////// There are also a number of hooks you can use to help with the workflow around `git am` and they are all covered in <<_email_hooks>>. +////////////////////////// +`git am` 명령을 사용할 때 설정할 수 있는 훅은 <<_email_hooks>>에서 다룬다. +////////////////////////// We also use it to apply patch formatted GitHub Pull Request changes in <<_email_notifications>>. +////////////////////////// +이 명령으로 Github Pull Request의 Patch도 적용할 수 있는데 <<_email_notifications>>에서 설명한다. ==== git format-patch +////////////////////////// The `git format-patch` command is used to generate a series of patches in mbox format that you can use to send to a mailing list properly formatted. +////////////////////////// +`git format-patch` 명령은 Patch를 mbox 포맷으로 생성하는 데 사용한다. 생성 한 패치를 쉽게 메일링 리스트로 보낼 수 있다. +////////////////////////// We go through an example of contributing to a project using the `git format-patch` tool in <<_project_over_email>>. +////////////////////////// +`git format-patch`로 프로젝트에 기여하는 예제를 <<_project_over_email>>에서 보여준다. ==== git send-email +////////////////////////// The `git send-email` command is used to send patches that are generated with `git format-patch` over email. +////////////////////////// +`git send-email` 명령은 `git format-patch` 명령으로 생성한 Patch를 이메일로 보내는 데 사용한다. +////////////////////////// We go through an example of contributing to a project by sending patches with the `git send-email` tool in <<_project_over_email>>. +////////////////////////// +<<_project_over_email>>에서 `git send-email` 명령으로 패치를 보내서 다른 프로젝트에 기여하는 것을 보여준다. ==== git request-pull +////////////////////////// The `git request-pull` command is simply used to generate an example message body to email to someone. If you have a branch on a public server and want to let someone know how to integrate those changes without sending the patches over email, you can run this command and send the output to the person you want to pull the changes in. +////////////////////////// +`git request-pull` 명령은 메일 바디를 생성해주는 명령이다. 그래서 쉽게 다른 사람에게 메일을 보낼 수 있다. 브랜치에 커밋하고 Push해 놓은 상태를 누군가에게 알릴 때 유용하다. Patch 자체는 이메일로 보내지 않고 정보만 요약해 보낼 수 있다. 이 명령을 결과를 메일로 보내면 된다. +////////////////////////// We demonstrate how to use `git request-pull` to generate a pull message in <<_public_project>>. +////////////////////////// +<<_public_project>>에서 `git request-pull` 명령을 사용하는 것을 보여준다. +////////////////////////// === External Systems +////////////////////////// +=== 다른 버전 관리 시스템 +////////////////////////// Git comes with a few commands to integrate with other version control systems. +////////////////////////// +Git에는 다른 버전 관리 시스템을 지원하는 명령어도 있다. ==== git svn +////////////////////////// The `git svn` command is used to communicate with the Subversion version control system as a client. This means you can use Git to checkout from and commit to a Subversion server. +////////////////////////// +`git svn` 명령은 Subversion의 클라이언트 명령이다. 그래서 Git으로 Subversion 서버에 있는 커밋을 Checkout할 수 있다. +////////////////////////// This command is covered in depth in <<_git_svn>>. +////////////////////////// +<<_git_svn>>에서 자세히 설명한다. ==== git fast-import +////////////////////////// For other version control systems or importing from nearly any format, you can use `git fast-import` to quickly map the other format to something Git can easily record. +////////////////////////// +버전 관리 시스템을 가리지 않고 데이터를 Git으로 가져올 수 있는 다목적 명령어도 있다. 버전 관리 시스템뿐만 아니라 다른 형식으로 관리하던 데이터도 가져올 수 있다. `git fast-import` 명령은 다른 포맷의 데이터를 쉽게 매핑할 수 있게 해준다. -This command is coverd in depth in <<_custom_importer>>. +////////////////////////// +This command is covered in depth in <<_custom_importer>>. +////////////////////////// +<<_custom_importer>>에서 이 명령을 설명한다. +////////////////////////// === Administration +////////////////////////// +=== 관리 +////////////////////////// If you're administering a Git repository or need to fix something in a big way, Git provides a number of administrative commands to help you out. +////////////////////////// +관리자는 Git 저장소에 문제가 생기면 해결해야 한다. Git은 이때 필요한 명령어도 제공한다. ==== git gc +////////////////////////// The `git gc` command runs ``garbage collection'' on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format. +////////////////////////// +`git gc`는 저장소에 필요없는 파일을 삭제하고 남은 파일을 압축하는 ``Garbage Collection'' 명령이다. +////////////////////////// This command normally runs in the background for you, though you can manually run it if you wish. We go over some examples of this in <<_git_gc>>. +////////////////////////// +직접 실행시켜도 되지만 Git이 자동으로 실행해준다. 자세한 설명은 <<_git_gc>>에서 한다. ==== git fsck +////////////////////////// The `git fsck` command is used to check the internal database for problems or inconsistencies. +////////////////////////// +`git fsck`는 Git 데이터베이스에 문제가 없는지 검사해준다. +////////////////////////// We only quickly use this once in <<_data_recovery>> to search for dangling objects. +////////////////////////// +<<_data_recovery>>에서 Dangling 개체를 찾는 법을 설명한다. ==== git reflog +////////////////////////// The `git reflog` command goes through a log of where all the heads of your branches have been as you work to find commits you may have lost through rewriting histories. +////////////////////////// +`git reflog` 명령은 HEAD가 가리켰던 커밋의 로그를 보여준다. 히스토리를 재작성해서 잃어버린 커밋을 찾을 때 유용하다. +////////////////////////// We cover this command mainly in <<_git_reflog>>, where we show normal usage to and how to use `git log -g` to view the same information with `git log` output. +////////////////////////// +<<_git_reflog>>에서 이 명령을 설명한다. `git log` 명령에 `-g` 옵션을 주면 `git log` 명령의 결과처럼 Reflog를 출력한다. +////////////////////////// We also go through a practical example of recovering such a lost branch in <<_data_recovery>>. +////////////////////////// +잃어버린 브랜치를 복구하는 법은 <<_data_recovery>>에서도 설명한다. ==== git filter-branch +////////////////////////// The `git filter-branch` command is used to rewrite loads of commits according to certain patterns, like removing a file everywhere or filtering the entire repository down to a single subdirectory for extracting a project. +////////////////////////// +`git filter-branch` 명령은 커밋 뭉치를 수정하는 데 사용한다. 전체 히스토리에서 파일을 삭제하거나 디렉토리 구조를 변경하는 데 사용한다. +////////////////////////// In <<_removing_file_every_commit>> we explain the command and explore several different options such as `--commit-filter`, `--subdirectory-filter` and `--tree-filter`. +////////////////////////// +<<_removing_file_every_commit>>에서 `--commit-filter`, `--subdirectory-filter`, `--tree-filter` 같은 옵션 사용법을 설명한다. +////////////////////////// In <<_git_p4>> and <<_git_tfs>> we use it to fix up imported external repositories. +////////////////////////// +<<_git_p4>>, <<_git_tfs>>에서는 다른 버전 관리 시스템에서 가져온 데이터베이스를 바로 잡는 데 사용한다. - +////////////////////////// === Plumbing Commands +////////////////////////// +=== Plumbing 명령어 +////////////////////////// There were also quite a number of lower level plumbing commands that we encountered in the book. +////////////////////////// +이 책에서는 저수준 Plumbing 명령어도 많이 소개한다. +////////////////////////// The first one we encounter is `ls-remote` in <<_pr_refs>> which we use to look at the raw references on the server. +////////////////////////// +<<_pr_refs>>에서는 서버에 있는 저수준 Ref를 조회하는 `ls-remote` 명령을 소개한다. +////////////////////////// We use `ls-files` in <<_manual_remerge>>, <<_rerere>> and <<_the_index>> to take a more raw look at what your staging area looks like. +////////////////////////// +<<_manual_remerge>>와 <<_rerere>>, <<_the_index>>에서 사용하는 `ls-files`는 Staging Area의 저수준 모습을 보여준다. -We also mention `rev-parse` in <<_branch_references>> to take just about any string and turn it into an object SHA. +////////////////////////// +We also mention `rev-parse` in <<_branch_references>> to take just about any string and turn it into an object SHA-1. +////////////////////////// +`rev-parse` 명령은 가리키는 개체의 SHA-1 값을 보여준다. <<_branch_references>>에서 다룬다. +////////////////////////// However, most of the low level plumbing commands we cover are in <<_git_internals>>, which is more or less what the chapter is focused on. We tried to avoid use of them throughout most of the rest of the book. +////////////////////////// +저수준 명령인 Plumbing 명령은 거의 <<_git_interals>>에서 설명한다. Plumbing 명령에는 이 장에서만 설명하려고 했다. 다른 장에서는 최대한 Plumbing 명령어는 사용하지 않으려고 노력했다.