Magic is everywhere! Specially in your terminal, and our git has some of its own. In this post I'm going to show you a little of this magic that lives inside the git rebase command.
🐻 Bear in mind, this post assumes you are already familiar with git.

git 재기

📖 Reapply commits on top of another base tip.

이것은 듣기와 보기에 마치git merge...정당하다

git checkout feature
git rebase master

완전히 그렇지는 않다.git rebase, 지점을 이동하고 모든 새로운 제출을 통합하지만, 원본 지점의 모든 제출에 새로운 제출을 만들어서 프로젝트 역사를 다시 씁니다.
이런 새로운 약속들은 공공부문에서 기수를 재설정하지 말라는 황금법칙을 제시했다.
재작성 제출 외에도 다음과 같은 두 가지 주요 기능을 추가할 수 있습니다 git rebase.

새로운 제출을 하지 않음 (다시 썼기 때문)

처리 중인 동일한 지점에 사용 가능

이 세 가지 핵심 기능은 우리에게 제출을 조정할 기회를 제공했다.

저희가 제출 메시지를 어지럽혔습니다

매우 작은 파일 변경을 진행했으며, 제출은 비교적 큰 파일

에서 하는 것이 가장 좋다

제출 순서를 변경해야 할 때

전체 제출 삭제

우리 손을 더럽혔어.

만약 내가 이 새로운 기능 지점을 계속 개발하고 있다고 가정한다면, 4개의 제출에서, 나는rebase를 사용하여 그것들에 대해 약간의 변경을 하고 싶다.

git rebase -i HEAD~4

git-rebase: 물론,git-rebase 명령 호출

-i: 이것은 상호작용적인 줄임말로 우리가 데이텀을 다시 설정해야 하는 제출 목록을 보여 줍니다. 이 목록을 편집하고 데이텀을 어떻게 다시 설정해야 하는지를 보여 줍니다.이 서류는 우리가 오늘 할 마술이다.

머리 4: 턱화 문자는 특정한 제출 위치를 가리키는 데 사용되며 본 예에서 머리이다.우리에게 네 번째 부모님을 주셨다.

현재, 당신이 디자인한 IDE에git-rebase-todo라는 파일을 열었습니다.git 프로젝트를 사용하지 않을 준비가 되었습니다.

# git-rebase-todo
pick 4acdb1d First Commit of Feature
fixup be76710 Second Commit of Feature
drop 78acdd0 Third Commit of Feature
reword 9480b3d Fourth Commit of Feature

우리가 --interactive/-i 을 사용할 때, 이 파일은git가 열거한 모든 제출을 어떻게 처리하는지 알려 줍니다.목록을 다시 정렬할 수 있습니다.git는 위에서 아래로 주문을 실행합니다!

기본적으로 모든 제출에는 옵션pick이 있지만, 많은 옵션을 사용하여 제출을 변경할 수 있습니다.
이것이 무엇을 의미하는지, 그리고 우리가 Rebase로 제공하는 다른 명령으로 무엇을 할 수 있는지 봅시다.

선택

제출된 신호를 사용하려면 git를 선택하십시오. 이것은 이 제출을 보류하고 재정비된 기반에서 사용할 것을 의미합니다.
➡ 픽은 언제 사용해야 합니까?매번 우리는 약속을 유지하고 싶다!

pick be76710 Super awesome commit message
# You can also use the short version: p
p be76710 Super awesome commit message

고쳐쓰다

Reword는 git가 픽업처럼 제출을 사용하도록 지시하지만, 다시 제출할 때 제출 메시지를 변경합니다.편집할 파일과 편집할 이전 제출 메시지를 입력하라는 메시지가 표시됩니다.
➡ Reword는 언제 사용해야 합니까?매번 우리는 약속을 유지하고 싶지만, 우리는 그것을 변경해야 한다.

reword be76710 Super awesome commit message
# You can also use the short version: r
r be76710 Super awesome commit message

편집하다

편집 신호git는 제출을 사용하지만, 제출하기 전에 멈추고, 변경하거나 조정합니다.《수칙》의 이 수정은 전혀 제한을 받지 않는다.제출할 준비가 되어 있다면, 모든 내용은 제출에 포함될 것이다. 맞춤법 오류, 몇 줄 코드, 새로운 파일을 포함한다.
➡ 편집은 언제 사용해야 합니까?매번 우리는 약속을 유지하고 싶지만, 우리는 그것에 대해 더 많은 변경을 해야 한다.

edit be76710 Super awesome commit message
# You can also use the short version: e
e be76710 Super awesome commit message

호박.

