자주 실수하는 git

소프트웨어에 개발에서 실수를 했을 때, 간단히 돌아오는 방법이 있습니다. GIT을 사용해서 프로젝트를 관리한다면 실수에서 벗어나는데 큰 도움이 됩니다.

1. 추적 된 파일 추적 금지

빈번히 발생하는 일 중에 node_modules를 포함해서 commit 했고, .gitignore파일이 없다는 것을 발견 했습니다. 이제서야 .gitignore에 node_modules를 추가 했지만, git은 여전히 node_modules 을 추적하고 있습니다.
git base에 commit이 되면서 git이 계속변경 사항을 추적하기 때문입니다. 이를 중지하기 위해서는 아래와 같이 입력 합니다.

git base 에 있는 파일이 삭제 됩니다.

git rm -r --cached node_modules

2. 마지막 commit 수정

local -> git remote 로 commit을 했습니다. 그 후 커밋 파일에 변경 사항을 포함하는 것을 잊었습니다. 또는 가장 최근 커밋한 동일한 커밋에 연결하려는 새 파일을 추가합니다.

git은 이전 커밋을 잠금 해제하고 새 파일을 추가 할 수 있습니다.

git add newfile

git commit --amend -no-edit

--no-edit: commit 메세지를 변경하지 않고, comiit을 수정합니다.

3. 마지막 commit 메세지 수정

위의 수정내용과 비슷합니다. git에 commit을 했는데, commit 한 메세지가 원하는 내용과 달라졌습니다.

git commit --amend -m '메세지가 #2 로 바뀜'

4. 작업 폴더내의 작업내역 삭제

프로젝트를 진행하고 있습니다. 코드를 수정하는 동안 프로그램이 손상되었고, 실제로 무엇이 잘못 되었는지 파악할 수 없게 되었습니다.
현재 작업내용을 취소하고 마지막 commit 시점으로 돌아가야 할 것 같습니다.

git restore .

또는

git reset --hard

이 작업 local 저장소에서 최근 커밋으로 복원 합니다. 커밋하지 않는 내용은 모두 손실 됩니다.

5. 특정파일에 대한 작업 내용 취소

local 저장소의 파일을 수정했습니다. 히지만, test.js 파일의 변경 사항이 의미가 없었다는 것을 알고, 폐기하려고 합니다.

git restore test.js

6. 시간을 거슬러 이전 버전으로 파일 복원

위의 명령어와 달리 파일을 이전 특정 시점 상태로 돌아가기를 원합니다. test.js 파일을 최근 commit 된 내용이 v10 이지만, v2 시점으로 돌아가려고 합니다.

git log


commit d94629103526ddfa0715ca9393362a3b70e097b
Merge: aa034a93 1809aa89
Date:   Tue Aug 9 07:40:00 2022 +0900

    Merge pull request #15 from aaaaaday/master

commit 1809aklflkajlkhfeff890913ec751b36167560
Date:   Sun Aug 7 16:26:45 2022 +0100

    리뷰에 따라 수정 완료

commit 1b93eehwkhflwkehf280b513806b000dd033b9f
Date:   Sat Aug 6 00:58:16 2022 +0100

    원문과 최대한 라인수 일치하도록 수정

를 통해 복원하려고 하는 시점의 commit hash 를 찾습니다.

git restore --source <commit-hash> <파일이름>

7. 삭제한 파일 복원 (이전 commit)

프로젝트를 새로 변경하고 있는데 사용되지 않는 파일이 표시됩니다. 계속해서 파일을 삭제 했습니다.
그러나, 삭제한 파일 deleted_file.js가 필요하다는 것을 알게 되었습니다.

git restore deleted_file.js

8. local 저장소의 모든 변경사항을 remote 상태로 취소합니다.

local repo 브런치에세 몇가지 변경 사항과 commit을 했습니다. 그런데, 변경 사항을 모두 pull을 받았을 당시로 되돌리려고 합니다.

