일반적인 Git 실수는 무엇이며 어떻게 수정합니까?

붐과 함께 IT 담당자가 동시에 여러 데이터에 대해 작업하는 것은 불가피하며 데이터는 시간이 지남에 따라 계속 진화합니다. 또한 데이터의 모든 변경 사항을 추적하고 필요한 경우 원치 않는 변경 사항을 실행 취소하거나 되돌릴 준비를하는 것도 중요합니다.

나는 Git에서 내 데이터를 버전 화하면 프로젝트 개발에서 더 실험적이 될 수 있다고 고백해야한다. 내가 엉망이되면 git은 항상 내 프로젝트의 해당 버전을 내가 망쳐 놓기 전의 방식으로 실행 취소 및 / 또는 되돌릴 수있는 방법을 알고 있습니다. 마다 레이어는 다음 단계에서 데이터를 이동하기 전에 데이터 변경 사항을 검토, 수정 및 / 또는 수정할 수 있도록 설계되었습니다. 따라서 다음은이 블로그에서 다루는 실수입니다.

• • Index에서 파일 / 디렉토리 언 스테이징
  • 마지막으로 커밋 된 메시지 편집
  • 마지막 커밋에서 일부 변경 사항을 잊었습니다.
  • 로컬 변경 사항 취소
  • 개인 데이터를 로컬 저장소에 커밋
  • 최신 커밋을 새 커밋으로 대체했습니다.
  • 잘못된 데이터를 커밋했습니다.
  • 내 이전 프로젝트 상태로 돌아 가기
  • 삭제 된 로컬 분기 복구
  • 커밋에서 수행 한 변경 실행 취소
  • 내 지점에 잘못된 이름을 지정했습니다.
  • 원격으로 푸시하기 전에 기록 로그를 다시 정렬하려는 경우
  • 관련없는 변경 사항을 단일 커밋으로 커밋했습니다.
  • 모든 브랜치의 모든 커밋에서 작성자 이메일 변경
  • 분실 및 발견 된 파일
  • 내 커밋 ID가있는 브랜치를 잊어 버렸습니다.
  • 기록에서 커밋 삭제
  • 잘못된 분기를 원격으로 푸시

Index에서 파일 / 디렉토리 언 스테이징

파일을 추가 및 / 또는 수정하는 동안 종종 모든 파일과 디렉토리를 색인에 추가하는 'git add'명령의 기본 동작을 사용하는 경향이 있습니다.많은 경우 특정 파일을 언 스테이징하거나 커밋하기 전에 마지막으로 수정해야 할 필요성을 느낍니다.

통사론: 자식 재설정

인덱스 영역에서 파일 스테이징을 해제하면 로컬 리포지토리에 커밋하기 전에 데이터를 다시 작업 할 수있는 또 다른 기회가 있습니다.

마지막으로 커밋 된 메시지 편집

명령: git commit --amend
새 커밋 메시지를 만들지 않고도 최신 커밋 메시지를 편집 할 수 있습니다. 커밋 로그를 나열하기 위해 별칭 'hist'를 설정했습니다.
명령: git config --global alias.hist 'log --pretty = format : '% C (노란색) % h % Creset % ad | % C (녹색) % s % Creset % C (빨간색) % d % Creset % C (파란색) [% an] '--graph --decorate --date = short'x

이미 원격 저장소로 푸시되고 다른 사람과 공유 된 커밋 메시지를 수정하지 마십시오. 이전 커밋 기록이 무효화되어 영향을받을 수있는 모든 작업에 영향을 미칠 수 있습니다.

마지막 커밋에서 일부 변경 사항을 잊었습니다.

수정하는 것을 잊고 이미 스냅 샷을 커밋했으며 실수를 강조하기 위해 다른 커밋을하고 싶지 않다고 가정 해 보겠습니다.
명령: git commit --amend

최근 커밋 객체의 sha-1 ID가 어떻게 재생성되고 변경되었는지 강조했습니다. 나는 두 변경 사항을 하나로 통합하는 단일 커밋을 만든 척했습니다.

로컬 변경 사항 취소

그래서 여기에 제가 'README'파일을 수정하고 스테이징 한 경우가 있습니다. 다음으로 동일한 파일을 두 번 수정했지만 두 번째 변경이 필요하지 않다는 것을 깨달았습니다.

이제 전체 변경 사항을 수동으로 실행 취소하지 않겠습니다. 파일의 준비된 버전을 가져 오기만하면됩니다.
통사론:
git checkout-– 파일의 로컬 변경
git checkout-– 디렉토리에있는 모든 파일의 로컬 변경 & shy & shy

