alvaro/git-flight-rules
1
0
Fork 0
mirror of https://github.com/k88hudson/git-flight-rules.git synced 2025-03-10 12:48:43 -03:00
Code Issues Releases Wiki Activity

Fix typo in README_kr.md (#228)

Browse Source 
* 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
1 changed files with 46 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
README_kr.md
View File

@ -10,7 +10,7 @@
> *Flight Rules* 는 어떤 문제 X가 발생한 이유와 그 단계의 매뉴얼에서 어렵사리 얻은 지식이에요. 기본적으로 각 시나리오의 매우 자세하고 구체적인 운영 절차랍니다. [...]
> NASA는 수성(Mecury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이 목록화 돼있어요.
> NASA는 수성(Mercury) 시대 때 지상팀에서 처음으로 "lessons learned" 이란 것을 모았는데 수천개의 문제의 상황들, 부서진 해치 손잡이로 인한 엔진 고장부터 컴퓨터 문제 그리고 그 해답까지, 1960년대 초부터 우리의 실수들, 재앙들, 해결책 등이 목록화 돼있어요.
— 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)
- [커밋 수정](#%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)
- [커밋 메세지를 잘못 썻어](#%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%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)
@ -138,7 +138,7 @@
$ git clone [url]
```
폴더 이름이 리모트 레파지토리 이름과 같이 저장될꺼에요.
폴더 이름이 리모트 레파지토리 이름과 같이 저장될 거에요.
복제할 리모트 서버의 연결을 확인하세요.(대부분 인터넷 연결을 확인하란 뜻이에요)
@ -173,15 +173,15 @@ $ git log -n1 -p
$ git show <commitid>:filename
```
### 커밋 메세지를 잘못 썻어
### 커밋 메세지를 잘못 썼어
만약 메시지를 잘못 썻고 아직 푸시를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요.
만약 메시지를 잘못 썼고 아직 푸시를 안했다면, 커밋 메시지 바꾸기를 따라해 볼 수 있어요.
```sh
$ git commit --amend
```
이 방법은 편집 가능한 기본 텍스트르 에디터가 열릴텐데요, 다른 방법으론 한줄에 쓸 수도 있어요.
이 방법은 편집 가능한 기본 텍스트 에디터가 열릴텐데요, 다른 방법으론 한줄에 쓸 수도 있어요.
```sh
$ git commit --amend -m 'xxxxxxx'
@ -242,7 +242,7 @@ $ git push --force-with-lease [remote] [branch]
```
이 방법은 푸시를 안 했을 때만 동작해요. 푸시를 했으면, 안전한 방법은 `git revert SHAofBadCommit` 한가지 밖이에요.
이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들꺼에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
이 방법은 모든 지난 커밋 변경점으로 되돌아간 새 커밋을 만들 거에요. 또는, 만약 푸시한 브랜치가 리베이스에 안전하다면 (만약 다른 사람이 풀 받지 않는다면), `git push --force-with-lease` 명령어를 쓸수 있어요.
더 알고 싶다면, [이 섹션](#deleteremove-last-pushed-commit)을 참고해주세요.
<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` (`-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
(master)$ git reflog
```
지난 커밋과 리셋을 위한 커밋을 볼 수 있을 꺼에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요:
지난 커밋과 리셋을 위한 커밋을 볼 수 있을 거에요. 돌아가고 싶은 커밋의 SHA 코드를 골라서, 리셋을 해요:
```sh
(master)$ git reset --hard SHA1234
```
계속 할 수 있을꺼에요.
계속 할 수 있을거에요.
<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
```
`-p`는 축약된 옵션이에요. 이 방식은 대화형 모드를 열텐데요. `s` 옵션을 쓰면 커밋을 나눌 수 있어요. 하지만 새 파일이라면 그런 옵션이 없을꺼에요. 새 파일을 추가하려면:
`-p`는 축약된 옵션이에요. 이 방식은 대화형 모드를 열텐데요. `s` 옵션을 쓰면 커밋을 나눌 수 있어요. 하지만 새 파일이라면 그런 옵션이 없을거에요. 새 파일을 추가하려면:
```sh
$ 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>
### 하나의 파일 변경점을 두개의 다른 커밋에 남기고 싶어
@ -354,7 +354,7 @@ $ git add -N filename.x
<a href="unstaging-edits-and-staging-the-unstaged"></a>
### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어
이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을꺼에요. 그 다음 스테이시를 다시 불러와 추가를 해요.
이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을거에요. 그 다음 스테이시를 다시 불러와 추가를 해요.
```sh
$ git stash -k
@ -398,7 +398,7 @@ $ git stash pop
$ git reset
```
이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (레파지토리 최상단 루트에서 실행해야 할꺼에요)
이 방법은 커밋되지 않은 모든 로컬 변경점이 되돌려 져요. (레파지토리 최상단 루트에서 실행해야 할거에요)
```sh
$ git checkout .
@ -535,7 +535,7 @@ $ git reset --hard c5bc55a
서버에 변경점을 푸시 안했는지부터 확인해요.
`git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄꺼에요:
`git status` 가 오리진보다 몇개의 커밋들이 앞서 있는지 보여줄거에요:
```sh
(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^`를 쓰고 싶지 않다면, 마스터 브랜치로 옮길 커밋 해시를 알아둬요 (`git log`가 트릭을 부릴 꺼에요) 그리고 그 해쉬로 리셋을 해요. `git push`가 리모트랑 변경점이 똑같은걸 확인해줄꺼에요.
대안으로, `HEAD^`를 쓰고 싶지 않다면, 마스터 브랜치로 옮길 커밋 해시를 알아둬요 (`git log`가 트릭을 부릴 거에요) 그리고 그 해쉬로 리셋을 해요. `git push`가 리모트랑 변경점이 똑같은걸 확인해줄거에요.
예를 들자면, 그 마스터의 커밋의 해쉬가 `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."
```
그 커밋을 브랜치(아마 feature일수도 있고, `develop` 일수도 있겠죠)에 넣고 싶을 때, 모든 파일을 지키는데 관심이 있을꺼에요. 큰 커밋을 작게 나누고 싶을꺼에요.
그 커밋을 브랜치(아마 feature일수도 있고, `develop` 일수도 있겠죠)에 넣고 싶을 때, 모든 파일을 지키는데 관심이 있을거에요. 큰 커밋을 작게 나누고 싶을거에요.
현재 가지고 있는건:
@ -626,7 +626,7 @@ HEAD is now at a13b85e
<a name="cherry-pick"></a>
### 한 브랜치에 다른 브랜치에 남겼어야 하는 커밋을 여러개 남겼어
마스터 브랜치에 있다고 가정하고 `git log` 해보면 커밋 두개 볼 수 있을꺼에요:
마스터 브랜치에 있다고 가정하고 `git log` 해보면 커밋 두개 볼 수 있을거에요:
```sh
(master)$ git log
@ -838,7 +838,7 @@ Switched to a new branch 'daves'
(`--track` 은 `git checkout -b [branch] [remotename]/[branch]` 의 축약이에요)
`daves` 브랜치의 로컬 카피를 줄꺼에요. 그리고 푸시된 업데이트들도 리모트로 표시돼요.
`daves` 브랜치의 로컬 카피를 줄거에요. 그리고 푸시된 업데이트들도 리모트로 표시돼요.
### 현재 로컬 브랜치로 새로운 리모트 브랜치를 만들고 싶어
@ -853,7 +853,7 @@ $ git push -u <remote> HEAD
```
`push.default` 설정의 `upstream` 모드와 `simple`모드 (2.0 버전의 깃의 기본)와 함께,
아래 커맨드는 이전에 `-u` 옵션으로 등록된 리모트 브랜치와 관련된 현재 브랜치를 푸시할꺼에요:
아래 커맨드는 이전에 `-u` 옵션으로 등록된 리모트 브랜치와 관련된 현재 브랜치를 푸시할거에요:
```sh
$ git push
@ -881,7 +881,7 @@ $ git branch -u [remotename]/[branch] [local-branch]
### HEAD를 기본 리모트 브랜치로 트래킹하도록 설정하고 싶어
리모트 브랜치를 확인해보는 것으로, HEAD가 트래킹 중인 리모트 브랜치를 볼 수 있어요. 몇몇 경우에는, 원하던 브랜치가 아닐꺼에요.
리모트 브랜치를 확인해보는 것으로, HEAD가 트래킹 중인 리모트 브랜치를 볼 수 있어요. 몇몇 경우에는, 원하던 브랜치가 아닐거에요.
```sh
$ git branch -r
@ -911,7 +911,7 @@ origin/HEAD set to master
<a name="undo-rebase"></a>
### 리베이스/머지 한 걸 되돌리고 싶어
현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을꺼에요.
현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을거에요.
깃은 위험한 과정 전에 원래의 HEAD 포인트를 ORIG_HEAD라 불리는 변수에 보관해요, 그러니 리베이스/머지 전 상태로 브랜치를 복구하기 간단해요.
```sh
@ -921,9 +921,9 @@ origin/HEAD set to master
<a name="force-push-rebase"></a>
### 리베이스를 했는데, 강제 푸시하고 싶진 않아
아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 떄문이죠.
리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을꺼에요.
많은 분들이 머지 워크플로우를 리에비스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요.
아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 때문이죠.
리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을거에요.
많은 분들이 머지 워크플로우를 리베이스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요.
주의해서 쓰세요.
리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요:
@ -950,7 +950,7 @@ origin/HEAD set to master
(my-branch)$ git commit -am "New awesome feature"
```
좀더 조정하고, 시간기록까지 보관하고 싶다면, 대화형 리베이스가 필요할꺼에요.
좀더 조정하고, 시간기록까지 보관하고 싶다면, 대화형 리베이스가 필요할거에요.
```sh
(my-branch)$ git rebase -i master
@ -963,7 +963,7 @@ origin/HEAD set to master
(master)$ git rebase -i HEAD~2
```
대화형 리베이스를 실행하면 텍스트 에디터로 이런 것들을 볼 수 있을꺼에요.
대화형 리베이스를 실행하면 텍스트 에디터로 이런 것들을 볼 수 있을거에요.
```vim
pick a9c8a1d Some refactoring
@ -994,7 +994,7 @@ pick e3851e8 another fix
다음으로 `pick` 부분을 다른 명령어로 바꾸거나, 해당하는 라인을 지워서 커밋을 지울 수도 있어요.
예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할꺼에요:
예를 들자면 **오래된 (첫번째) 커밋만 두고 두번째 오래된 커밋과 나머지를 다 합치고 싶을때**, 첫번째와 두번째 커밋 제외한 나머지 커맨드들을 `f`로 바꿔야 할거에요:
```vim
pick a9c8a1d Some refactoring
@ -1003,7 +1003,7 @@ f b729ad5 fixup
f e3851e8 another fix
```
이 커밋들을 합치고 **커밋 이름을 바꾸고 싶다면**, 추가로 적어줘야 해요 두번째 커밋 다음에 `r`를 추가하거나 간단히 `f` 대신 `s`를 추가해주면 될꺼에요:
이 커밋들을 합치고 **커밋 이름을 바꾸고 싶다면**, 추가로 적어줘야 해요 두번째 커밋 다음에 `r`를 추가하거나 간단히 `f` 대신 `s`를 추가해주면 될거에요:
```vim
pick a9c8a1d Some refactoring
@ -1027,7 +1027,7 @@ Newer, awesomer features
#
```
전부 다 성공하면, 이런 메세지를 볼꺼에요:
전부 다 성공하면, 이런 메세지를 볼거에요:
```sh
(master)$ Successfully rebased and updated refs/heads/master.
@ -1052,8 +1052,8 @@ Newer, awesomer features
<a name="rebase-unpushed-commits"></a>
#### 푸시 되지 않은 커밋만 합치고 싶어
가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을꺼에요.
다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을꺼에요.
가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을거에요.
다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을거에요.
```sh
(master)$ git rebase -i @{u}
@ -1063,7 +1063,7 @@ Newer, awesomer features
#### 머지를 중단해야해
때떄로 머지는 어떤 파일에 문제를 일으킬 수도 있어요, 이 경우 옵션 `abort`으로 현재 충돌 해결 프로세스를 중단하고 병합하기 전 상태로 다시 구성할 수 있어요.
때때로 머지는 어떤 파일에 문제를 일으킬 수도 있어요, 이 경우 옵션 `abort`으로 현재 충돌 해결 프로세스를 중단하고 병합하기 전 상태로 다시 구성할 수 있어요.
```sh
(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
```
이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄꺼에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄꺼구요. 다른 옵션은 이렇게:
이 명령은 어디에는 있고 다른덴 없는 커밋이 있나를 알려줄거에요 그리고 브랜치들 사이에 공유되지 않은게 목록을 보여줄 거구요. 다른 옵션은 이렇게:
```sh
(master)$ git log master ^feature/120-on-scroll --no-merges
@ -1105,7 +1105,7 @@ noop
#### 충돌이 있어
리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할꺼에요.
리베이스를 똑바로 끝내지 못했다면, 충돌을 해결해야 할거에요.
어떤 파일이 충돌났는지 `git status`를 먼저 실행해봐요:
@ -1129,7 +1129,7 @@ Changes not staged for commit:
>>>>>>> new-commit
```
새로운 커밋으로 추가된 코드(예시에선, 중간 선부터 `new-commit` 까지의)와 `HEAD` 사이에서 차이점을 해결해야 할꺼에요.
새로운 커밋으로 추가된 코드(예시에선, 중간 선부터 `new-commit` 까지의)와 `HEAD` 사이에서 차이점을 해결해야 할거에요.
어느 한쪽 브랜치의 코드를 남기고 싶다면, `--ours` 또는 `--theirs`를 쓰면 돼요:
@ -1214,7 +1214,7 @@ $ git stash list
$ 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>
### 작성자나 커미터를 찾고 싶어
작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓼 수 있어요:
작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓸 수 있어요:
```sh
$ git log --author=<name or email>
@ -1263,7 +1263,7 @@ $ git log -- <path to file>
$ git log -- **/*.js
```
와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할꺼에요:
와일드 카드를 쓸 때, 커밋된 파일의 목록을 볼 수 있는 `--name-status`로 확인하는게 유용할거에요:
```sh
$ git log --name-status -- **/*.js
@ -1344,14 +1344,14 @@ $ git fsck --unreachable | grep tag
$ 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)을 이용해서 풀 리퀘스트 자체를 확인할 수 있어요.
PR#1의 내용을 pr_1이란 새 브랜치로 패치 받을려면:
PR#1의 내용을 pr_1이란 새 브랜치로 패치 받으려면:
```sh
$ git fetch origin refs/pull/1/head:pr_1
@ -1471,7 +1471,7 @@ $ touch mydir/.gitkeep
인증이 필요한 레파지토리를 가지고 있을 텐데요.
이런 경우 유저명과 비밀번호를 캐시할 수 있을테니 매번 푸시/풀 할 때마다 입력할 필욘 없어요.
크리덴셜 헬퍼가 해줄꺼에요.
크리덴셜 헬퍼가 해줄거에요.
```sh
$ git config --global credential.helper cache
@ -1535,14 +1535,14 @@ c10f740 HEAD@{2}: checkout: moving from master to 2.2
저기에선, 오래된 커밋으로 리셋하기 어려워요. 최신 활동이 `HEAD@{0}` 상단 라벨로 보여지네요.
만약 실수로 뒤로 이동했다면,
리플로그는 실수로 지워진 2개의 커밋 전 상태인 (0254ea7)를 가르키는 커밋 마스터를 포함할꺼에요.
리플로그는 실수로 지워진 2개의 커밋 전 상태인 (0254ea7)를 가리키는 커밋 마스터를 포함할거에요.
```sh
$ git reset --hard 0254ea7
```
`git reset`을 쓰는 것으로 마스터를 이전 커밋으로 되돌릴 수 있어요.
이력이 실수로 변경됐을 때의 안정망을 제공할꺼에요.
이력이 실수로 변경됐을 때의 안정망을 제공할거에요.
([여기](https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog)에서 복제해와 수정했어요).