압출 신호git는 이전 제출과 통합됩니다. 이것은 두 제출이 새로운 해시를 가진 제출이 된다는 것을 의미합니다.Git는 새로 만든 커밋된 커밋 메시지를 다시 쓸 수 있도록 하고 파일을 사용하여 편집하라는 메시지를 표시합니다.
➡ 호박은 언제 써야 합니까?매번 우리는 당신이 하나 이상의 제출을 이전과 합병하기를 희망합니다.

squash be76710 Super awesome commit message
# You can also use the short version: s
s sbe76710 Super awesome commit message

수정하다

Fixup은git에 신호를 보내서 제출을 이전 제출과 합치도록 합니다. 압축과 같지만 제출한 메시지를 버립니다.
➡ 픽업은 언제 사용해야 합니까?우리가 하나 이상의 제출을 이전과 합병하려고 할 때마다 그 메시지는 무시됩니다.

pick 4acdb1d Super Awesome Commit
fixup be76710 This commit is going to be merged with the one on top of it
pick 9480b3d Another Super Awesome Commit
# You can also use the short version: f
f be76710 Super awesome commit message

방울

Drop은git에 전송된 모든 신호를 삭제합니다.
➡ 픽업은 언제 사용해야 합니까?모든 변경 사항을 제출하는 것을 포기할 때마다

drop be76710 Super awesome commit message
# You can also use the short version: d
d be76710 Super awesome commit message

그렇다면 이 마술을 어떻게 사용해야 할까요?

너는 방금 너의 새 사이트 색인에 대해 매우 큰 변화를 했다.html.당신의 눈은 완성된 일에 놀라서 갑자기 싫은 맞춤법 오류가 어디에서 튀어나왔는지 모르겠다.
✨ 고정된 맞춤법 오류를 사용하여 다른 제출만 하면 됩니다.터미널git -i rebase HEAD~2에서 마술 글자를 상향 조정한 다음fixup을 사용하여 입력 오류에 대한 제출을 통합합니다.
세 번의 제출이 진행된 후에 첫 번째 제출 시 제출 메시지가 표시되어 팀의 다른 사람들이 곤혹스러울 수 있습니다.
✨ git rebase -i HEAD~3rebase의 위대함을 호출하고 메시지를 변경하려는 제출에reword를 사용하십시오.
너는 이미 네가 한 모든 약속을 알아차렸다. 다섯 가지 약속은 이전에 틀렸다. 그러나...리셋 사용을 잃고 싶지 않은 제출이 많아요!
✨ 이 모든 어리석은 실수를 감추기 위해 Rebase!우리 단말기git rebase -i HEAD~5에서 함께 외우자,drop을 사용하자,commit는 이미 영원히 사라졌다!

권력이 크고 책임이 크다

rebase를 사용하기 전에, 합병할 제출이 공공 지점에 통합되었는지 확인해야 합니다. 만약 그렇다면...우리로 하여금 기준을 다시 설정하게 하지 마라.저희가 새로운 제출을 위해 기초를 재설정하는 데 뭘 배웠는지 기억나세요?너는 문제가 있을 것이다. 왜냐하면 우리는 방금 제출 역사를 다시 썼기 때문이다.
기억해야 할 또 다른 것은 우리가 기초를 다시 설정할 때 모든 제출이 하나하나 적용된다는 것이다. 이것은 제출의 순서를 삭제하거나 변경하면 충돌이 발생할 수 있다는 것을 의미한다. 충돌을 복구한 다음에 기초를 다시 설정하기 전에 제출해야 한다.성공적으로 처리한 후 우아하게 사용git rebase --continue하여 기초를 재조정한다.아니면 아예 git rebase --abort따라 울면서 자고 그 충돌을 기억해라...오, 하느님...이러한 충돌.

📚 더 많이 읽읍시다!

참고로 이 글은 merge과rebase 사이의 차이를 깊이 토론하지 않았다는 것을 알지만, 좋은 소식이 있습니다🔗Atlassian has a great post about it.

지점에 미치는 영향을 시각화할 수 있는 더 좋은 방법이 필요하다면
있다

내가 여기서 소개한 옵션은 rebase가 가지고 있는 유일한 옵션이 아니다.만약 이 화제가 당신을 중독시켰다면, 당신은 당신의 지식을 확장하고 역사를 개작하기를 갈망합니다🔗 git documentation on has a lot of good insight.

좀 더 전문적이고 싶다면,
짧지만 달콤한 게시물에 과장이 있다.

이것이 바로 내가 지금 말한 것이다. 나는 네가 그것이 유용하다고 생각하기를 바란다. 너의 다음 항목에서, rebase의 마력 때문에, 이런 싫은 맞춤법 오류가 너의 제출 역사를 더욱 적게 괴롭히고 있다.✨