명령: git checkout-README

그래서 파일에 대한 마지막 변경 사항을 버리고 파일의 준비된 버전을 수락했습니다. 다음 커밋에서는 파일의 준비된 버전 만 로컬 저장소에 저장됩니다.

개인 데이터를 로컬 저장소에 커밋

로컬 저장소에서 특정 데이터를 제거하고 파일은 작업 디렉토리에 보관하고 싶습니다.
통사론:
git reset --mixed HEAD ~
git reset --mixed

명령: git reset --mixed HEAD ~ 1
HEAD ~ 1은 현재 브랜치 HEAD가 가리키는 최근 커밋 직전 커밋을 나타냅니다.

현재 스냅 샷의 파일이 로컬 저장소와 스테이징 영역 모두에서 제거되었습니다. 전역 .gitignore 파일에 다음 패턴을 추가하여 git에서 추적하지 않도록 제외합니다.
vim ~ / .gitignore_global
# 암호 파일 #
*.통과하다
*.키
* .passwd

이를 통해 암호 파일의 스냅 샷이있는 커밋이 제거되고 깨끗한 스테이징 영역이 생깁니다. 내 파일은 여전히 ​​내 작업 디렉토리에 있지만 더 이상 로컬 저장소에 존재하지 않으며 원격 저장소에도 푸시되지 않습니다.

주의: 당신이 그들을 잃으면 git은 그것에 대해 알지 못하기 때문에 당신을 위해 그들을 복구 할 수 없습니다.

최신 커밋을 새 커밋으로 교체

통사론: git reset --soft [/ HEAD ~ n>]

‘–soft’옵션은 커밋 된 파일이 여전히 인덱스에 준비되어있는 동안 로컬 저장소에서 제거하고 검토 후 다시 커밋 할 수 있습니다. 로컬 저장소에서 제거하려는 스냅 샷의 sha-1입니다. 여기서 n은 HEAD 커밋 전 커밋 수입니다.

명령 :git reset --soft HEAD ~ 1

PHP mysql_fetch_array

파일 수정 및 다시 준비

명령: git commit -m 'index.html 및 style.css 추가'
이제 커밋 기록은 다음과 같습니다.

잘못된 데이터를 커밋했습니다.

통사론:
git reset --hard HEAD ~ n– 최근 커밋 된 스냅 샷 이전에 프로젝트를 'n'커밋으로 재설정
git reset --hard– 주어진 커밋 ID 스냅 샷으로 프로젝트 재설정

명령: git reset --hard HEAD ~ 1

최신 커밋과 손상된 파일이 로컬 저장소, 스테이징 영역 및 작업 디렉토리에서 제거됩니다.

주의: 작업 디렉토리에서 파일을 잃게되므로 위험한 명령입니다. 원격 공유 저장소에는 권장되지 않습니다.

내 이전 프로젝트 상태로 돌아 가기

시간의 역사에서 프로젝트의 이전 상태로 이동할 수 있습니다. 최신 버전을 엉망으로 만들거나 이전 코드를 개선해야하는 경우 현재 작업을 방해하지 않도록 이전 프로젝트 스냅 샷에서 다른 분기를 생성 할 수 있습니다. 방법을 살펴 보겠습니다.
ㅏ. 프로젝트 기록을 나열하고 이전 커밋 ID, 명령을 결정합니다.히스 토로 이동
비. 커밋 ID에서 다른 분기를 만듭니다.git checkout -b 이전 상태 e7aa9a5
씨. 코드 작업을 계속하고 나중에 '마스터'브랜치와 병합 / 리베이스합니다.

삭제 된 로컬 분기 복구

참조 분기에서 손실 된 작업을 다시 생성 할 수 있습니다. 메인 브랜치와 병합하지 않고‘old_code’브랜치를 삭제하고 작업을 잃었다 고 가정 해 보겠습니다. 그리고 아니요, 분기를 원격 저장소로 푸시하지 않았습니다. 그러면 어떻게됩니까? 잘 git은 각 참조에서 수행 된 모든 변경 사항을 추적하고 저널 항목을 유지합니다.퇴각하다

따라서 HEAD @ {2}는‘old_code’브랜치로 이동할 때 포인터입니다. 복구 해 보겠습니다.

통사론:git checkout -b
명령:git checkout -b old_code HEAD @ {2}

생성 당시의 최신 작업이있는 'old_code'브랜치에 있어야합니다. 또한 HEAD @ {1}의 'reflog'포인터는 'old_code'브랜치에서 만든 최근 커밋이었습니다. 커밋 명령을 다음과 같이 실행하십시오.git reset --hard HEAD @ {1}.또한 작업 디렉토리에서 수정 된 파일을 복원합니다.

