당신의 Git 게임을 정리하고, 당신의 역사를 정리합니다.

This post is aimed for people who want to learn how to use commands such as rebase & learn a few tricks to have a nicer Git experience.

자, 제가 Github에서 첫 번째 프로젝트에 참여한 Git의 역사를 살펴보겠습니다.

Oh no

Oh no no no no

OH LORD WHAT HAVE I DONE

지금 나는 이미 자신을 비웃었다. 우리들에게 나의 대다수 프로젝트가 현재 어떤 모습인지 보여 주자😄

Oof, much better

이 모든 것이 무엇을 의미하는지 모르면 간단하게 설명해 드리겠습니다.
이것은 Github에 있는 Git 역사 기록의 일종으로 시간의 추이에 따라 프로젝트 지점에서 제출한 것을 의미합니다.

You can see your own by navigating to the "Insights" tab of one of your projects, then going to the "Network" tab on the left.

검은색 줄은 나의 master 지점을 대표하고, 교체된 파란색과 녹색 줄은 모두 독립된 지점이다.
최근 더 좋은 역사에서 보듯이, 그것들은 마스터에 번갈아 합쳐져서, 코드 흐름을 잘 작성하고, 합쳐진다. (이것은 항상 pull 요청을 누적하는 것이 아니라 추천된다.)
그럼, 당신은 어떻게 더 깨끗한 역사를 가지고 있습니까?진정한 용례를 봅시다.
다음은 각 섹션이 순서대로 완료되었는지 확인하는 내용입니다.

Rebasing

Fixing up a commit

Dropping a commit

Renaming a commit

Rebasing on master

Getting a better git log

마술사git rebaseOfficial documentation
Git rebase는 당신의 뜻에 따라 역사를 재구성할 수 있습니다.주어진 지점의 제출 목록을 조작하는 방법으로 간주합니다.
예를 들어 제출을 완전히 삭제하고 (기본적으로git의 심연에서 안녕이라고 말하고) 이름을 바꾸고 (제출 메시지를 다시 쓰기) 다른 제출로 압축할 수 있습니다.

실천 속에서 배우다
제가 이 자리를 위해 제작한 다음 내용project으로 넘어가 포크로 포크를 찍어 보도록 하겠습니다.
가닥은 기본적으로 자신을 위해 나의 프로젝트 던전을 만드는 것입니다. 당신은 아무 문제 없이 그것을 처리할 수 있습니다.이렇게 하려면 오른쪽 위 모서리의 가름 버튼을 클릭합니다.

그리고 갈라진 저장소를 복제합니다.

예시 1:rebase 복구를 사용하여 제출
장면: 제출할 가치가 없는 내용을 제출했거나 요청을 하기 전에 지점의 제출 횟수를 한 번으로 줄이기를 원합니다.

분기에서 새 분기를 만듭니다.

새 파일을 만듭니다. 그 내용은 사실 중요하지 않습니다.

새로운 서류를 지점에 제출한다.

git add index.js
git commit -m "add index.js"

파일의 일부 업데이트

"update index.js"

등의 메시지를 사용하여 다시 제출

실행master, 보시다시피 두 개의 제출

이 있습니다.
우리는 현재 git log fixup를 update 제출에 제출하려고 합니다. 왜냐하면 이 작은 변경 사항 자체는 제출할 가치가 없기 때문입니다.
이를 위해 우리는 add의 상호작용 모드를 사용할 것이다. 이로써 우리는 아름다운 인터페이스로 주소를 재정비할 수 있다.

rebase 명령을 다음과 같이 실행합니다.

git rebase -i HEAD~2

git rebase는 분지(머리)의 마지막 제출부터 시작해서 두 번 제출한다는 뜻이다.더 많은 제출을 조작하려면, 값을 맨 오른쪽으로 변경할 수 있습니다.
이제 다음과 같은 인터페이스가 있어야 합니다.

당황하지 마십시오. 이것은 맨 위에서 변경한 두 개의 제출과 아래에 사용할 수 있는 명령만 보여 줍니다.
기본적으로rebase 인터페이스는 Vim을 사용합니다. 쓰기 위해서는 i키를 누르기만 하면 됩니다.현재 삽입 모드입니다.첫 번째 제출에서 두 번째 제출을 복원하고 싶기 때문에, 우리가 해야 할 일은 그 앞에 HEAD~2 또는 fixup 을 쓰는 것이지, f 을 쓰는 것이 아니다.우리의 pick 제출은 현재 update index.js로 압축되지만 add index.js 메시지만 보류됩니다.

두 번째 행을 다음과 같이 업데이트합니다.

pick c0091ec add index.js
f a19336e update index.js

현재, 우리는 다시 주소를 적용하고, escape를 누르면 삽입 모드를 종료하고, (사칭) 을 누르고, wq를 입력하면 '쓰기' 와 '종료' 를 표시하고,enter를 누르면 변경 사항을 적용합니다.콜론은 Vim에 대해 실행할 명령만 작성할 수 있습니다.
이제 콘솔에 다음 메시지가 표시되어야 합니다.

Successfully rebased and updated refs/heads/{YOUR BRANCH NAME}.

