mirrors/git-flight-rules
mirrors
/
git-flight-rules
mirror of https://github.com/k88hudson/git-flight-rules.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

git-flight-rule 번역 1차 종료후 점검

This commit is contained in:
jeffrey.ha 2018-08-28 19:02:21 +09:00
parent be5cee9e3c
commit 0ddbf3eb7a
1 changed files with 208 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

293
README_kr.md
View File

@ -3,20 +3,21 @@
🌍
*[English](README.md) ∙ [Español](README_es.md) ∙ [Русский](README_ru.md) ∙ [简体中文](README_zh-CN.md)∙ [한국어](README_kr.md)*
#### flight rules 이 뭔가요?
#### flight rules 가 뭐야?
A [guide for astronauts](https://www.jsc.nasa.gov/news/columbia/fr_generic.pdf) (now, programmers using Git) about what to do when things go wrong.
뭔가 잘못 됐을 때 뭘 해야할지에 대한 [우주비행사를 위한 가이드](https://www.jsc.nasa.gov/news/columbia/fr_generic.pdf) (여기선 깃을 쓰는 개발자를 위한)
> *Flight Rules* 는 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이다. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차입니다. [...]
> NASA는 수성(Mecury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란게 모아졌는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 이한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책들을 모아져왔습니다.
> *Flight Rules* 는 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이에요. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차랍니다. [...]
> NASA는 수성(Mecury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책들을 목록화 돼있어요.
— Chris Hadfield, *인생을 위한 우주비행사의 가이드*.
#### 이 문서의 규칙
For clarity's sake all examples in this document use a customized bash prompt in order to indicate the current branch and whether or not there are staged changes. The branch is enclosed in parentheses, and a `*` next to the branch name indicates staged changes.
명확성을 위해 이 문서의 모든 예제는 현재 브랜치를 표시하고 스테이지에 변경이 있는지를 나타내기 위해 커스텀 된 배시 프롬프트를 써요.
브랜치는 괄호 안에 있고, 브랜치 다음의 *는 스테이지의 변경된 것을 나타내요.
[![Join the chat at https://gitter.im/k88hudson/git-flight-rules](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/k88hudson/git-flight-rules?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
@ -118,29 +119,29 @@ For clarity's sake all examples in this document use a customized bash prompt in
- [Scripts and Tools](#scripts-and-tools)
- [GUI Clients](#gui-clients)
## Repositories
## 레파지토리
### 로컬 저장소에서 시작하고 싶어
### 로컬 레파지토리에서 시작하고 싶어
이미 있는 디렉토리 내를 깃 레파지토리로 최적화해 쓰려면
이미 존재하는 프로젝트 디렉토리를 깃 레파지토리로 최적화해 쓰려면:
```sh
(my-folder) $ git init
```
### 난 원격 저장소를 복제해오고 싶어
### 난 리모트 레파지토리를 복제해오고 싶어
원격 저장소를 클론하려면, 저장소 url를 복사해와서 실행해요.
리모트 레파지토리를 클론하려면, 레파지토리 URL을 복사해와서 실행해요.
```sh
$ git clone [url]
```
폴더 이름이 원격 저장소 이름과 같이 저장될꺼에요.
폴더 이름이 리모트 레파지토리 이름과 같이 저장될꺼에요.
복제할 원격 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요)
복제할 리모트 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요)
다른 저장소 이름으로 복제를 해오고 싶다면
다른 레파지토리 이름으로 복제를 해오고 싶다면
```sh
$ git clone [url] name-of-new-folder
@ -151,11 +152,9 @@ $ git clone [url] name-of-new-folder
<a name="diff-last"></a>
<!-- ### What did I just commit? -->
### 내가 방금 어떤 commit을 남겼지?
### 내가 방금 어떤 커밋을 남겼지?
자 당신이 막 commit을 `git commit -a` 로 남기고 내가 남긴 내용이 뭔지 확신이 안 서요.
<!-- You can show the latest commit on your current HEAD with: -->
그럼 최근의 commit을 현재 HEAD에서 볼 수 있어요.
`git commit -a` 로 막 커밋을 남기고 내가 뭐라고 안에 적었더라? 한다고 하고. 최근의 커밋을 현재 HEAD에서 볼 수 있어요.
```sh
(master)$ git show
@ -167,7 +166,7 @@ $ git clone [url] name-of-new-folder
$ git log -n1 -p
```
만약 특정 commit의 파일을 보고 싶다면, 이렇게 할 수도 있어요 . (commitID는 바로 당신이 관심있는 그 commit이에요)
만약 특정 커밋의 파일을 보고 싶다면, 이렇게 할 수도 있어요. (commitID는 바로 당신이 관심있는 그 commit이에요)
```sh
$ git show <commitid>:filename
@ -175,7 +174,7 @@ $ git show <commitid>:filename
### 커밋 메세지를 잘못 썻어
만약 메시지를 잘못 썻고 아직 push를 안했다면, commit 메시지 바꾸기를 따라해 볼 수 있어요.
만약 메시지를 잘못 썻고 아직 푸쉬를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요.
```sh
$ git commit --amend
@ -187,36 +186,28 @@ $ git commit --amend
$ git commit --amend -m 'xxxxxxx'
```
If you have already pushed the message, you can amend the commit and force push, but this is not recommended.
만약 push를 이미 했다면, commit을 amend(수정)하고 forcepush를 할 수 있어요. 근데 별로 추천 안해요.
만약 푸시를 이미 했다면, 커밋을 수정해서 강제 푸시를 할 수 있긴한대 별로 추천하진 않아요.
<a name="commit-wrong-author"></a>
### 커밋을 다른 이름과 이메일 설정으로 해버렸어
### I committed with the wrong name and email configured
### 커밋을 잘못된 이름과 이메일 설정으로 해버렸어
If it's a single commit, amend it
단지 commit 하나면, 이렇게 수정해요.
하나의 커밋이라면 이렇게 수정해요.
```sh
$ git commit --amend --no-edit --author "New Authorname <authoremail@mydomain.com>"
```
An alternative is to correctly configure your author settings in `git config --global author.(name|email)` and then use
대안으로 `git config --global author.(name|email)`에서 설정을 다시 맞춘 다음 써요.
대안으로는 `git config --global author.(name|email)`에서 설정을 다시 맞춘 다음
```sh
$ git commit --amend --reset-author --no-edit
```
If you need to change all of history, see the man page for `git filter-branch`.
만약 전체 이력 변경이 필요하다면, `git filter-branch`의 설명 페이지를 봐요.
### I want to remove a file from the previous commit
### 지난 커밋에서 파일 하나를 지우고 싶어
In order to remove changes for a file from the previous commit, do the following:
지난 commit에서 똑바로 파일 변경을 지우려면, 이렇게 해봐요.
지난 커밋에서 파일 변경내역을 지우려면, 이렇게 해봐요:
```sh
$ git checkout HEAD^ myfile
@ -224,66 +215,49 @@ $ git add myfile
$ git commit --amend --no-edit
```
In case the file was newly added to the commit and you want to remove it (from Git alone), do:
그 파일이 새 commit으로 추가됐고 그 파일만 지우고 (git 에서만) 싶을땐,
그 파일이 새롭게 커밋으로 추가됐고 그 파일만 지우고 (git 에서만) 싶은 경우엔,
```sh
$ git rm --cached myfile
$ git commit --amend --no-edit
```
This is particularly useful when you have an open patch and you have committed an unnecessary file, and need to force push to update the patch on a remote. The `--no-edit` option is used to keep the existing commit message.
이 방법은 열린 패치가 있고 불필요한 파일을 commit을 했거나 force push로 원격에 패치를 업데이트 해야할때 특히 유용해요. `--no-edit` 옵션은 기존 commit 메세지를 그대로 워요.
이 방법은 열린 패치가 있고 불필요한 파일을 커밋 했거나 리모트에 강제 푸시로 패치를 업데이트 해야할때 특히 유용해요. `--no-edit` 옵션은 기존 커밋 메세지를 유지하는데 사용돼요.
<a name="delete-pushed-commit"></a>
### 마지막 커밋을 지우고 싶어
### I want to delete or remove my last commit
### 마지막 commit을 지우고 싶어
If you need to delete pushed commits, you can use the following. However, it will irreversibly change your history, and mess up the history of anyone else who had already pulled from the repository. In short, if you're not sure, you should never do this, ever.
push된 commit을 지우고 싶다면 이걸 따라하면 되는데, 이력을 돌이킬 수 없게 되고 저장소에서 이미 풀을 받아간 다른 사람의 이력이 엉망이 되요. 간단히 말하자면, 잘 모르겠으면 절대 하지마요.
푸시된 커밋을 지우고 싶다면 이걸 따라하면 되는데, 이력을 돌이킬 수 없게 되고 레파지토리에서 이미 풀을 받아간 다른 사람의 이력도 엉망이 되요. 간단히 말하자면, 잘 모르겠으면 절대 하지마요.
```sh
$ git reset HEAD^ --hard
$ git push --force-with-lease [remote] [branch]
```
If you haven't pushed, to reset Git to the state it was in before you made your last commit (while keeping your staged changes):
아직 push 안했으면, 리셋으로 마지막 commit 전 상태로 돌아가요. (변경 사항은 스테이지로 유지되요)
아직 푸시 안했으면, 리셋으로 마지막 커밋 전 상태로 돌아가요. (변경점은 스테이지에 두고서)
```
(my-branch*)$ git reset --soft HEAD@{1}
```
This only works if you haven't pushed. If you have pushed, the only truly safe thing to do is `git revert SHAofBadCommit`.
That will create a new commit that undoes all the previous commit's changes. Or, if the branch you pushed to is rebase-safe
(ie. other devs aren't expected to pull from it), you can just use `git push --force-with-lease`. For more, see [the above section](#deleteremove-last-pushed-commit).
이 방법은 push를 안했을때만 동작해요. push를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요.
이 방법은 모든 지난 커밋 변경점이 되돌아간 새 commit을 만들꺼에요. 또는, 만약 push한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
더 알고 싶다면, 여길 참고해주세요 [the above section](#deleteremove-last-pushed-commit).
이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요.
이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들꺼에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
더 알고 싶다면, [이 섹션](#deleteremove-last-pushed-commit)을 참고해주세요 .
<a name="delete-any-commit"></a>
### 임의적인 커밋 지우기
### Delete/remove arbitrary commit
### 임의의 commit 지우기
The same warning applies as above. Never do this if possible.
이전과 동일한 경고에요. 가능한한 이 방법은 쓰지 마세요.
이전과 동일한 경고에요. 가능한 이 방법은 쓰지 마세요.
```sh
$ git rebase --onto SHA1_OF_BAD_COMMIT^ SHA1_OF_BAD_COMMIT
$ git push --force-with-lease [remote] [branch]
```
Or do an [interactive rebase](#interactive-rebase) and remove the line(s) corresponding to commit(s) you want to see removed.
아니면 [interactive rebase](#interactive-rebase)를 쓰고 지우고 싶은 commit 라인을 지워도 되요.
아니면 [대화형 리베이스](#interactive-rebase)를 쓰고 지우고 싶은 커밋 라인을 지워도 되요.
<a name="#force-push"></a>
### I tried to push my amended commit to a remote, but I got an error message
### 수정된 commit을 push했는데, 에러 메세지가 떠
### 수정된 커밋을 푸시했는데, 에러 메세지가 떠
```sh
To https://github.com/yourusername/repo.git
@ -295,7 +269,7 @@ hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```
알아두세요, rebase(아래를 보세요)나 amend는 **기존 commit을 새걸로 바꿔요**,
알아두세요, 리베이스(아래를 보세요)나 amend는 **기존 commit을 새걸로 바꿔요**,
그래서 이미 먼저 수정된 commit이 push 됐다면 force push를 해야 해요.
이 방법을 쓸땐 조심하세요; *항상* 작업되는 브랜치가 맞나 확인해요!
@ -471,7 +445,7 @@ $ git reset
```
This will revert all local uncommitted changes (should be executed in repo root):
이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (저장소 최상단 루트에서 실행해야 할꺼에요)
이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (레파지토리 최상단 루트에서 실행해야 할꺼에요)
```sh
$ git checkout .
@ -589,7 +563,7 @@ $ git branch
```
List remote branches
(원격 저장소) 리모트 브랜치 다 보기
(리모트 레파지토리) 리모트 브랜치 다 보기
```sh
$ git branch -r
@ -655,7 +629,7 @@ Confirm that you haven't pushed your changes to the server.
```
One way of resetting to match origin (to have the same as what is on the remote) is to do this:
오리진(원격과 같은 상태의)로 맞추는 리셋을 하는 방법 중 하나는:
오리진(리모트과 같은 상태의)로 맞추는 리셋을 하는 방법 중 하나는:
```sh
@ -849,7 +823,7 @@ $ git fetch -p upstream
```
where, `upstream` is the remote you want to fetch from.
여기서, `upstream`은 가져오려는 원격저장소에요.
여기서, `upstream`은 가져오려는 리모트레파지토리에요.
<a name='restore-a-deleted-branch'></a>
@ -857,7 +831,7 @@ where, `upstream` is the remote you want to fetch from.
### 브랜치를 지워버렸어
If you're regularly pushing to remote, you should be safe most of the time. But still sometimes you may end up deleting your branches. Let's say we create a branch and create a new file:
주기적으로 원격으로 푸시한다면, 대부분은 안전해야 해요. 그치만 가끔은 브랜치를 지울 수 있어요. 새 브랜치를 만들고 파일을 하나 만들었다고 해보죠:
주기적으로 리모트으로 푸시한다면, 대부분은 안전해야 해요. 그치만 가끔은 브랜치를 지울 수 있어요. 새 브랜치를 만들고 파일을 하나 만들었다고 해보죠:
```sh
@ -906,7 +880,7 @@ oh noes, deleted my branch!
```
At this point you should get familiar with 'reflog', an upgraded logger. It stores the history of all the action in the repo.
여기에서 업그레이드된 로그 도구인 '리플로그'에 익숙해져야 해요. 리플로그는 저장소의 모든 행동의 이력을 다 보관해요.
여기에서 업그레이드된 로그 도구인 '리플로그'에 익숙해져야 해요. 리플로그는 레파지토리의 모든 행동의 이력을 다 보관해요.
```
(master)$ git reflog
@ -996,14 +970,14 @@ To rename a different (local) branch:
### 다른 사람이 작업중인 리모트 브랜치로 체크아웃 하고 싶어
First, fetch all branches from remote:
우선, 원격 저장소에서 모든 브랜치를 패치 받아요:
우선, 리모트 레파지토리에서 모든 브랜치를 패치 받아요:
```sh
(master)$ git fetch --all
```
Say you want to checkout to `daves` from the remote.
원격의 `daves`로 체크아웃 하고 싶다고 하면.
리모트의 `daves`로 체크아웃 하고 싶다고 하면.
```sh
(master)$ git checkout --track origin/daves
@ -1015,7 +989,7 @@ Switched to a new branch 'daves'
(`--track` 은 `git checkout -b [branch] [remotename]/[branch]` 의 축약이에요)
This will give you a local copy of the branch `daves`, and any update that has been pushed will also show up remotely.
`daves` 브랜치의 로컬 카피를 줄꺼에요. 그리고 푸시된 업데이트들도 원격으로 표시되요.
`daves` 브랜치의 로컬 카피를 줄꺼에요. 그리고 푸시된 업데이트들도 리모트으로 표시되요.
### I want to create a new remote branch from current local one
### 현재 로컬에서 새로운 리모트 브랜치를 만들고 싶어
@ -1262,9 +1236,10 @@ If everything is successful, you should see something like this:
```sh
(master)$ git merge --no-ff --no-commit my-branch
```
```///
#### I need to merge a branch into a single commit
####
```sh
(master)$ git merge --squash my-branch
@ -1273,63 +1248,86 @@ If everything is successful, you should see something like this:
<a name="rebase-unpushed-commits"></a>
#### I want to combine only unpushed commits
#### 푸시 되지 않은 커밋만 합치고 싶어
Sometimes you have several work in progress commits that you want to combine before you push them upstream. You don't want to accidentally combine any commits that have already been pushed upstream because someone else may have already made commits that reference them.
Sometimes you have several work in progress commits that you want to combine before you push them upstream.
You don't want to accidentally combine any commits that have already been pushed upstream because someone else may have already made commits that reference them.
가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을꺼에요.
다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을꺼에요.
```sh
(master)$ git rebase -i @{u}
```
This will do an interactive rebase that lists only the commits that you haven't already pushed, so it will be safe to reorder/fix/squash anything in the list.
This will do an interactive rebase that lists only the commits that you haven't already pushed,
so it will be safe to reorder/fix/squash anything in the list.
이 명령은 아직 푸시하지 않은 커밋만으로 대화형 리베이스를 실행해요. 그러니 목록 내에 있는 어떤 커밋이든 재정렬/수정/합치기 안전해요.
#### I need to abort the merge
#### 머지를 중단해야해
Sometimes the merge can produce problems in certain files, in those cases we can use the option `abort` to abort the current conflict resolution process, and try to reconstruct the pre-merge state.
때떄로 머지는 어떤 파일에 문제를 일으킬 수도 있어요, 이 경우 옵션 `abort`으로 현재 충돌 해결 프로세스를 중단하고 병합하기 전 상태로 다시 구성할 수 있어요.
```sh
(my-branch)$ git merge --abort
```
This command is available since Git version >= 1.7.4
이 명령은 1.7.4 버전부터 쓸 수 있어요.
### Check if all commits on a branch are merged
### 브랜치내 모든 커밋이 머지됐는지 확인해
To check if all commits on a branch are merged into another branch, you should diff between the heads (or any commits) of those branches:
브랜치 내 모든 커밋이 다른 브랜치로 머지됐는지 확인하려면, 그 브랜치들 HEAD (또는 특정 커밋)를 비교해야해요:
```sh
(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
```
This will tell you if any commits are in one but not the other, and will give you a list of any nonshared between the branches. Another option is to do this:
이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄꺼에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄꺼구요. 다른 옵션은 이렇게:
```sh
(master)$ git log master ^feature/120-on-scroll --no-merges
```
### Possible issues with interactive rebases
### 대화형 리베이스로 발생가능한 이슈
<a name="noop"></a>
#### The rebase editing screen says 'noop'
#### 리베이스 편집 화면에서 'noop'
If you're seeing this:
이런 걸 본다면:
```
noop
```
That means you are trying to rebase against a branch that is at an identical commit, or is *ahead* of your current branch. You can try:
동일한 커밋에 있거나 현재 브랜치보다 앞서 있는 브랜치에 대해 리베이스를 시도한다는 의미에요. 이렇게 해볼 수 있어요:
* making sure your master branch is where it should be
* rebase against `HEAD~2` or earlier instead
* 마스터 브랜치가 있어야 할 곳에 있나 확인
* 대신해서 `HEAD~2` 또는 더 기존 항목을 리베이스
<a name="merge-conflict"></a>
#### There were conflicts
#### 충돌이 있었어
If you are unable to successfully complete the rebase, you may have to resolve conflicts.
리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할꺼에요.
First run `git status` to see which files have conflicts in them:
어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요:
```sh
(my-branch)$ git status
@ -1342,6 +1340,7 @@ Changes not staged for commit:
```
In this example, `README.md` has conflicts. Open that file and look for the following:
이 예시에선, `README.md` 가 충돌났네요. 파일을 열어서 아래와 같은 부분을 찾아봐요:
```vim
<<<<<<< HEAD
@ -1352,8 +1351,10 @@ In this example, `README.md` has conflicts. Open that file and look for the foll
```
You will need to resolve the differences between the code that was added in your new commit (in the example, everything from the middle line to `new-commit`) and your `HEAD`.
새로운 커밋으로 추가된 코드(예시에선, 중간 선부터 `new-commit` 까지의)와 `HEAD` 사이에서 차이점을 해결해야 할꺼에요.
If you want to keep one branch's version of the code, you can use `--ours` or `--theirs`:
어느 한쪽 브랜치의 코드를 남기고 싶다면, `--ours` 또는 `--theirs`를 쓰면 돼요:
```sh
(master*)$ git checkout --ours README.md
@ -1361,14 +1362,18 @@ If you want to keep one branch's version of the code, you can use `--ours` or `-
- When *merging*, use `--ours` to keep changes from the local branch, or `--theirs` to keep changes from the other branch.
- When *rebasing*, use `--theirs` to keep changes from the local branch, or `--ours` to keep changes from the other branch. For an explanation of this swap, see [this note in the Git documentation](https://git-scm.com/docs/git-rebase#git-rebase---merge).
- *머지*할때, `--ours`를 쓰면 로컬 브랜치의 변경점 유지하고, `--theirs` 는 다른 브랜치의 변경점를 유지해요.
- *리베이스*할 땐, `--theirs`가 로컬 브랜치의 변경점을 유지하고 `--ours`는 다른 브랜치의 변경점을 유지해요. 이런 차이에 관한 설명은 Git 정식 문서 중 [이 문서](https://git-scm.com/docs/git-rebase#git-rebase---merge)를 보세요.
If the merges are more complicated, you can use a visual diff editor:
만약 머지가 더 복잡하면, 비주얼 디프 에디터를 쓸 수도 있어요.
```sh
(master*)$ git mergetool -t opendiff
```
After you have resolved all conflicts and tested your code, `git add` the files you have changed, and then continue the rebase with `git rebase --continue`
코드의 충돌을 해결하고 테스트가 해결되고 나면, 바뀐 파일 내용을 `git add` 해주고, `git rebase --continue`로 리베이스를 이어서 해요.
```sh
(my-branch)$ git add README.md
@ -1376,8 +1381,10 @@ After you have resolved all conflicts and tested your code, `git add` the files
```
If after resolving all the conflicts you end up with an identical tree to what it was before the commit, you need to `git rebase --skip` instead.
만약 모든 충돌을 개선한 내용이 커밋 전과 동일한 트리 구조를 가진다면, 대신에 `git rebase --skip`를 해야 해요.
If at any time you want to stop the entire rebase and go back to the original state of your branch, you can do so:
리베이스 중 멈추고 싶은 어떤 시점이거나 원래 상태의 브랜치로 돌아가고 싶다면, 이렇게 할 수 있어요:
```sh
(my-branch)$ git rebase --abort
@ -1386,30 +1393,37 @@ If at any time you want to stop the entire rebase and go back to the original st
<a name="stashing"></a>
## Stash
## 스테이시
### Stash all edits
### 모든 변경점 스테이시 하기
To stash all the edits in your working directory
작업중인 디렉토리에서의 모든 변경한 내용을 스테이시 하려면
```sh
$ git stash
```
If you also want to stash untracked files, use `-u` option.
트래킹 되지 않은 파일까지도 포함하려면, `-u` 옵션을 써요.
```sh
$ git stash -u
```
### Stash specific files
### 특정 파일들만 스테이시 하기
To stash only one file from your working directory
작업중인 디렉토리에서 한 파일만 스테이시 하기
```sh
$ git stash push working-directory-path/filename.ext
```
To stash multiple files from your working directory
작업중인 디렉토리에서 여러 파일 스테이시 하기
```sh
$ git stash push working-directory-path/filename1.ext working-directory-path/filename2.ext
@ -1418,6 +1432,7 @@ $ git stash push working-directory-path/filename1.ext working-directory-path/fil
<a name="stash-msg"></a>
### Stash with message
### 메세지와 함께 스테이시 하기
```sh
$ git stash save <message>
@ -1426,91 +1441,121 @@ $ git stash save <message>
<a name="stash-apply-specific"></a>
### Apply a specific stash from list
### 특정 스테이시 목록에서 가져와 적용하기
First check your list of stashes with message using
메세지 작성된 스테이시 리스트 먼저 확인하세요
```sh
$ git stash list
```
Then apply a specific stash from the list using
그런 다음 리스트 내 특정 스테이시를 적용해요
```sh
$ git stash apply "stash@{n}"
```
Here, 'n' indicates the position of the stash in the stack. The topmost stash will be position 0.
여기에서, 'n' 은 스택 안에서 스테이시의 위치를 나타내요. 젤 위에 있는 스테이시가 0 일꺼에요.
## Finding
## 찾아보기
### I want to find a string in any commit
### 어떤 커밋에서 문자열을 찾고 싶어
To find a certain string which was introduced in any commit, you can use the following structure:
특정한 문자열이 포함된 어떤 커밋을 찾으려면, 이런 구조로 쓸 수 있어요:
```sh
$ git log -S "string to find"
```
Commons parameters:
일반적인 파라미터들은:
* `--source` means to show the ref name given on the command line by which each commit was reached.
* `--source` 각 커밋에 도달한 명령어에 지정된 참조 이름을 보여주는걸 의미해요 ???
* `--all` means to start from every branch.
* `--all` 는 모든 브랜치에서 시작하는걸 의미해요.
* `--reverse` prints in reverse order, it means that will show the first commit that made the change.
* `--reverse` 반대의 순서로 출력해요, 변경점의 첫번째 커밋이 보일꺼란 거죠.
<a name="i-want-to-find-by-author-committer"></a>
### I want to find by author/committer
### 코드 작성자나 커미터를 찾고 싶어
To find all commits by author/committer you can use:
작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓼 수 있어요:
```sh
$ git log --author=<name or email>
$ git log --committer=<name or email>
```
Keep in mind that author and committer are not the same. The `--author` is the person who originally wrote the code; on the other hand, the `--committer`, is the person who committed the code on behalf of the original author.
Keep in mind that author and committer are not the same.
The `--author` is the person who originally wrote the code;
on the other hand, the `--committer`, is the person who committed the code on behalf of the original author.
작성자와 커미터가 같지 않다는 것만 염두해두세요.
`--author`는 코드를 실제로 코드를 작성한 사람이고;
반면에 `--committer`는 실제 작성자를 대신해 커밋을 한 사람이에요.
### I want to list commits containing specific files
### 특정 파일이 포함된 커밋을 목록화 하고 싶어
To find all commits containing a specific file you can use:
특정 파일이 든 모든 커밋을 찾으려면 이렇게 해요:
```sh
$ git log -- <path to file>
```
You would usually specify an exact path, but you may also use wild cards in the path and file name:
보통은 정확한 경로를 지정할테지만 와일드 카드로 경로나 파일명을 쓸수도 있어요:
```sh
$ git log -- **/*.js
```
While using wildcards, it's useful to inform `--name-status` to see the list of committed files:
와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할꺼에요:
```sh
$ git log --name-status -- **/*.js
```
### Find a tag where a commit is referenced
### 커밋을 참조할 태그를 찾고 싶어
To find all tags containing a specific commit:
특정 커밋이 포함된 모든 태그를 찾으려면:
```sh
$ git tag --contains <commitid>
```
## Submodules
## 서브모듈
<a name="clone-submodules"></a>
### Clone all submodules
### 모든 서브모듈을 클론하기
```sh
$ git clone --recursive git://github.com/foo/bar.git
```
If already cloned:
벌써 클론했다면:
```sh
$ git submodule update --init --recursive
@ -1519,8 +1564,10 @@ $ git submodule update --init --recursive
<a name="delete-submodule"></a>
### Remove a submodule
### 서브모듈 지우기
Creating a submodule is pretty straight-forward, but deleting them less so. The commands you need are:
서브모듈을 만드는건 아주 간단하지만 지우는건 그렇진 않아요. 필요한 명령어는:
```sh
$ git submodule deinit submodulename
@ -1530,22 +1577,27 @@ $ rm -rf .git/modules/submodulename
```
## Miscellaneous Objects
## 잡다한 것들
### Restore a deleted file
### 지운 파일 복구하기
First find the commit when the file last existed:
우선 그 파일이 마지막으로 잇었던 커밋을 찾고:
```sh
$ git rev-list -n 1 HEAD -- filename
```
Then checkout that file:
그런 다음 그 파일을 체크아웃해요
```
git checkout deletingcommitid^ -- filename
```
### Delete tag
### 태그 지우기
```sh
$ git tag -d <tag_name>
@ -1555,24 +1607,38 @@ $ git push <remote> :refs/tags/<tag_name>
<a name="recover-tag"></a>
### Recover a deleted tag
### 지워진 태그 복구학기
If you want to recover a tag that was already deleted, you can do so by following these steps: First, you need to find the unreachable tag:
이미 지운 태그를 복구하고 싶다면, 이런 단계를 따라해 볼 수 있어요: 우선, 연결할 수 없는 태그를 찾고:
```sh
$ git fsck --unreachable | grep tag
```
Make a note of the tag's hash. Then, restore the deleted tag with following, making use of [`git update-ref`](https://git-scm.com/docs/git-update-ref):
Make a note of the tag's hash.
Then, restore the deleted tag with following, making use of [`git update-ref`](https://git-scm.com/docs/git-update-ref):
태그의 해쉬를 메모해두세요.
그런 다음 [`git update-ref`](https://git-scm.com/docs/git-update-ref)을 써서 지워진 태그를 복구해요:
```sh
$ git update-ref refs/tags/<tag_name> <hash>
```
Your tag should now have been restored.
이제 태그가 복구돼있을꺼에요.
### Deleted Patch
### 지워진 패치
If someone has sent you a pull request on GitHub, but then deleted their original fork, you will be unable to clone their repository or to use `git am` as the [.diff, .patch](https://github.com/blog/967-github-secrets) urls become unavailable. But you can checkout the PR itself using [GitHub's special refs](https://gist.github.com/piscisaureus/3342247). To fetch the content of PR#1 into a new branch called pr_1:
If someone has sent you a pull request on GitHub, but then deleted their original fork,
you will be unable to clone their repository or to use `git am` as the [.diff, .patch](https://github.com/blog/967-github-secrets) urls become unavailable.
But you can checkout the PR itself using [GitHub's special refs](https://gist.github.com/piscisaureus/3342247).
To fetch the content of PR#1 into a new branch called pr_1:
만약 깃헙에서 누군가가 풀리퀘스트를 보냈는데 이미 원래의 포크가 지워졌다면,
url을 쓸 수 없게 돼 레파지토리를 클론할 수 없거나 [.diff, .patch](https://github.com/blog/967-github-secrets)와 같은 `git am`를 쓸 수 없을 꺼에요.
하지만 [깃헙의 특별한 참조](https://gist.github.com/piscisaureus/3342247)을 이용해서 풀 리퀘스트 자체를 확인할 수 있어요.
PR#1의 내용을 pr_1이란 새 브랜치로 패치 받을려면:
```sh
$ git fetch origin refs/pull/1/head:pr_1
@ -1581,22 +1647,26 @@ From github.com:foo/bar
```
### Exporting a repository as a Zip file
### Zip파일로 레파지토리 추출하기
```sh
$ git archive --format zip --output /full/path/to/zipfile.zip master
```
## Tracking Files
## 파일 추적하기
<a href="i-want-to-change-a-file-names-capitalization-without-changing-the-contents-of-the-file"></a>
### I want to change a file name's capitalization, without changing the contents of the file
### 파일 내용엔 변경이 없이 파일 이름을 앞글자만 대문자로 바꾸고 싶어
```sh
(master)$ git mv --force myfile MyFile
```
### I want to overwrite local files when doing a git pull
### 깃 풀 받을때 로컬 파일을 덮어씌우고 싶어
```sh
(master)$ git fetch --all
@ -1606,44 +1676,58 @@ $ git archive --format zip --output /full/path/to/zipfile.zip master
<a href="remove-from-git"></a>
### I want to remove a file from Git but keep the file
### 파일을 로컬에는 그대로 두고 깃에서 지우고 싶어
```sh
(master)$ git rm --cached log.txt
```
### I want to revert a file to a specific revision
### 특정한 버전대로 파일을 복구하고 싶어
Assuming the hash of the commit you want is c5f567:
복구하고 싶은 해시가 c5f567 이라고 가정하면:
```sh
(master)$ git checkout c5f567 -- file1/to/restore file2/to/restore
```
If you want to revert to changes made just 1 commit before c5f567, pass the commit hash as c5f567~1:
c5f567 한 단계전으로 복구하고 싶다면, c5f567~1로 적어줘요:
```sh
(master)$ git checkout c5f567~1 -- file1/to/restore file2/to/restore
```
### I want to list changes of a specific file between commits or branches
### 커밋과 브랜치 간의 특적 파일 변경 이력이 필요해
Assuming you want to compare last commit with file from commit c5f567:
마지막 커밋과 c5f567으로 부터의 차이를 비교하고 싶다고 가정하면:
```sh
$ git diff HEAD:path_to_file/file c5f567:path_to_file/file
```
Same goes for branches:
브랜치도 같은 방법으로:
```sh
$ git diff master:path_to_file/file staging:path_to_file/file
```
## Configuration
## 설정
### I want to add aliases for some Git commands
### 깃 명령어 몇개 앨리어스 등록하고 싶어
On OS X and Linux, your git configuration file is stored in ```~/.gitconfig```.
I've added some example aliases I use as shortcuts (and some of my common typos) in the ```[alias]``` section as shown below:
맥OS나 리눅스에는, 깃 설정 파일이 ```~/.gitconfig``` 에 있어요.
단축용으로 (몇개는 평소 쓰는 용도로) 앨리어스 몇개를 아래와 같이 계속 추가해오고 있어요.
On OS X and Linux, your git configuration file is stored in ```~/.gitconfig```. I've added some example aliases I use as shortcuts (and some of my common typos) in the ```[alias]``` section as shown below:
```vim
[alias]
@ -1669,8 +1753,10 @@ On OS X and Linux, your git configuration file is stored in ```~/.gitconfig```.
```
### I want to add an empty directory to my repository
### 레파지토리에 빈 디렉토리를 추가하고 싶어
You can’t! Git doesn’t support this, but there’s a hack. You can create a .gitignore file in the directory with the following contents:
못해요! 깃은 지원하지 않거든요, 근데 꼼수가 있어요. 디렉토리에에 .gitignore 파일을 아래 내용으로 만들어요:
```
# Ignore everything in this directory
@ -1680,6 +1766,7 @@ You can’t! Git doesn’t support this, but there’s a hack. You can create a
```
Another common convention is to make an empty file in the folder, titled .gitkeep.
다른 일반적인 컨벤션은 그 폴더 안에 .gitkeep이라는 이름의 빈 파일을 만드는 거에요.
```sh
$ mkdir mydir
@ -1687,10 +1774,17 @@ $ touch mydir/.gitkeep
```
You can also name the file as just .keep , in which case the second line above would be ```touch mydir/.keep```
.keep이란 이름으로도 쓸 수 있는데요, 두번째 라인이 ```touch mydir/.keep```가 되어야겠죠.
### I want to cache a username and password for a repository
### 레파지토리 유저명과 비밀번호를 캐시해두고 싶어
You might have a repository that requires authentication. In which case you can cache a username and password so you don't have to enter it on every push / pull. Credential helper can do this for you.
You might have a repository that requires authentication.
In which case you can cache a username and password so you don't have to enter it on every push / pull.
Credential helper can do this for you.
인증이 필요한 레파지토리를 가지고 있을 텐데요.
이런 경우 유저명과 비밀번호를 캐시할 수 있을테니 매번 푸시/풀 할 때마다 입력할 필욘 없어요.
크리덴셜 헬퍼가 해줄꺼에요.
```sh
$ git config --global credential.helper cache
@ -1703,44 +1797,57 @@ $ git config --global credential.helper 'cache --timeout=3600'
```
### I want to make Git ignore permissions and filemode changes
### 깃이 권한과 파일모드 변경을 무시하게 만들고 싶어
```sh
$ git config core.fileMode false
```
If you want to make this the default behaviour for logged-in users, then use:
이 것을 로그인된 유저의 기본 행위로 설정으로 해두려면, 이렇게 써요:
```sh
$ git config --global core.fileMode false
```
### I want to set a global user
### 글로버 유저로 설정해두고 싶어
To configure user information used across all local repositories, and to set a name that is identifiable for credit when review version history:
모든 로컬 레파지토리에 사용되는 유저 정보를 설정하려면, 그리고 버전 이력을 리뷰할때 알아보기 쉬운 이름으로 설정하려면:
```sh
$ git config --global user.name “[firstname lastname]”
```
To set an email address that will be associated with each history marker:
각 이력 생산자에게 연관해서 이메일 설정을 해주려면:
```sh
git config --global user.email “[valid-email]”
```
### I want to add command line coloring for Git
### 깃에 명령어 색상을을 넣고 싶어
To set automatic command line coloring for Git for easy reviewing:
손 쉬운 리뷰를 위한 깃 명령줄 자동 색상을 설정 하려면:
```sh
$ git config --global color.ui auto
```
## I've no idea what I did wrong
## 내가 뭘 잘못했는지 모르겠어
So, you're screwed - you `reset` something, or you merged the wrong branch, or you force pushed and now you can't find your commits. You know, at some point, you were doing alright, and you want to go back to some state you were at.
This is what `git reflog` is for. `reflog` keeps track of any changes to the tip of a branch, even if that tip isn't referenced by a branch or a tag. Basically, every time HEAD changes, a new entry is added to the reflog. This only works for local repositories, sadly, and it only tracks movements (not changes to a file that weren't recorded anywhere, for instance).
So, you're screwed - you `reset` something, or you merged the wrong branch, or you force pushed and now you can't find your commits.
You know, at some point, you were doing alright, and you want to go back to some state you were at.
This is what `git reflog` is for. `reflog` keeps track of any changes to the tip of a branch, even if that tip isn't referenced by a branch or a tag.
Basically, every time HEAD changes, a new entry is added to the reflog. This only works for local repositories, sadly, and it only tracks movements (not changes to a file that weren't recorded anywhere, for instance).
음, 망했군요. 뭔가를 `reset` 했거나, 다른 브랜치로 머지했거나, 지금은 찾질 못하는 커밋으로 강제 푸시를 해버렸군요.
알다시피, 어떤 시점에선, 잘 하고 있었고 거기로 돌아가고 싶겠죠.
이게 바로 `git reflog`의 존재이유에요. `reflog` 는 브랜치 끝의 어떤 변경점이든 브랜치나 태그에 의해 참조되지 않더라도 다 보관해요.
기본적으로, HEAD가 변경되는 모든 경우, 리플로그에 새로운 입력이 추가돼요. 아쉽게도 이 기능은 로컬 레파지토리에서만 동작해고, 오직 움직임만을 트래킹해요 (예를 들자면 어디에도 기록되지 않았던 파일의 변경은 아니에요)
```sh
(master)$ git reflog
@ -1749,26 +1856,40 @@ This is what `git reflog` is for. `reflog` keeps track of any changes to the tip
c10f740 HEAD@{2}: checkout: moving from master to 2.2
```
The reflog above shows a checkout from master to the 2.2 branch and back. From there, there's a hard reset to an older commit. The latest activity is represented at the top labeled `HEAD@{0}`.
The reflog above shows a checkout from master to the 2.2 branch and back.
From there, there's a hard reset to an older commit. The latest activity is represented at the top labeled `HEAD@{0}`.
이 리플로그는 마스터에서 2.2 브랜치로 체크아웃하고 되돌린 것을 보여주네요.
저기에선, 오래된 커밋으로 리셋하기 어려워요. 최신 활동이 `HEAD@{0}` 상단 라벨로 보여지네요.
If it turns out that you accidentally moved back,
the reflog will contain the commit master pointed to (0254ea7) before you accidentally dropped 2 commits.
만약 실수로 뒤로 이동했다면,
리플로그는 실수로 지워진 2개의 커밋 전인 (0254ea7)를 가르키는 커밋 마스터를 포함할꺼에요.
If it turns out that you accidentally moved back, the reflog will contain the commit master pointed to (0254ea7) before you accidentally dropped 2 commits.
```sh
$ git reset --hard 0254ea7
```
Using `git reset` it is then possible to change master back to the commit it was before. This provides a safety net in case history was accidentally changed.
Using `git reset` it is then possible to change master back to the commit it was before.
This provides a safety net in case history was accidentally changed.
`git reset`을 쓰는 것으로 마스터를 이전 커밋으로 되돌릴 수 있어요.
이력이 실수로 변경됐을 때의 안정망을 제공할꺼에요.
(copied and edited from [Source](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)).
(복사해서 수정해봐가며 배워요 [Source](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog))
# Other Resources
# 다른 리소스
## Books
## 도서
* [Pro Git](https://git-scm.com/book/en/v2) - Scott Chacon and Ben Straub's excellent book about Git
* [Git Internals](https://github.com/pluralsight/git-internals-pdf) - Scott Chacon's other excellent book about Git
## Tutorials
## 튜토리얼
* [Atlassian's Git tutorial](https://www.atlassian.com/git/tutorials) Get Git right with tutorials from beginner to advanced.
* [Learn Git branching](https://learngitbranching.js.org/) An interactive web based branching/merging/rebasing tutorial
@ -1778,6 +1899,7 @@ Using `git reset` it is then possible to change master back to the commit it was
* [Githug](https://github.com/Gazler/githug) - A game to learn more common Git workflows
## Scripts and Tools
## 스크립트와 도구
* [firstaidgit.io](http://firstaidgit.io/) A searchable selection of the most frequently asked Git questions
* [git-extra-commands](https://github.com/unixorn/git-extra-commands) - a collection of useful extra Git scripts
@ -1787,6 +1909,7 @@ Using `git reset` it is then possible to change master back to the commit it was
* [git-town](https://github.com/Originate/git-town) - Generic, high-level Git workflow support! http://www.git-town.com
## GUI Clients
## GUI 클라이언트
* [GitKraken](https://www.gitkraken.com/) - The downright luxurious Git client,for Windows, Mac & Linux
* [git-cola](https://git-cola.github.io/) - another Git client for Windows and OS X