이 글은 처음에 발표되었다 medium.freecodecamp.org
나는 잘못을 하나 저질렀는데, 나는 어떻게 고쳐야 합니까?
나의 범죄 기록이 엉망진창인데, 어떻게 그것을 정리해야 합니까?
만약 네가 일찍이 상술한 문제가 있었다면, 이 게시물은 너를 위해 준비한 것이다.
만약 당신이 Git 기초 지식을 모른다면, click here Git 기초 지식에 관한 저의 블로그를 보십시오.본문을 충분히 활용하기 위해서는 Git의 기초 지식을 알아야 합니다.
우선, 이 글은gitamend를 해석한 다음에gitrebase를 해석할 것이다😃

나는 잘못을 하나 저질렀다.나 어떡하지?

chuttersnap 위의 Unsplash "바닥 위의 도자기판"

장면 1

만약 당신이 이미 한 무더기의 파일을 제출했고 입력한 제출 메시지가 실제로는 분명하지 않다는 것을 깨달았다면.제출 메시지를 변경하려고 합니다.이를 위해 사용할 수 있습니다git commit --amend

git commit --amend -m "New commit message"

장면 2

여섯 개의 파일을 제출하려고 했지만 오류로 인해 결국 다섯 개의 파일만 제출했다고 가정하십시오.새 커밋을 만들고 여섯 번째 파일을 커밋에 추가할 수 있다고 생각할 수 있습니다.
이런 방법은 틀림없다.단, 깔끔한 제출 기록을 유지하기 위해서, 만약 당신이 정말로 어떤 방식으로 이 파일을 이전의 제출 자체에 추가할 수 있다면 더욱 좋지 않겠습니까?이것 또한 git commit --amend를 통해 완성할 수 있다.

git add file6
git commit --amend --no-edit

--no-edit 제출 메시지가 변경되지 않음을 나타냅니다.

장면

Git에서 제출할 때마다 제출에는 작성자 이름과 작성자 이메일이 첨부됩니다.일반적으로 Git를 처음 설정할 때 작성자 이름과 전자 메일을 설정해야 합니다.제출할 때마다 작성자의 상세한 정보를 걱정할 필요가 없습니다.
즉, 특정 항목에 대해 다른 전자 메일 ID를 사용할 수 있습니다. 다음 명령을 사용하여 항목의 전자 메일 ID를 구성해야 합니다.

git config user.email "your email id"

전자 메일 설정을 잊어버리고 첫 번째 제출을 마쳤다고 가정하십시오.Amend 마지막으로 제출한 작성자를 변경할 수도 있습니다.다음 명령을 사용하여 커밋된 작성자를 변경할 수 있습니다.

git commit --amend --author "Author Name <Author Email>"

주석 가리키기

로컬 저장소에서만 amend 명령을 사용합니다.원격 저장소에 amend 를 사용하는 것은 많은 혼란을 초래할 수 있습니다.

나의 범죄 기록은 엉망진창이다.어떻게 처리해야 합니까?

코드를 작성하고 있다고 가정하십시오.코드는 대략 10일이 걸려야 완성할 수 있다는 것을 알고 있습니다.10일 내에 다른 개발자들도 코드를 원격 저장소에 제출할 것이다.
로컬 저장소 코드와 원격 저장소의 코드를 최신 상태로 유지하는 것은 좋은 방법이다.이것은 나중에 요청을 할 때 대량의 합병 충돌을 피할 수 있다.따라서 원격 저장소에서 이틀에 한 번씩 변경 사항을 추출하기로 결정했습니다.
원격 저장소에서 로컬 저장소로 코드를 끌어올릴 때마다 로컬 저장소에 새로운 통합 커밋이 생성됩니다.이것은 로컬 제출 기록에 많은 합병 제출이 있을 것이라는 것을 의미하며, 이것은 검토자를 곤혹스럽게 할 수 있습니다.

다음은 제출 기록이 로컬 저장소에 있는 모양입니다.

어떻게 하면 제출 역사를 더욱 깔끔하게 볼 수 있습니까?

이것이 바로 리베이스의 생명을 구하는 길이다.

재정기란 무엇입니까?

나는 하나의 예를 통해 이 점을 설명하겠다.

이 그림은 발표 지점과 기능 지점의 제출을 보여 준다