당신의 add index.js를 검사하고, 당신은 지금 예쁘고 깨끗한 약속을 가지고 있습니다!

마지막으로 리디렉션을 원격 서버에 적용하기 위해 이 지점으로 강제 전송

git push origin {BRANCH-NAME} -f

git log빠질 수 없는 것은git역사를 다시 수정했기 때문에 강제 집행이 필요하다.

예 2: 커밋 삭제
다음 두 단계는 첫 번째 단계와 매우 비슷합니다. 왜냐하면 현재 어떤 종류의 재정립을 진행할 도구가 있기 때문입니다🎉
장면:제출을 완전히 삭제하려면
우리는 이전에 한 -f 약속을 포기할 것이다.

rebase 명령 실행

git rebase -i HEAD~1

삭제할 제출 전에 add FILENAME 또는 d를 추가합니다.

Vim 편집기에서 실행drop:wq (제출이 삭제되었는지 확인)

원격 서버로 강제 전송😀

예 3: 다시 쓰기 커밋
아주 비슷해요. 단 하나의 변화밖에 없어요.
장면: 타자 오류를 수정하거나 제출한 제목이나 설명을 다시 쓰고 싶습니다.

랜덤 커밋 만들기

rebase 명령 실행

git rebase -i HEAD~1

덮어쓸 커밋 전에 git log 또는 r(현재 제목 편집 필요 없음)를 추가합니다.

Vim 편집기에서 실행reword.다시 쓸 제출을 포함하는 유사한 편집기를 열 것입니다.

제출한 제목과 설명을 유언장으로 업데이트하고 :wq 실행합니다!재인코딩이 적용되었는지 확인

원격 서버로 강제 전송😀

예 4: 의 기본 주소 재설정:wq

This example isn't reproduced in the Github project, but feel free to test it out.

장면:여러 PRs를 동시에 엽니다(잡아당기기 요청).

너는 PR을 하나 합쳤어. 지금 너의 두 번째 PR은 최신이 아니야git log!

이런 흔한 시나리오에서는 첫 번째 PR에서 새 코드를 병합할 수 있도록 두 번째 PR의 기초를 master에 재설정합니다.

베이스를 재설정할 브랜치(두 번째 PR 브랜치)에서 다음 작업을 실행합니다.

git fetch

이것은 저희 지점에서rebase를 응용하는 데 필요한 모든 참고 자료를 다운로드할 것입니다.

그런 다음 베이스를 다음과 같이 수행합니다.

git rebase origin/master

마지막으로 master 프로그램을 실행하여rebase를 원격 서버에 적용

Hurray !

보상:더 좋음master너git push origin {MY-BRANCH} -f 너무 대처하기 어려운 거 아니야?

단도직입적이고 더 보기 좋은 git log를 원하십니까?

그만 봐!다음과 같은 방법으로 콘솔에 다음을 붙여 넣습니다.

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

현재 git log 에 git log 라는 별명을 만들었습니다. 이 별명은 이전에 보여준 더 좋은 출력을 보여 줍니다.변경된 행을 보려면 git log(또는 git lg를 입력합니다.

Thanks to Coderwall for this bonus ✨

강박의 위험성 및 기타 주의해야 할 사항을 논하다
닉 반카(Nick Huanca)는 팀과 협력할 때 힘껏 밀면 위험할 수 있다고 말했다.

Nick Huanca
•
글 고마워요!이것은 아주 좋은 독서/복습이다.시청자가git게임을 업그레이드하고 싶은 사람이기 때문에 저는'강제 전송'의 위험에 대한 정보를 추가할 것을 권장합니다. 참고force push with care도 있을 수 있습니다. 이것은 git lg를 이용했습니다. 그러면 사람들이 의외로 팀을 덮어씌우지 않을 것입니다.
또 하나 주의해야 할 것은 git lg -p 중기 과정에서 의외의 상황(충돌 또는 기타 이상/의외의 행위)이 발생할 경우이다.특히 시작할 때 어떻게 안전하게 명령을 물러날지 알게 되어 기쁘다.
다시 한 번 감사합니다!
따라서 다른 선택은 --force-with-lease일 수 있다. "한 사람이 다른 사람의 작업을 무의식중에 덮어쓰지 않고 강제로 밀어붙일 수 있다. 원격 인용이 로컬 원격 추적 지점과 같은 값을 가지고 있을 때만 원격 인용을 업데이트할 수 있다."Reference . 팁 고마워, 닉!😄
보시다시피, 그는 git rebase --abort 어떤 문제가 발생하지 않도록 중도에서 재조정을 중지할 수 있도록 허락했다.따라서 만약 어떤 이유로든 당신의 재기지를 망치면git는 조금--force-with-lease 다시 시작합니다.

결어
Git를 어떻게 사용하는지 배우는 것은 아마도 우리가 개발자로서 얻을 수 있는 가장 중요한 기술 중의 하나일 것이다.나는 너희들 중 일부가 내가 아까처럼 그렇게 두려워하지 않기를 바란다. git rebase --abort만약 이 문장이 당신에게 도움이 된다면, 수시로 평론을 발표하세요❤️🦄🔖 트위터에 팔로우!