git reset --hard origin/master

commit 되지않는 파일은 영구적으로 삭제 됩니다.

9. 추적되지 않는 파일 삭제 (untracked file)

프로젝트에 여러 개의 새 파일을 만들고 일부 파일도 수정했습니다. 접근 방식을 변경했으며 이제 생성한 새 파일이 더 이상 필요하지 않지만, 수정된 파일 변경 사항을 유지하기로 결정했습니다.
Git은 추적되지 않은 파일을 제거하는 명령을 제공합니다.

git clean -f

git clean 명령에는 force 지시문(또한 --force)을 의미하는 -f 플래그가 필요합니다.

이 작업에는 추적되지 않은 파일 삭제가 됩니다. Git에서 커밋되지 않은 작업을 제거하는 것은 취소할 수 없습니다.

기본적으로 이 명령은 .gitignore로 지정된 추적되지 않은 폴더나 파일을 제거하지 않습니다. 무시된 파일을 제거하려면 -x 옵션을 지정하십시오. 또한 git clean은 디렉토리에서 재귀적으로 작동하지 않습니다.
이것은 우발적인 영구 삭제를 방지하기 위한 또 다른 안전 메커니즘입니다. 디렉토리를 제거하려면 다음과 같이 -d 플래그를 사용하십시오.

자식 청소 -df 이렇게 하면 추적되지 않은 파일과 디렉토리가 지워지지만 .gitignore 파일에 나열된 파일과 디렉토리는 제거되지 않습니다.

10. commit 을 다른 branch로 전환

프로젝트가 발전했으며 현재 newsletter 추가와 layout 미세 조정이라는 두 가지 기능을 작업하고 있습니다. newletter와 layout이라는 두 개의 별도 분기를 만들었으며 각 분기를 관련 기능인 뉴스레터 및 레이아웃 전용으로 지정했습니다.

현재 뉴스레터 기능을 추가하고 있으며 뉴스레터 분기에서 몇 가지 커밋을 수행하고 있습니다. 다음에 프로젝트로 돌아올 때 레이아웃 기능에 대해 작업하려고 하는데 연결된 레이아웃 분기로 전환하는 것을 잊었습니다. 잘못된 뉴스레터 분기에서 레이아웃 기능을 추가하고 커밋했습니다.

나중에 뉴스레터 분기에 추가한 커밋이 실제로 레이아웃 분기에 속한다는 사실을 알게 됩니다.

따라서 커밋 추가 레이아웃 기능이 뉴스레터 분기에서 올바른 레이아웃 분기로 이동되기를 원합니다.

Git에서 수행할 작업은 다음과 같습니다.

newleter 지점으로 checkout

git checkout newletter

레이아웃 기능을 추가한 커밋의 커밋 해시를 찾아 복사합니다. 다음 명령을 실행합니다.

git log
# aceew89e0ac

이 커밋으로 적용하려는 올바른 브랜치를 확인하십시오. 우리의 경우:

git checkout layout

# 확인한 hash을 layout branch에 적용
git cherry-pick <commit-hash> 

그런 다음 뉴스레터 분기를 확인합니다.

git checkout newletter
# 잘못 commit 한 내용을 삭제 합니다.
git reset HEAD~1 --hard
or
git reset HEAD^ --hard

HEAD~1은 뉴스레터 브랜치를 재설정하여, 가장 최근 커밋 뒤로 하나의 커밋을 옮기고 다른 곳으로 이동한 커밋을 제거한다는 의미입니다. 우리의 경우 이 newletter 분기에 대한 최신 커밋은 layout 기능이 있는 커밋이었습니다.

11. 삭제된 branch 부활시키기

더 이상 기능 브랜치가 필요하지 않다고 생각하고 삭제했습니다. 다음번에는 삭제가 실수였다는 사실을 알 수 있습니다. 이 황당한 사건에 대해서 당황해 합니다. 당신은 불가능하게 시간을 되돌려 그것을 되찾고 싶어합니다.
삭제된 브랜치를 되돌리고 싶어합니다.