이 명령의 작동 방식과 'reflog'항목을 관리하는 방법에 대해 자세히 알고 싶다면 이전 게시물을 읽어보십시오.git reflog에서 삭제 된 분기 복구.

커밋에서 수행 한 변경 실행 취소

가다돌아가는 것이전 커밋의 효과를 반전시키기 위해 일부 새 커밋을 기록하는 데 사용됩니다.
통사론: 자식 되돌리기
내 커밋 로그에서 강조 표시된 커밋 ID의 변경 사항을 되돌리고 싶습니다.

명령: 자식 복귀 827bc0d

공유 된 커밋을 '–hard'재설정하지 않고 대신 기록을 보존하기 위해 'git revert'하여 모든 사람이 기록 로그를 추적하여 누가 무엇을 되돌 렸는지 쉽게 알 수 있도록하는 것이 좋습니다. 그리고 왜?

HEAD ~ 3 또는 HEAD ~ 4 등과 같이 커밋 ID를 제공하는 대신 HEAD 포인터와 관련된 커밋을 참조하는 동일한 논리를 사용할 수 있습니다.

내 지점에 잘못된 이름을 지정했습니다.

로컬 브랜치 이름을 바꿀 수 있습니다. 한 위치에서 다른 위치로 모든 작업을 마이그레이션하는 고통을 겪지 않고 작업중인 문제에 따라 브랜치의 이름을 바꾸고 싶을 때가 여러 번 발생합니다. 예를 들어, 동일한 브랜치 또는 다른 브랜치에있을 수 있으며 아래와 같이 원하는 브랜치의 이름을 변경할 수 있습니다.
통사론: 자식 브랜치 -m
명령: git branch -m old_code old_ # 4920

git이이 이름 변경을 추적하고 있는지 궁금 할 수 있습니다. 예, 귀하의 'reflog'항목을 참조합니다. 다음은 내 것입니다.

분기 이름을 변경해도 원격 추적 분기에는 영향을주지 않습니다. 원격 저장소에서 브랜치를 대체하는 방법을 원격 섹션에서 볼 것입니다.

원격으로 푸시하기 전에 기록 로그 다시 정렬

내가 어떤 커밋을 다른 것보다 일찍했고 어떤 커밋을 전혀하지 않았 으면 좋겠다. 코드를 효과적으로 수정하거나 향상시키기 위해 이전 커밋을 대화식으로 다시 정렬하고 편집합니다.
통사론: 자식 rebase -i
명령: 자식 rebase -i fb0a90e– commit-id fb0a90e 이후에 작성된 커미트 리베이스 시작

다시 방문하십시오 자식 rebase '– 대화 형 또는 -i'리베이스가 일반 리베이스와 어떻게 다른지 이해하기위한 설명서

관련없는 변경 사항을 단일 커밋으로 커밋했습니다.

이 경우 오래된 매장 커밋을 여러 논리적 커밋으로 분할해야합니다.
통사론: 자식 rebase -i
명령: 자식 rebase -i fb0a90e
리베이스 편집기에서 e7aa9a5 커밋 ID를 선택하고 'pick'대신 'edit'로 변경해야합니다.

이제 프로젝트 버전의 커밋 id-e7aa9a5에 있습니다. 먼저 커밋 히스토리 및 스테이징 영역을 이전 commit-Command로 재설정합니다.git reset HEAD ~ 1
둘째, 파일을 개별적으로 편집 + 준비 + 커밋
명령어 :
git add code && git commit -m 'Adding initial codes'
git add newcode && git commit -m 'Adding new code'

셋째, 리베이스를 계속하고 종료하십시오.

명령 :git rebase --continue
넷째, 추가 커밋으로 기록을 확인합니다.

명령: 히스 토로 이동

네임 스페이스를 사용하는 C ++

모든 브랜치의 모든 커밋에서 작성자 이메일 변경

나는 오랫동안 git에서 내 프로젝트 파일의 버전을 관리하고 커밋했지만 지금까지 원격 저장소에 게시되는 커밋 기록 로그에서 내 이메일 ID가 손상되었다는 사실이 나에게 놀랐습니다. 글쎄, 이것은 '.gitconfig'파일에서 구성을 처음 설정할 때 누구에게나 발생할 수 있습니다. 고쳐 쓰기 커밋 객체를 생성 할 때 제공하는 환경 변수.

먼저 목록을 얻습니다. 이메일 ID 변경할 항목을 결정하려면 :
명령: git log --all --pretty = format : '% an % d'– 작성자 이름 (refname / branch-name)을 인쇄합니다.

