diff --git a/README_kr.md b/README_kr.md index 664bd76..13acd89 100644 --- a/README_kr.md +++ b/README_kr.md @@ -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 :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)을 참고해주세요. @@ -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 ``` -계속 할 수 있을꺼에요. +계속 할 수 있을거에요. ### 머지를 실수로 커밋, 푸시해버렸어 @@ -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`는 로컬에 저장된 부분과 스테이지에 있는 라인들을 비교해서 보여줄 거에요. ### 하나의 파일 변경점을 두개의 다른 커밋에 남기고 싶어 @@ -354,7 +354,7 @@ $ git add -N filename.x ### 아직 스테이지에 안 올라간 변경점을 스테이지에 추가하고, 스테이지에 있는 변경점을 다시 빼고 싶어 -이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을꺼에요. 그 다음 스테이시를 다시 불러와 추가를 해요. +이건 좀 꼼수인데요, 스테이지 전인 파일들을 스테이시해서 빼두고선 리셋 할 수 있을거에요. 그 다음 스테이시를 다시 불러와 추가를 해요. ```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 ### 한 브랜치에 다른 브랜치에 남겼어야 하는 커밋을 여러개 남겼어 -마스터 브랜치에 있다고 가정하고 `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 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 ### 리베이스/머지 한 걸 되돌리고 싶어 -현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을꺼에요. +현재 브랜치를 의도하지 않던 브랜치로 머지 또는 리베이스 했거나, 리베이스/머지 도중에 완료하거나 끝내지 못했을거에요. 깃은 위험한 과정 전에 원래의 HEAD 포인트를 ORIG_HEAD라 불리는 변수에 보관해요, 그러니 리베이스/머지 전 상태로 브랜치를 복구하기 간단해요. ```sh @@ -921,9 +921,9 @@ origin/HEAD set to master ### 리베이스를 했는데, 강제 푸시하고 싶진 않아 -아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 떄문이죠. -리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을꺼에요. -많은 분들이 머지 워크플로우를 리에비스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요. +아쉽게도 그런 변경점을 리모트 브랜치에 반영하려면 강제 푸시밖에 방법이 없어요. 이력을 변경해왔기 때문이죠. +리모트 브랜치는 강제 푸시 외엔 적용 해주지 않을거에요. +많은 분들이 머지 워크플로우를 리베이스 워크플로우보다 선호하는 많이 이유 중 하나죠 - 큰 팀에선 개발자의 강제 푸시로 곤란해질 수 있어요. 주의해서 쓰세요. 리베이스를 그나마 안전하게 쓰는 방법은 리모트 브랜치의 모든 변경점과 똑같이 반영하는게 아니라 대신에 이렇게 해봐요: @@ -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 #### 푸시 되지 않은 커밋만 합치고 싶어 -가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을꺼에요. -다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을꺼에요. +가끔 여러가지 작업 도중인 커밋을 푸시하기 전에 합치고 싶을거에요. +다른 누군가가 벌써 참고해서 커밋을 만들고 있을테니 이미 푸시된 커밋을 잘못 합치길 바라진 않을거에요. ```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" ### 작성자나 커미터를 찾고 싶어 -작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓼 수 있어요: +작성자나 커미터의 모든 커밋을 찾으려면 이렇게 쓸 수 있어요: ```sh $ git log --author= @@ -1263,7 +1263,7 @@ $ git log -- $ 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/ ``` -이제 태그가 복구돼있을꺼에요. +이제 태그가 복구돼있을거에요. ### 지워진 패치 만약 깃헙에서 누군가가 풀리퀘스트를 보냈는데 이미 원래의 포크가 지워졌다면, -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)에서 복제해와 수정했어요).