삭제된 브랜치를 복구하는 방법은 다음과 같습니다.

명령을 실행할 때 나열될 삭제된 분기의 커밋 해시를 찾아 복사합니다.

git reflog

그런 다음 다음과 같이 분기를 다시 만듭니다.

git branch <new-branch-name> <삭제된 브런치 hash>

이것은 <deleted-branch-commit-hash>까지의 모든 작업을 포함할 분기를 다시 생성합니다. <deleted-branch-commit-hash>가 삭제된 분기의 최신 작업이 아닌 경우, 최신 작업이 있는 커밋을 얻을 때까지 새 커밋 해시를 찾을 수 있습니다.
git branch를 입력하면 이전에 삭제한 브랜치가 다시 나열되는 것을 볼 수 있습니다. 이것은 Origin(remote)에서 브랜치가 삭제된 경우에도 작동합니다.

<branch-name>이 원하는 이름이 아닌 경우 git branch -m <branch-name> <new-branch-name>으로 이름을 바꾸면 됩니다.

삭제된 브랜치를 성공적으로 되돌리는 열쇠는 올바른 커밋 해시를 찾는 것입니다. 커밋의 이름을 똑똑하게적 지정하십시오. 그것은 많은 도움이됩니다.

12. 잘못된 commit 되돌리기

팀에서 새 버전의 프로젝트를 출시했습니다. 추가된 모든 새로운 기능이 절대적인 마스터 클래스임을 모두 확신합니다. 잠시 후 팀 리더의 긴급 전화로 새 버전에 중요한 결함이 있으며 즉시 수정해야 한다는 연락이 왔습니다. 엔지니어링 팀은 긴급 조치를 취해야 하며, 앉아서 결함을 찾는 것은 긴급한 문제에 대한 적절한 대응이 아닙니다.

가장 빠른 응답 중 하나는 오류가 발생하기 쉬운 릴리스에 대한 변경 사항을 취소하는 것입니다. 따라서 커밋에 대한 변경 사항을 취소하고 싶습니다.

Git에서 진행하는 방법은 다음과 같습니다.

변경 사항을 취소하려는 커밋(깨진 커밋)의 커밋 해시를 찾아 복사합니다.

git log
# 해당 커밋에 지정된 변경 사항 되돌리기
git revert <잘못 된 commit-hash>

git revert는 되돌린 변경 사항으로 새 커밋을 만듭니다.

깨진 커밋에 지정된 모든 변경 사항은 새 커밋에서 롤백됩니다. 예를 들어, 깨진 커밋에서 제거된 모든 것이 새 커밋에 추가되고, 깨진 커밋에서 추가된 모든 것이 새 커밋에서 제거됩니다.
생성될 커밋 되돌리기에 대한 기본 커밋 메시지와 함께 기본 편집기가 팝업됩니다. 원하는 대로 수정할 수 있습니다.

13. merge(병합) 취소

기능 분기의 새로운 변경 사항에 만족합니다. 기능 브랜치를 메인 브랜치에 병합할 준비가 된 것 같습니다. 따라서 기본 분기에서 기능 분기를 병합하고, 새 변경 사항을 원격 저장소에 푸시합니다.

잠시 후, 병합이 실제로는 그다지 좋은 코드가 아니라는 것을 알게 되었습니다. 그래서 병합을 취소하고 싶습니다.

# master branch로 이동합니다
git checkout master
# 병합 commit의 hash를 확인합니다
git log
# 되돌리기
git revert -m 1 <merge-commit-hash>

병합의 분기는 해당 병합의 부모입니다.

일반적으로 git은 병합의 어느 쪽(부모)이 메인라인으로 간주되어야 하는지 모르기 때문에 병합을 되돌릴 수 없습니다. git revert -m 1 메인라인의 상위 번호를 지정하고 지정된 상위 항목에 상대적인 변경 사항을 되돌리기 위해 revert를 허용합니다.

