git merge, git rebase, git Reset, git revert, git fetch, git pull, git reflog... 이 git 명령이 어떤 작업을 수행하는지 아시나요? 아직도 혼란스럽다면 이 글을 놓치지 마세요. 이 글에서는 JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker, Golang에 익숙한 21세 소프트웨어 컨설턴트인 Lydia Hallie가 이러한 일반적으로 사용되는 git 명령의 작업 과정을 애니메이션 형식으로 직관적으로 소개합니다. 당신이 그들을 결코 잊지 않도록 보장합니다.
Git은 매우 강력한 도구이지만 Git이 사용하기에는 악몽이라고 말하면 대부분의 사람들은 내 말에 동의할 것입니다. Git으로 작업할 때 머리 속에 시각화하는 것이 매우 유용하다고 생각합니다. 특정 명령을 실행할 때 이러한 분기가 어떻게 상호 작용하고 기록에 어떤 영향을 미칠까요? 마스터에서 하드 재부팅을 수행하고 원래 브랜치로 강제 푸시하고 .git 폴더를 rimraf할 때 동료가 울부짖는 이유는 무엇입니까? 가장 일반적으로 사용되고 유용한 Git 명령의 시각적 예를 만드는 것이 완벽한 사용 사례라고 생각했습니다! 아래에서 설명할 많은 명령에는 선택적 매개변수가 있습니다. 이러한 매개변수를 사용하여 해당 명령의 동작을 변경할 수 있습니다. 그리고 내 예에서는 명령의 기본 동작만 다루며 선택적 구성을 추가하거나 너무 많이 추가하지 않습니다! 다양한 새 변경 사항을 서로 격리하고 실수로 프로덕션 코드에 의도하지 않은 변경 사항을 푸시하지 않도록 여러 분기를 갖는 것이 편리합니다. . 하지만 이러한 변경 사항이 승인되면 이를 프로덕션 지점에 배포해야 합니다! 한 브랜치의 변경 사항을 다른 브랜치에 통합하는 한 가지 방법은 git merge를 수행하는 것입니다. Git은 빨리 감기와 빨리 감기 안 함이라는 두 가지 유형의 병합을 수행할 수 있습니다. 지금은 차이점을 구분하지 못할 수도 있지만 잠시 후에 차이점을 살펴보겠습니다. Fast-forward 병합은 병합하려는 브랜치에 비해 현재 브랜치에 추가 커밋이 없을 때 수행될 수 있습니다. Git은 게으르고 가장 간단한 옵션인 빨리 감기를 먼저 시도합니다! 이 유형의 병합은 새 커밋을 생성하지 않지만 대신 현재 브랜치에 직접 병합하려는 브랜치의 커밋을 병합합니다. 완벽해요! 이제 dev 브랜치에서 변경한 모든 내용이 마스터 브랜치에 병합되었습니다. 그렇다면 빨리 감기가 없다는 것은 무엇을 의미합니까? 현재 브랜치에 병합하려는 브랜치에 비해 커밋이 없다면 괜찮지만 매우 슬프게도 현실은 이런 경우가 거의 없습니다! 병합하려는 브랜치에 없는 현재 브랜치에 변경 사항을 커밋하면 git은 no-fast-forward 병합을 수행합니다. no-fast-forward를 사용하여 병합할 때 Git은 현재 활성 브랜치에 새로운 병합 커밋을 생성합니다. 이 커밋의 상위 커밋은 이 활성 브랜치를 가리키며 또한 병합하려는 브랜치를 가리킵니다! 별거 아닙니다. 완벽하게 병합됩니다! 이제 dev 브랜치에서 변경한 모든 내용이 마스터 브랜치에 병합되었습니다. Git은 브랜치를 병합하는 방법과 파일에 변경 사항을 추가하는 방법을 결정하는 데 꽤 능숙하지만, 항상 그 결정을 전적으로 자체적으로 내리는 것은 아닙니다. 병합하려는 두 브랜치가 동일한 파일의 동일한 코드 줄에서 서로 다른 수정 사항을 가지거나 한 브랜치가 파일을 삭제하고 다른 브랜치가 파일을 수정하는 경우 Git은 무엇을 선택해야 할지 모릅니다. 이 경우 Git은 어떤 옵션을 유지할 것인지 묻습니다. 두 가지 모두에서 README.md의 첫 번째 줄을 편집한다고 가정합니다. 개발자를 마스터로 병합하려는 경우 병합 충돌이 발생합니다. 제목을 Hello!로 하시겠습니까?
이 브랜치를 병합하려고 하면 Git은 충돌이 발생한 위치를 보여줍니다. 유지하지 않으려는 변경 사항을 수동으로 제거하고, 변경 사항을 저장하고, 수정된 파일을 다시 추가하고, 변경 사항을 커밋할 수 있습니다. 완료! 병합 충돌은 종종 성가시지만 의미가 있습니다. Git은 우리가 유지하려는 변경 사항을 추측할 필요가 없습니다.
우리는 git merge를 실행하여 한 브랜치에서 다른 브랜치로 변경 사항을 적용할 수 있다는 것을 보았습니다. 한 브랜치의 변경 사항을 다른 브랜치에 통합하는 또 다른 방법은 git rebase를 수행하는 것입니다. git rebase는 현재 브랜치의 커밋을 지정된 브랜치에 복사합니다. 완벽합니다. 이제 dev 브랜치의 마스터 브랜치에 모든 변경 사항이 적용되었습니다. 리베이스와 병합에는 한 가지 주요 차이점이 있습니다. Git은 어떤 파일을 유지할지 여부를 결정하지 않습니다. 우리가 리베이스하는 브랜치에는 항상 우리가 유지하고 싶은 가장 최근의 변경 사항이 포함되어 있습니다! 이렇게 하면 병합 충돌이 발생하지 않고 훌륭하고 선형적인 Git 기록이 유지됩니다. 위의 예는 마스터 브랜치에 대한 리베이스를 보여줍니다. 그러나 대규모 프로젝트에서는 일반적으로 이 작업을 수행할 필요가 없습니다. git rebase는 복사된 커밋에 대한 새 해시를 생성할 때 프로젝트 기록을 수정합니다. 기능 브랜치를 개발 중이고 마스터 브랜치가 업데이트된 경우 리베이스가 매우 유용합니다. 브랜치에서 모든 업데이트를 얻을 수 있으므로 향후 병합 충돌을 방지할 수 있습니다. 커밋에 대한 리베이스를 수행하기 전에 커밋을 수정할 수 있습니다! 이 작업을 수행하기 위해 대화형 리베이스를 사용할 수 있습니다. 대화형 리베이스는 현재 개발 중인 브랜치에서 특정 커밋을 수정하려는 경우에 유용합니다.
리베이스하는 커밋에서 다음 6가지 작업을 수행할 수 있습니다.
대단해요! 이런 방식으로 우리는 커밋을 완전히 제어할 수 있습니다. 커밋을 제거하려면 삭제하면 됩니다.
여러 커밋을 병합하여 명확한 커밋 기록을 얻으려는 경우에도 문제 없습니다!
대화형 리베이스를 사용하면 리베이스할 때 현재 활성 브랜치에 대해서도 많은 제어가 가능합니다.
이 명령은 이전에 제출한 변경 사항을 원하지 않을 때 사용됩니다. 이는 WIP 커밋일 수도 있고 버그를 유발한 커밋일 수도 있습니다. 이 경우 git 재설정을 수행해야 합니다.
git 재설정을 사용하면 현재 데스크탑의 파일을 더 이상 사용할 수 없으며 HEAD가 가리켜야 하는 위치를 제어할 수 있습니다.
소프트 재설정
소프트 재설정은 해당 커밋 이후에 추가된 변경 사항을 제거하지 않고 HEAD를 지정된 커밋(또는 HEAD와 비교한 커밋의 인덱스)으로 이동합니다!
style.css 파일을 추가하는 커밋 9e78i를 유지하고 싶지 않고 index.js 파일을 추가하는 커밋 035cc도 유지하고 싶지 않다고 가정해 보겠습니다. 하지만 새로 추가된 style.css 및 index.js 파일은 유지하고 싶습니다! 이는 소프트 리셋을 위한 완벽한 사용 사례입니다.
git status를 입력한 후에도 이전 커밋의 모든 변경 사항에 여전히 액세스할 수 있음을 알 수 있습니다. 좋습니다. 이는 해당 파일의 내용을 수정하고 나중에 다시 제출할 수 있다는 의미입니다!
하드 리셋
때로는 특정 커밋에 의해 도입된 변경 사항을 유지하고 싶지 않을 때가 있습니다. 소프트 리셋과 달리 다시 액세스할 필요가 없습니다. Git은 전체 상태를 특정 커밋 전 상태로 직접 재설정해야 합니다. 여기에는 작업 디렉터리와 준비된 파일에서 변경한 내용도 포함됩니다.
Git은 9e78i 및 035cc에서 도입된 변경 사항을 폐기하고 상태를 ec5be 상태로 재설정했습니다.
변경 사항을 실행 취소하는 또 다른 방법은 git revert를 수행하는 것입니다. 특정 커밋에 대해 되돌리기 작업을 수행하여 되돌린 변경 사항이 포함된 새 커밋을 생성합니다.
ec5be가 index.js 파일을 추가한다고 가정해 보겠습니다. 그러나 우리는 이 커밋으로 인해 도입된 변경 사항이 더 이상 필요하지 않다는 것을 발견했습니다. 그런 다음 ec5be 제출을 복원하십시오!
완벽해요! 커밋 9e78i는 커밋 ec5be에 의해 도입된 변경 사항을 되돌립니다. git revert는 브랜치 기록을 수정하지 않고 특정 커밋을 실행 취소할 때 유용합니다. 특정 브랜치에 활성 브랜치에 필요한 커밋이 포함되어 있으면 해당 커밋에 대해 체리 선택을 수행합니다! 커밋을 선별할 때 선택된 커밋에 의해 도입된 변경 사항을 포함하는 활성 분기에 새 커밋을 생성합니다. dev 브랜치에서 커밋 76d12가 index.js 파일에 변경 사항을 추가하고 이를 마스터 브랜치에 통합하고 싶다고 가정해 보겠습니다. 우리는 전체 dev 브랜치를 원하지 않고 단지 이 커밋만을 원합니다! 이제 마스터 브랜치에는 76d12에서 도입된 변경 사항이 포함되어 있습니다.
GitHub의 브랜치와 같은 원격 Git 브랜치가 있는 경우 현재 브랜치에 없는 커밋이 원격 브랜치에 포함되어 있으면 검색을 사용할 수 있습니다. 다른 브랜치가 병합되거나 동료가 빠른 수정을 추진할 때와 같습니다.
이 원격 브랜치에서 git fetch를 실행하면 로컬에서 이러한 변경 사항을 가져올 수 있습니다. 이는 어떤 방식으로든 로컬 브랜치에 영향을 주지 않습니다. fetch는 단순히 새 데이터를 다운로드합니다.
이제 마지막 푸시 이후의 모든 수정 사항을 볼 수 있습니다. 이제 새 데이터는 로컬에 있으므로 이를 어떻게 처리할지 결정할 수 있습니다.
git fetch를 사용하여 지점의 원격 정보를 가져올 수 있지만 git pull을 수행할 수도 있습니다. git pull은 실제로 두 개의 명령이 하나로 결합된 것입니다: git fetch 및 git merge. 소스에서 변경 사항을 가져올 때 먼저 git fetch와 같은 모든 데이터를 검색한 다음 최신 변경 사항이 자동으로 로컬 브랜치에 병합됩니다.
좋습니다. 이제 원격 지점과 완벽하게 동기화되었으며 최신 수정 사항도 모두 적용되었습니다!
누구나 실수는 하지만, 실수해도 괜찮아요! 때로는 git 저장소가 완전히 손상되어 완전히 삭제하고 싶은 느낌이 들 수도 있습니다.
git reflog는 수행된 모든 작업의 로그를 표시할 수 있는 매우 유용한 명령입니다. 여기에는 병합, 재설정, 되돌리기, 기본적으로 브랜치에 대한 모든 변경 사항이 포함됩니다.
실수한 경우 reflog에서 제공하는 정보를 기반으로 HEAD를 재설정하면 쉽게 다시 실행할 수 있습니다!
원본 브랜치를 실제로 병합할 필요가 없다고 가정해 보겠습니다. git reflog 명령을 실행하면 병합 전 이 저장소의 상태가 HEAD@{1}에 있었던 것을 확인할 수 있습니다. 그런 다음 git 재설정을 수행하고 HEAD를 HEAD@{1} 위치로 리디렉션합니다.
최신 작업이 reflog로 푸시된 것을 확인할 수 있습니다. 위 내용은 Git의 작동 방식을 알려주는 수십 개의 애니메이션 그림의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
