1
0
mirror of https://github.com/k88hudson/git-flight-rules.git synced 2025-03-10 12:48:43 -03:00

Fix typo in README_kr.md (#228)

* Fix typo in README_kr.md

fix following typo in korean readme:

Mecury -> Mercury
꺼에요 -> 거에요
꺼구요 -> 거구요
썻어 -> 썼어
썻고 -> 썼고
텍스트르 에디터 -> 텍스트 에디터
리에비스 -> 리베이스
쓼 수 -> 쓸 수
때떄로 -> 때때로
받을려면 -> 받으려면

* Update Doctoc ToC
This commit is contained in:
mnpk 2018-10-23 21:44:00 +09:00 committed by Richard Littauer
parent 02d9745c00
commit 3339385cdb

View File

@ -10,7 +10,7 @@
> *Flight Rules* 는 어떤 문제 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이에요. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차랍니다. [...] > *Flight Rules* 는 어떤 문제 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이에요. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차랍니다. [...]
> NASA는 수성(Mecury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이 목록화 돼있어요. > NASA는 수성(Mercury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이 목록화 돼있어요.
— Chris Hadfield, *인생을 위한 우주비행사의 가이드*. — Chris Hadfield, *인생을 위한 우주비행사의 가이드*.
@ -28,7 +28,7 @@
- [난 리모트 레파지토리를 복제해오고 싶어](#%EB%82%9C-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%A0%88%ED%8C%8C%EC%A7%80%ED%86%A0%EB%A6%AC%EB%A5%BC-%EB%B3%B5%EC%A0%9C%ED%95%B4%EC%98%A4%EA%B3%A0-%EC%8B%B6%EC%96%B4) - [난 리모트 레파지토리를 복제해오고 싶어](#%EB%82%9C-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%A0%88%ED%8C%8C%EC%A7%80%ED%86%A0%EB%A6%AC%EB%A5%BC-%EB%B3%B5%EC%A0%9C%ED%95%B4%EC%98%A4%EA%B3%A0-%EC%8B%B6%EC%96%B4)
- [커밋 수정](#%EC%BB%A4%EB%B0%8B-%EC%88%98%EC%A0%95) - [커밋 수정](#%EC%BB%A4%EB%B0%8B-%EC%88%98%EC%A0%95)
- [내가 방금 어떤 커밋을 남겼지?](#%EB%82%B4%EA%B0%80-%EB%B0%A9%EA%B8%88-%EC%96%B4%EB%96%A4-%EC%BB%A4%EB%B0%8B%EC%9D%84-%EB%82%A8%EA%B2%BC%EC%A7%80) - [내가 방금 어떤 커밋을 남겼지?](#%EB%82%B4%EA%B0%80-%EB%B0%A9%EA%B8%88-%EC%96%B4%EB%96%A4-%EC%BB%A4%EB%B0%8B%EC%9D%84-%EB%82%A8%EA%B2%BC%EC%A7%80)
- [커밋 메세지를 잘못 썻어](#%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%84%B8%EC%A7%80%EB%A5%BC-%EC%9E%98%EB%AA%BB-%EC%8D%BB%EC%96%B4) - [커밋 메세지를 잘못 썼어](#%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%84%B8%EC%A7%80%EB%A5%BC-%EC%9E%98%EB%AA%BB-%EC%8D%BC%EC%96%B4)
- [커밋을 다른 이름과 이메일 설정으로 해버렸어](#%EC%BB%A4%EB%B0%8B%EC%9D%84-%EB%8B%A4%EB%A5%B8-%EC%9D%B4%EB%A6%84%EA%B3%BC-%EC%9D%B4%EB%A9%94%EC%9D%BC-%EC%84%A4%EC%A0%95%EC%9C%BC%EB%A1%9C-%ED%95%B4%EB%B2%84%EB%A0%B8%EC%96%B4) - [커밋을 다른 이름과 이메일 설정으로 해버렸어](#%EC%BB%A4%EB%B0%8B%EC%9D%84-%EB%8B%A4%EB%A5%B8-%EC%9D%B4%EB%A6%84%EA%B3%BC-%EC%9D%B4%EB%A9%94%EC%9D%BC-%EC%84%A4%EC%A0%95%EC%9C%BC%EB%A1%9C-%ED%95%B4%EB%B2%84%EB%A0%B8%EC%96%B4)
- [지난 커밋에서 파일 하나를 지우고 싶어](#%EC%A7%80%EB%82%9C-%EC%BB%A4%EB%B0%8B%EC%97%90%EC%84%9C-%ED%8C%8C%EC%9D%BC-%ED%95%98%EB%82%98%EB%A5%BC-%EC%A7%80%EC%9A%B0%EA%B3%A0-%EC%8B%B6%EC%96%B4) - [지난 커밋에서 파일 하나를 지우고 싶어](#%EC%A7%80%EB%82%9C-%EC%BB%A4%EB%B0%8B%EC%97%90%EC%84%9C-%ED%8C%8C%EC%9D%BC-%ED%95%98%EB%82%98%EB%A5%BC-%EC%A7%80%EC%9A%B0%EA%B3%A0-%EC%8B%B6%EC%96%B4)
- [마지막 커밋을 지우고 싶어](#%EB%A7%88%EC%A7%80%EB%A7%89-%EC%BB%A4%EB%B0%8B%EC%9D%84-%EC%A7%80%EC%9A%B0%EA%B3%A0-%EC%8B%B6%EC%96%B4) - [마지막 커밋을 지우고 싶어](#%EB%A7%88%EC%A7%80%EB%A7%89-%EC%BB%A4%EB%B0%8B%EC%9D%84-%EC%A7%80%EC%9A%B0%EA%B3%A0-%EC%8B%B6%EC%96%B4)
@ -138,7 +138,7 @@
$ git clone [url] $ git clone [url]
``` ```
폴더 이름이 리모트 레파지토리 이름과 같이 저장될에요. 폴더 이름이 리모트 레파지토리 이름과 같이 저장될에요.
복제할 리모트 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요) 복제할 리모트 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요)
@ -173,15 +173,15 @@ $ git log -n1 -p
$ git show <commitid>:filename $ git show <commitid>:filename
``` ```
### 커밋 메세지를 잘못 ### 커밋 메세지를 잘못
만약 메시지를 잘못 고 아직 푸시를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요. 만약 메시지를 잘못 고 아직 푸시를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요.
```sh ```sh
$ git commit --amend $ git commit --amend
``` ```
이 방법은 편집 가능한 기본 텍스트 에디터가 열릴텐데요, 다른 방법으론 한줄에 쓸 수도 있어요. 이 방법은 편집 가능한 기본 텍스트 에디터가 열릴텐데요, 다른 방법으론 한줄에 쓸 수도 있어요.
```sh ```sh
$ git commit --amend -m 'xxxxxxx' $ git commit --amend -m 'xxxxxxx'
@ -242,7 +242,7 @@ $ git push --force-with-lease [remote] [branch]
``` ```
이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요. 이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요.
이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요. 이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
더 알고 싶다면, [이 섹션](#deleteremove-last-pushed-commit)을 참고해주세요. 더 알고 싶다면, [이 섹션](#deleteremove-last-pushed-commit)을 참고해주세요.
<a name="delete-any-commit"></a> <a name="delete-any-commit"></a>
@ -279,7 +279,7 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
``` ```
일반적으로 강제 푸시를 쓰지 마세요. 일반적으로 강제 푸시를 쓰지 마세요.
새 커밋을 만들어서 푸시하는게 수정된 커밋을 강제로 푸시하는 것보다 훨씬 나아요. 그런 수정된 커밋은 그 브랜치나 다른 자식 브랜치를 쓰는 다른 개발자의 소스 이력과 충돌의 원인이 될에요. 새 커밋을 만들어서 푸시하는게 수정된 커밋을 강제로 푸시하는 것보다 훨씬 나아요. 그런 수정된 커밋은 그 브랜치나 다른 자식 브랜치를 쓰는 다른 개발자의 소스 이력과 충돌의 원인이 될에요.
`--force-with-lease` 는 여전히 실패할텐데, 누군가가 같은 브랜치를 쓴다면 변경점을 덮어쓰는 푸시를 할 수도 있어요. `--force-with-lease` 는 여전히 실패할텐데, 누군가가 같은 브랜치를 쓴다면 변경점을 덮어쓰는 푸시를 할 수도 있어요.
절대로 아무도 같은 브랜치를 안 쓰거나, 절대로 브랜치에 업데이트를 해야할때 `--force` (`-f`) 옵션을 쓸 수 있지만 일반적으론 피하는게 좋아요. 절대로 아무도 같은 브랜치를 안 쓰거나, 절대로 브랜치에 업데이트를 해야할때 `--force` (`-f`) 옵션을 쓸 수 있지만 일반적으론 피하는게 좋아요.
@ -289,19 +289,19 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
만약 하드 리셋을 했다고 해도 커밋을 돌릴 순 있어요. 깃은 며칠간은 로그를 가지고 있거든요. 만약 하드 리셋을 했다고 해도 커밋을 돌릴 순 있어요. 깃은 며칠간은 로그를 가지고 있거든요.
알아두기 : 이건 커밋을 남겼거나 스테이시같이 백업을 했을 때만 유효해요. `git reset --hard` 은 커밋되지 않은 수정사항을 _다 지울 에요_, 그러니 조심해서 써야해요. (안전한 방법으론 `git reset --keep` 이 있어요) 알아두기 : 이건 커밋을 남겼거나 스테이시같이 백업을 했을 때만 유효해요. `git reset --hard` 은 커밋되지 않은 수정사항을 _다 지울 에요_, 그러니 조심해서 써야해요. (안전한 방법으론 `git reset --keep` 이 있어요)
```sh ```sh
(master)$ git reflog (master)$ git reflog
``` ```
지난 커밋과 리셋을 위한 커밋을 볼 수 있을 에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요: 지난 커밋과 리셋을 위한 커밋을 볼 수 있을 에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요:
```sh ```sh
(master)$ git reset --hard SHA1234 (master)$ git reset --hard SHA1234
``` ```
계속 할 수 있을에요. 계속 할 수 있을에요.
<a href="undo-a-commit-merge"></a> <a href="undo-a-commit-merge"></a>
### 머지를 실수로 커밋, 푸시해버렸어 ### 머지를 실수로 커밋, 푸시해버렸어
@ -338,13 +338,13 @@ hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git add --patch filename.x $ git add --patch filename.x
``` ```
`-p`는 축약된 옵션이에요. 이 방식은 대화형 모드를 열텐데요. `s` 옵션을 쓰면 커밋을 나눌 수 있어요. 하지만 새 파일이라면 그런 옵션이 없을에요. 새 파일을 추가하려면: `-p`는 축약된 옵션이에요. 이 방식은 대화형 모드를 열텐데요. `s` 옵션을 쓰면 커밋을 나눌 수 있어요. 하지만 새 파일이라면 그런 옵션이 없을에요. 새 파일을 추가하려면:
```sh ```sh
$ git add -N filename.x $ git add -N filename.x
``` ```
그 다음 임의적으로 라인들을 골라 추가해주려면 `e`옵션이 필요할에요. `git diff --cached``git diff --staged`는 로컬에 저장된 부분과 스테이지에 있는 라인들을 비교해서 보여줄 에요. 그 다음 임의적으로 라인들을 골라 추가해주려면 `e`옵션이 필요할에요. `git diff --cached``git diff --staged`는 로컬에 저장된 부분과 스테이지에 있는 라인들을 비교해서 보여줄 에요.
<a href="stage-in-two-commits"></a> <a href="stage-in-two-commits"></a>
### 하나의 파일 변경점을 두개의 다른 커밋에 남기고 싶어 ### 하나의 파일 변경점을 두개의 다른 커밋에 남기고 싶어
@ -354,7 +354,7 @@ $ git add -N filename.x
<a href="unstaging-edits-and-staging-the-unstaged"></a> <a href="unstaging-edits-and-staging-the-unstaged"></a>
### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어 ### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어
이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을에요. 그 다음 스테이시를 다시 불러와 추가를 해요. 이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을에요. 그 다음 스테이시를 다시 불러와 추가를 해요.
```sh ```sh
$ git stash -k $ git stash -k
@ -398,7 +398,7 @@ $ git stash pop
$ git reset $ git reset
``` ```
이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (레파지토리 최상단 루트에서 실행해야 할에요) 이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (레파지토리 최상단 루트에서 실행해야 할에요)
```sh ```sh
$ git checkout . $ git checkout .
@ -535,7 +535,7 @@ $ git reset --hard c5bc55a
서버에 변경점을 푸시 안했는지부터 확인해요. 서버에 변경점을 푸시 안했는지부터 확인해요.
`git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄에요: `git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄에요:
```sh ```sh
(my-branch)$ git status (my-branch)$ git status
@ -571,7 +571,7 @@ $ git reset --hard c5bc55a
알아두세요 `HEAD^2``HEAD~2`과 같은게 아니에요. (더 자세한 정보는 [이 링크](http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde)를 참고해요 ) 알아두세요 `HEAD^2``HEAD~2`과 같은게 아니에요. (더 자세한 정보는 [이 링크](http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde)를 참고해요 )
대안으로, `HEAD^`를 쓰고 싶지 않다면, 마스터 브랜치로 옮길 커밋 해시를 알아둬요 (`git log`가 트릭을 부릴 에요) 그리고 그 해쉬로 리셋을 해요. `git push`가 리모트랑 변경점이 똑같은걸 확인해줄에요. 대안으로, `HEAD^`를 쓰고 싶지 않다면, 마스터 브랜치로 옮길 커밋 해시를 알아둬요 (`git log`가 트릭을 부릴 에요) 그리고 그 해쉬로 리셋을 해요. `git push`가 리모트랑 변경점이 똑같은걸 확인해줄에요.
예를 들자면, 그 마스터의 커밋의 해쉬가 `a13b85e`라면: 예를 들자면, 그 마스터의 커밋의 해쉬가 `a13b85e`라면:
@ -595,7 +595,7 @@ HEAD is now at a13b85e
(solution)$ git add -A && git commit -m "Adding all changes from this spike into one big commit." (solution)$ git add -A && git commit -m "Adding all changes from this spike into one big commit."
``` ```
그 커밋을 브랜치(아마 feature일수도 있고, `develop` 일수도 있겠죠)에 넣고 싶을 때, 모든 파일을 지키는데 관심이 있을꺼에요. 큰 커밋을 작게 나누고 싶을꺼에요. 그 커밋을 브랜치(아마 feature일수도 있고, `develop` 일수도 있겠죠)에 넣고 싶을 때, 모든 파일을 지키는데 관심이 있을거에요. 큰 커밋을 작게 나누고 싶을거에요.
현재 가지고 있는건: 현재 가지고 있는건:
@ -626,7 +626,7 @@ HEAD is now at a13b85e
<a name="cherry-pick"></a> <a name="cherry-pick"></a>
### 한 브랜치에 다른 브랜치에 남겼어야 하는 커밋을 여러개 남겼어 ### 한 브랜치에 다른 브랜치에 남겼어야 하는 커밋을 여러개 남겼어
마스터 브랜치에 있다고 가정하고 `git log` 해보면 커밋 두개 볼 수 있을에요: 마스터 브랜치에 있다고 가정하고 `git log` 해보면 커밋 두개 볼 수 있을에요:
```sh ```sh
(master)$ git log (master)$ git log
@ -838,7 +838,7 @@ Switched to a new branch 'daves'
(`--track``git checkout -b [branch] [remotename]/[branch]` 의 축약이에요) (`--track``git checkout -b [branch] [remotename]/[branch]` 의 축약이에요)
`daves` 브랜치의 로컬 카피를 줄에요. 그리고 푸시된 업데이트들도 리모트로 표시돼요. `daves` 브랜치의 로컬 카피를 줄에요. 그리고 푸시된 업데이트들도 리모트로 표시돼요.
### 현재 로컬 브랜치로 새로운 리모트 브랜치를 만들고 싶어 ### 현재 로컬 브랜치로 새로운 리모트 브랜치를 만들고 싶어
@ -853,7 +853,7 @@ $ git push -u <remote> HEAD
``` ```
`push.default` 설정의 `upstream` 모드와 `simple`모드 (2.0 버전의 깃의 기본)와 함께, `push.default` 설정의 `upstream` 모드와 `simple`모드 (2.0 버전의 깃의 기본)와 함께,
아래 커맨드는 이전에 `-u` 옵션으로 등록된 리모트 브랜치와 관련된 현재 브랜치를 푸시할에요: 아래 커맨드는 이전에 `-u` 옵션으로 등록된 리모트 브랜치와 관련된 현재 브랜치를 푸시할에요:
```sh ```sh
$ git push $ git push
@ -881,7 +881,7 @@ $ git branch -u [remotename]/[branch] [local-branch]
### HEAD를 기본 리모트 브랜치로 트래킹하도록 설정하고 싶어 ### HEAD를 기본 리모트 브랜치로 트래킹하도록 설정하고 싶어
리모트 브랜치를 확인해보는 것으로, HEAD가 트래킹 중인 리모트 브랜치를 볼 수 있어요. 몇몇 경우에는, 원하던 브랜치가 아닐에요. 리모트 브랜치를 확인해보는 것으로, HEAD가 트래킹 중인 리모트 브랜치를 볼 수 있어요. 몇몇 경우에는, 원하던 브랜치가 아닐에요.
```sh ```sh
$ git branch -r $ git branch -r
@ -911,7 +911,7 @@ origin/HEAD set to master
<a name="undo-rebase"></a> <a name="undo-rebase"></a>
### 리베이스/머지 한 걸 되돌리고 싶어 ### 리베이스/머지 한 걸 되돌리고 싶어
현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을에요. 현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을에요.
깃은 위험한 과정 전에 원래의 HEAD 포인트를 ORIG_HEAD라 불리는 변수에 보관해요, 그러니 리베이스/머지 전 상태로 브랜치를 복구하기 간단해요. 깃은 위험한 과정 전에 원래의 HEAD 포인트를 ORIG_HEAD라 불리는 변수에 보관해요, 그러니 리베이스/머지 전 상태로 브랜치를 복구하기 간단해요.
```sh ```sh
@ -921,9 +921,9 @@ origin/HEAD set to master
<a name="force-push-rebase"></a> <a name="force-push-rebase"></a>
### 리베이스를 했는데, 강제 푸시하고 싶진 않아 ### 리베이스를 했는데, 강제 푸시하고 싶진 않아
아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 문이죠. 아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 문이죠.
리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을에요. 리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을에요.
많은 분들이 머지 워크플로우를 리에비스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요. 많은 분들이 머지 워크플로우를 리베이스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요.
주의해서 쓰세요. 주의해서 쓰세요.
리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요: 리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요:
@ -950,7 +950,7 @@ origin/HEAD set to master
(my-branch)$ git commit -am "New awesome feature" (my-branch)$ git commit -am "New awesome feature"
``` ```
좀더 조정하고, 시간기록까지 보관하고 싶다면, 대화형 리베이스가 필요할에요. 좀더 조정하고, 시간기록까지 보관하고 싶다면, 대화형 리베이스가 필요할에요.
```sh ```sh
(my-branch)$ git rebase -i master (my-branch)$ git rebase -i master
@ -963,7 +963,7 @@ origin/HEAD set to master
(master)$ git rebase -i HEAD~2 (master)$ git rebase -i HEAD~2
``` ```
대화형 리베이스를 실행하면 텍스트 에디터로 이런 것들을 볼 수 있을에요. 대화형 리베이스를 실행하면 텍스트 에디터로 이런 것들을 볼 수 있을에요.
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -994,7 +994,7 @@ pick e3851e8 another fix
다음으로 `pick` 부분을 다른 명령어로 바꾸거나, 해당하는 라인을 지워서 커밋을 지울 수도 있어요. 다음으로 `pick` 부분을 다른 명령어로 바꾸거나, 해당하는 라인을 지워서 커밋을 지울 수도 있어요.
예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할에요: 예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할에요:
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -1003,7 +1003,7 @@ f b729ad5 fixup
f e3851e8 another fix f e3851e8 another fix
``` ```
이 커밋들을 합치고 **커밋 이름을 바꾸고 싶다면**, 추가로 적어줘야 해요 두번째 커밋 다음에 `r`를 추가하거나 간단히 `f` 대신 `s`를 추가해주면 될에요: 이 커밋들을 합치고 **커밋 이름을 바꾸고 싶다면**, 추가로 적어줘야 해요 두번째 커밋 다음에 `r`를 추가하거나 간단히 `f` 대신 `s`를 추가해주면 될에요:
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -1027,7 +1027,7 @@ Newer, awesomer features
# #
``` ```
전부 다 성공하면, 이런 메세지를 볼에요: 전부 다 성공하면, 이런 메세지를 볼에요:
```sh ```sh
(master)$ Successfully rebased and updated refs/heads/master. (master)$ Successfully rebased and updated refs/heads/master.
@ -1052,8 +1052,8 @@ Newer, awesomer features
<a name="rebase-unpushed-commits"></a> <a name="rebase-unpushed-commits"></a>
#### 푸시 되지 않은 커밋만 합치고 싶어 #### 푸시 되지 않은 커밋만 합치고 싶어
가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을에요. 가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을에요.
다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을에요. 다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을에요.
```sh ```sh
(master)$ git rebase -i @{u} (master)$ git rebase -i @{u}
@ -1063,7 +1063,7 @@ Newer, awesomer features
#### 머지를 중단해야해 #### 머지를 중단해야해
로 머지는 어떤 파일에 문제를 일으킬 수도 있어요, 이 경우 옵션 `abort`으로 현재 충돌 해결 프로세스를 중단하고 병합하기 전 상태로 다시 구성할 수 있어요. 로 머지는 어떤 파일에 문제를 일으킬 수도 있어요, 이 경우 옵션 `abort`으로 현재 충돌 해결 프로세스를 중단하고 병합하기 전 상태로 다시 구성할 수 있어요.
```sh ```sh
(my-branch)$ git merge --abort (my-branch)$ git merge --abort
@ -1079,7 +1079,7 @@ Newer, awesomer features
(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll (master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
``` ```
이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄꺼에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄꺼구요. 다른 옵션은 이렇게: 이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄거에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄 거구요. 다른 옵션은 이렇게:
```sh ```sh
(master)$ git log master ^feature/120-on-scroll --no-merges (master)$ git log master ^feature/120-on-scroll --no-merges
@ -1105,7 +1105,7 @@ noop
#### 충돌이 있어 #### 충돌이 있어
리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할에요. 리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할에요.
어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요: 어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요:
@ -1129,7 +1129,7 @@ Changes not staged for commit:
>>>>>>> new-commit >>>>>>> new-commit
``` ```
새로운 커밋으로 추가된 코드(예시에선, 중간 선부터 `new-commit` 까지의)와 `HEAD` 사이에서 차이점을 해결해야 할에요. 새로운 커밋으로 추가된 코드(예시에선, 중간 선부터 `new-commit` 까지의)와 `HEAD` 사이에서 차이점을 해결해야 할에요.
어느 한쪽 브랜치의 코드를 남기고 싶다면, `--ours` 또는 `--theirs`를 쓰면 돼요: 어느 한쪽 브랜치의 코드를 남기고 싶다면, `--ours` 또는 `--theirs`를 쓰면 돼요:
@ -1214,7 +1214,7 @@ $ git stash list
$ git stash apply "stash@{n}" $ git stash apply "stash@{n}"
``` ```
여기에서, 'n' 은 스택 안에서 스테이시의 위치를 나타내요. 젤 위에 있는 스테이시가 0 일에요. 여기에서, 'n' 은 스택 안에서 스테이시의 위치를 나타내요. 젤 위에 있는 스테이시가 0 일에요.
## 찾아보기 ## 찾아보기
@ -1238,7 +1238,7 @@ $ git log -S "string to find"
<a name="i-want-to-find-by-author-committer"></a> <a name="i-want-to-find-by-author-committer"></a>
### 작성자나 커미터를 찾고 싶어 ### 작성자나 커미터를 찾고 싶어
작성자나 커미터의 모든 커밋을 찾으려면 이렇게 수 있어요: 작성자나 커미터의 모든 커밋을 찾으려면 이렇게 수 있어요:
```sh ```sh
$ git log --author=<name or email> $ git log --author=<name or email>
@ -1263,7 +1263,7 @@ $ git log -- <path to file>
$ git log -- **/*.js $ git log -- **/*.js
``` ```
와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할에요: 와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할에요:
```sh ```sh
$ git log --name-status -- **/*.js $ git log --name-status -- **/*.js
@ -1344,14 +1344,14 @@ $ git fsck --unreachable | grep tag
$ git update-ref refs/tags/<tag_name> <hash> $ git update-ref refs/tags/<tag_name> <hash>
``` ```
이제 태그가 복구돼있을에요. 이제 태그가 복구돼있을에요.
### 지워진 패치 ### 지워진 패치
만약 깃헙에서 누군가가 풀리퀘스트를 보냈는데 이미 원래의 포크가 지워졌다면, 만약 깃헙에서 누군가가 풀리퀘스트를 보냈는데 이미 원래의 포크가 지워졌다면,
url을 쓸 수 없게 돼 레파지토리를 클론할 수 없거나 [.diff, .patch](https://github.com/blog/967-github-secrets)와 같은 `git am`를 쓸 수 없을 에요. url을 쓸 수 없게 돼 레파지토리를 클론할 수 없거나 [.diff, .patch](https://github.com/blog/967-github-secrets)와 같은 `git am`를 쓸 수 없을 에요.
하지만 [깃헙의 특별한 참조](https://gist.github.com/piscisaureus/3342247)을 이용해서 풀 리퀘스트 자체를 확인할 수 있어요. 하지만 [깃헙의 특별한 참조](https://gist.github.com/piscisaureus/3342247)을 이용해서 풀 리퀘스트 자체를 확인할 수 있어요.
PR#1의 내용을 pr_1이란 새 브랜치로 패치 받려면: PR#1의 내용을 pr_1이란 새 브랜치로 패치 받려면:
```sh ```sh
$ git fetch origin refs/pull/1/head:pr_1 $ git fetch origin refs/pull/1/head:pr_1
@ -1471,7 +1471,7 @@ $ touch mydir/.gitkeep
인증이 필요한 레파지토리를 가지고 있을 텐데요. 인증이 필요한 레파지토리를 가지고 있을 텐데요.
이런 경우 유저명과 비밀번호를 캐시할 수 있을테니 매번 푸시/풀 할 때마다 입력할 필욘 없어요. 이런 경우 유저명과 비밀번호를 캐시할 수 있을테니 매번 푸시/풀 할 때마다 입력할 필욘 없어요.
크리덴셜 헬퍼가 해줄에요. 크리덴셜 헬퍼가 해줄에요.
```sh ```sh
$ git config --global credential.helper cache $ git config --global credential.helper cache
@ -1535,14 +1535,14 @@ c10f740 HEAD@{2}: checkout: moving from master to 2.2
저기에선, 오래된 커밋으로 리셋하기 어려워요. 최신 활동이 `HEAD@{0}` 상단 라벨로 보여지네요. 저기에선, 오래된 커밋으로 리셋하기 어려워요. 최신 활동이 `HEAD@{0}` 상단 라벨로 보여지네요.
만약 실수로 뒤로 이동했다면, 만약 실수로 뒤로 이동했다면,
리플로그는 실수로 지워진 2개의 커밋 전 상태인 (0254ea7)를 가르키는 커밋 마스터를 포함할꺼에요. 리플로그는 실수로 지워진 2개의 커밋 전 상태인 (0254ea7)를 가리키는 커밋 마스터를 포함할거에요.
```sh ```sh
$ git reset --hard 0254ea7 $ git reset --hard 0254ea7
``` ```
`git reset`을 쓰는 것으로 마스터를 이전 커밋으로 되돌릴 수 있어요. `git reset`을 쓰는 것으로 마스터를 이전 커밋으로 되돌릴 수 있어요.
이력이 실수로 변경됐을 때의 안정망을 제공할에요. 이력이 실수로 변경됐을 때의 안정망을 제공할에요.
([여기](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)에서 복제해와 수정했어요). ([여기](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)에서 복제해와 수정했어요).