둘째, 나는 각 지점의 모든 커밋 새 이메일 ID로 커밋 객체를 다시 작성하십시오.
명령:
git filter-branch --env-filter '
if [ '$ GIT_AUTHOR_NAME'= 'divya']
그때
GIT_AUTHOR_EMAIL = 'divya@github.com'
있다
' -- --모두

분실 및 발견 된 파일

특정 파일을 잃어 버리고 그 이름을 기억하지 못하지만 파일의 특정 단어를 기억할 수 있다고 가정합니다. 이 경우 다음 단계를 따를 수 있습니다.
1 단계: 검색된 패턴과 함께 파일 스냅 샷을 포함했던 모든 커밋을 나열합니다.
명령 :git rev-list --all | xargs git grep -i '타임 스탬프'

2 단계 : 강조 표시된이 commit-id에서 'lost-found'브랜치를 새로 만듭니다.
통사론: git checkout -b lost-found d8c6a76a6dcb1fc6e8c3f6b097e1bd07e7cd328f

내 커밋 ID가있는 브랜치를 잊어 버렸습니다.

때때로 버그가있는 커밋 ID를 감지 한 후이 커밋이있는 모든 브랜치를 알고 싶을 수도 있습니다. 대규모 다중 지점 프로젝트에서 각 지점의 역사를 확인하는 것은 그리 실용적이지 않습니다.

내 탐색 건물 응용 프로그램에서 만든 잘못된 커밋으로 인해 코드가 손상되었습니다. 잘못된 커밋 ID를 감지하는‘git bisect’명령 다음에명령:git branch --contains그 나쁜 커밋으로 분기를 나열합니다.

이제 여전히 잘못된 커밋이있는 모든 분기를 알고 있으므로이 변경 집합을 되돌 리거나 재설정 할 수 있습니다.

기록에서 커밋 삭제

때때로 나는 역사에서 커밋을 지우고 흔적을 남기지 않을 필요성을 느낍니다. 공유 브랜치에서이 스턴트를 시도하지 않고 로컬 브랜치에서만 시도하는 것이 좋습니다.
통사론: 자식 rebase -i
명령 :자식 rebase -i 93859d8
리베이스 편집기에서-> 강조 표시된 커밋 ID에 대해‘edit’를‘drop’으로 바꿉니다. 69f4813

경우에 따라 이러한 재 작성으로 인해 충돌이 발생할 수 있습니다. 충돌을 해결 한 다음 계속 진행해야합니다.

경고 : 이것은 히스토리를 다시 쓰고 데이터를 잃을 수 있으므로 위험한 명령입니다. 이러한 분기는 원격 상대와 다르며--힘또는-임대 강제선택권.

잘못된 분기를 리모컨으로 푸시

자, 여기 제가하고 싶은 일이 있습니다. 원격 지점 내 지역 지점에서 추적을 중지합니다. 'git push'명령과 함께 사용할 경우--지우다옵션은 원격 브랜치를 삭제합니다. 그래서 이것은 복제 된 프로젝트의 로컬 사본을 얻는 방법입니다.

git clone https://github.com/greets/myProj.git
cd myProj

일단 원격 분기가 삭제되면 공유 저장소의 다른 사용자가 원격 참조를 새로 고치고 업데이트해야합니다.--치다누락 된 개체 참조를 삭제하는 옵션 :git fetch --prune -v origin

이 게시물에서는 git이 해결하는 데 도움이 될 수있는 일반적인 실수 나 변경 사항에 대해 언급했습니다. 모든 코드는 고유하고 고유 한 방식으로 개발되므로 문제에 접근하고 해결하는 다양한 방법이 있습니다. 언제든지 공식을 참조 할 수 있습니다. 자식 문서 다양한 git 명령이 소스 코드를 보호하는 방법과 명령을 가능한 최선의 방법으로 활용하는 방법을 이해합니다.

이제 일반적인 Git 실수를 이해 했으므로 다음을 확인하십시오. 전 세계에 250,000 명 이상의 만족 한 학습자 네트워크를 보유한 신뢰할 수있는 온라인 학습 회사 인 Edureka에서 작성했습니다. Edureka DevOps 인증 교육 과정은 학습자가 DevOps가 무엇인지 이해하고 Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack 및 GIT와 같은 다양한 DevOps 프로세스 및 도구에 대한 전문 지식을 습득하여 SDLC의 여러 단계를 자동화하는 데 도움이됩니다.

질문이 있으십니까? 이 '일반적인 Git 실수'의 댓글 섹션에 언급 해 주시면 다시 연락 드리겠습니다.