일반적으로 git merge 중에 가장 먼저 기록되는 부모는 병합할 때 있던 분기입니다. 여기서 오류의 경우 메인 브랜치에서 체크아웃하는 동안 feature 브랜치를 병합했습니다. 따라서 -m 1은 주 분기를 지정합니다.

14. 이전 버전으로 롤백

프로젝트를 이전 버전으로 롤백할 수 있습니다. 이렇게 하면 최근에 깨진 커밋 이전에 올바르게 작동하던 버전으로 돌아가려고 합니다.

여기에 표시된 git 명령은 기록을 다시 씁니다. 다른 사람과 소프트웨어 프로젝트를 공동 작업할 때는 적합하지 않습니다. 부득이 작업을 하게 된다면 다른 사람들에게 해당 내용을 공유하여야 합니다.

따라서 리포지토리의 기록을 되감아 프로젝트의 이전 버전으로 이동하려고 합니다.

git reset --hard <commit-hash>

git reset은 HEAD 포인터(따라서 작업 트리)를 이전 버전(<commit-hash>)으로 이동합니다.
이 버전 이후의 커밋은 프로젝트 기록에서 제거됩니다.

--hard 플래그는 스테이징 영역과 작업 트리를 재설정합니다.

git reset --mixed <commit-hash>와 같은 --mixed 플래그를 사용하면 저장소를 작업 트리의 지정된 커밋 해시 보존 파일로 다시 재설정합니다. 이후 커밋에 있었지만 재설정한 커밋에는 없는 파일은 추적되지 않는 파일이 됩니다.

--mixed 플래그는 인덱스(스테이징 영역)를 처리하는 방식에 차이가 있지만 --soft와 가까운 사촌이 있습니다.

--mixed 플래그는 스테이징 영역(색인)을 재설정하지만 작업 트리는 재설정하지 않습니다. 따라서 다음 커밋에서 추적되지 않은 파일을 추가하려면 git add 다음 git commit해야 합니다.

--soft 플래그는 스테이징 영역이나 작업 트리를 재설정하지 않습니다. 따라서 다음 커밋에서 추적되지 않은 파일을 추가하려면 git commit만 하면 됩니다.

15. 이전 커밋 메시지 수정

프로젝트 진행에 만족합니다. 프로젝트 기록을 살펴보고 있습니다. 하지만, 모호한 커밋 메시지를 발견했습니다. 따라서 이 메시지를 논리적 의미를 설명하는 더 나은 메시지(더 나은 설명이 있는 메시지)로 변경하려고 합니다.

Git에서 대화형(interactive) rebase를 사용하여 기록에서 더 깊은 커밋 메시지를 편집할 수 있습니다. 커밋 메시지를 변경하려는 커밋의 커밋 해시를 찾아 복사합니다.

rebase 대화형 세션을 엽니다.

git rebase -i <commit-hash>

편집기가 나타납니다.

위의 샘플 대화형 rebase 세션에서 1행에 오타가 있음을 알 수 있습니다. 이 오타를 수정하고 더 나은 설명 메시지를 제공하겠습니다.

편집기에서 수행하려는 작업만 지정합니다. 지금 당장 커밋 메시지를 다시 작성하고 싶을 수 있지만, 그렇게 하지는 않습니다. rebase -i는 SHA(커밋 해시) 열 이후의 모든 것을 무시합니다. 그 뒤의 텍스트는 커밋 해시가 무엇인지 기억하는 데 도움이 됩니다.