발표 지점에는 Rcommit1, Rcommit2, Rcommit3 세 가지 제출이 있습니다.

게시 지점에 커밋이 하나만 있을 때 게시 지점에서 기능 지점을 만듭니다.

기능 지점에 두 개의 커밋을 추가했습니다.그것들은 Fcommit1과 Fcommit2이다.

게시 지점에서 특성 지점으로 제출을 옮기는 것이 목표입니다.

이 동작을 실행하려면rebase를 사용하십시오.

방출 브랜치의 이름은 Release이고 피쳐 브랜치의 이름은 Feature입니다.

재지정 기준은 다음 명령을 사용할 수 있습니다.

git checkout feature
git rebase release

재정비

기본 주소를 다시 정할 때, 기능 지점이 발표 지점에서 최신 코드를 얻을 수 있도록 하는 것이 목표입니다.
재배치 각 제출을 하나씩 추가하고 충돌을 검사합니다.이것은 듣기에 사람을 곤혹스럽게 합니까?
도표로 설명해 드릴게요.
이것은 내부의 실제 작용을 재조정하는 것을 나타낸다.

1단계

명령을 실행할 때 특징 지점은 지점을 방출하는 머리를 가리킨다.

현재 기능 지점은 세 가지 제출이 있습니다. 그것이 바로 Rcommit1, Rcommit2, Rcommit3입니다.

Fcommit1과 Fcommit2에 무슨 일이 일어났는지 알고 싶을 수도 있습니다.

제출은 다음 단계에서 사용됩니다.

2단계

이제 Git은 Fcommit1을 기능 분기에 추가합니다.

충돌이 없으면 Rcommit3

이후에 Fcommit1을 추가합니다.

충돌이 있을 경우 Git은 충돌을 수동으로 해결해야 한다고 알려 줍니다.충돌이 해결된 후 다음 명령을 사용하여 계속 재정의하십시오

git add fixedfile
git rebase --continue

단계 3

Fcommit1을 추가하면 Git은 Fcommit2를 추가합니다.

마찬가지로 충돌이 없으면 Fcommit1 다음에 Fcommit2를 추가하고 초기화에 성공합니다.

충돌이 발생하면 Git에서 수동으로 해결해야 한다고 알려줍니다.충돌 해결

후 2단계에서 언급된 동일한 명령 사용

전체 중기를 완성하면 특징 지점에 Rcommit1, Rcommit2, Rcommit3, Fcommit1, Fcommit2가 있음을 알 수 있습니다.

주의사항

Rebase와 Merge는 Git에서 모두 유용합니다.하나는 다른 것보다 결코 좋지 않다.

합병 시 합병 제출이 있습니다.중기적인 상황에서 합병 제출과 같은 추가 제출은 없다.

가장 좋은 방법은 서로 다른 점에서 명령을 사용하는 것이다.원격 저장소의 최신 코드를 사용하여 로컬 코드 저장소를 업데이트할 때rebase를 사용하십시오.드래그 요청을 처리할 때merge를 사용하여 기능 지점을 발표나 주 지점과 통합합니다.

Rebase를 사용하여 제출 내역을 변경합니다.하지만 그렇다고 제출 역사를 바꾸는 것도 위험하다.따라서 원격 저장소의 코드에 rebase를 사용하지 않도록 하십시오.로컬 리셋 코드의 제출 기록을 항상 Rebase로만 변경합니다.

원격 저장소를 재설정하면 다른 개발자들이 새로운 역사를 식별할 수 없기 때문에 많은 혼란을 초래할 수 있다.

또한 원격 저장소에서 기초를 재정비하면 다른 개발자가 원격 저장소에서 최신 코드를 추출하려고 할 때 문제가 발생할 수 있습니다.그래서 다시 한 번 말씀드리지만 로컬 저장소에만 rebase를 사용합니다.😃

축하한다😃

본 게시물에서 다음을 알 수 있습니다.

개정 약속

재기준

이 두 개념은 모두 매우 유용하다.Git 세계를 탐험하며 공부하기
심지어 더 많다.

언제든지 저에게 연락하거나 따라주세요.

만약 네가 이 게시물을 좋아한다면, 너는 나의 사이트를 볼 수 있다https://adityasridhar.com기타 유사 직위