커밋의 내용을 유지하지만 커밋 메시지를 편집하려면 메시지를 변경하려는 커밋에 대해 reword action 명령을 지정하십시오. 다음과 같이 첫 번째 열의 단어 선택을 단어 reword(또는 r만)로 바꾸면 됩니다.

 (1 year, 7 months ago) Auto Deploy (Merge pull request #3 from node/translation/ch03 - github-actions[bot]
noop

# Rebase 53723b64..53723b64 onto 53723b64 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Reword 리베이스 작업

그런 다음 편집기를 저장하고 닫습니다.

마지막으로 git은 커밋 메시지를 변경할 수 있는 편집기를 엽니다. 커밋 메시지를 더 나은 것으로 변경하십시오.

이전 커밋 메시지 업데이트

마지막으로 편집기를 저장하고 닫을 수 있습니다. 커밋은 새 커밋 메시지로 업데이트됩니다.

16. 오래된 커밋 삭제

오래된 커밋이 당신을 귀찮게 할 수 있으며 프로젝트 기록에서 삭제되기를 원할 수 있습니다. 따라서 이 커밋이 더 이상 프로젝트 기록에 나타나지 않기를 원합니다.

다음과 같이 이 커밋을 삭제할 수 있습니다.

먼저, 예정된 커밋의 커밋 해시를 찾아 복사합니다.

git log

git rebase -i <commit-hash>

커밋을 삭제하기 위한 drop 액션 단어를 지정합니다:

pick f39873d 안녕
pick c33dih3 방가워
drop 24dddvw 삭제하고 싶은 commit
pick dpojafe 하하하

편집기를 저장하고 닫습니다. 예정된 커밋은 프로젝트 기록에서 제거됩니다.

17. 이전 커밋에 새로운 변경사항 수정

프로젝트에 변경 사항을 추가하려는 상황이 발생할 수 있습니다. 그러나 이 변경 사항은 특정 변경 사항을 처리하던 당시의 커밋과 관련이 있습니다.

예를 들어, 프로젝트는 여러 커밋으로 발전했으며 아마도 가장 최근 커밋을 프로젝트의 v5로 브랜드화할 수 있습니다. file.js을 만들었습니다. 당신은 이 파일이 아마도 프로젝트 v2에서 더 깊은 기록의 이전 커밋의 일부가 되기를 원합니다.

Git에서는 새로운 변경 사항을 커밋에 다시 결합하여 이전 커밋을 편집할 수 있습니다.

단계는 다음과 같습니다.

편집용으로 표시하려는 커밋의 커밋 해시를 찾아 복사합니다.

git log

#rebase interactive
git rebase -i "<commit-hash>^"

<commit-hash> 끝에 캐럿(^)을 추가하는 방법에 유의하십시오. 이렇게 하면 이 표시된 커밋을 편집한 후 커밋의 원래 연대기로 돌아가고 싶다고 Git에 알릴 수 있습니다. git rebase -i "<commit-hash>^"를 실행하면 git log에 표시된 <commit-hash>가 가장 최근 커밋으로 표시되기 때문입니다.

이 명령을 실행하면 기본 편집기가 나타나고, <commit-hash>를 언급하는 줄에서 편집할 작업 동사 선택을 수정합니다.

작업 트리와 프로젝트 기록은 이제 이전에 커밋했을 때의 상태입니다. git log를 실행하면 <commit-hash>가 가장 최근 커밋임을 알 수 있습니다. 작업 트리에 생성한 파일(file.js)이 여전히 있으며 가장 최근 커밋으로 수정할 수 있는 좋은 기회입니다. 이 시점에서 가장 최근 커밋이 편집하려는 커밋임을 기억하십시오.

따라서 다음과 같이 수정하십시오.

git add file.js
git commit --amend --no-edit
# 기록을 정상순서로 되돌리기
git rebase --contirnue

이런 식으로 file.js을 추가하여 <commit-hash>에 지정된 커밋을 편집했습니다.

경고: 이렇게 하면 해당 시점부터 기록이 다시 작성됩니다. 팀 환경에서 프로젝트를 작업할 때는 좋은 생각이 아닙니다.

팀프로젝트에서는 기록을 다시 쓰는 것은 지양해야 합니다. 많은 소스 꼬임이 발생할 수 있습니다.