git cherry-pick 사용 시기 및 방법 🍒

목차

Intro

But why?

Let's see how

Setup

Simulating the error

Cherry picking 🍒

Keep this in mind

소개

Without much ado, let's get right into it...

So, the official git docs은 cherry-pick를 다음과 같이 설명합니다.

Given one or more existing commits, apply the change each one introduces, recording a new commit for each.

그래서 그것이 정확히 무엇을 의미하는지 봅시다 ...

하지만 왜?

OK, picture this:

• You're working on a project and you're inside a local git repository.
• You have been working on an awesome feature on a separate branch.
• You just added some more code and committed.

But wait. You had to commit to the feature branch, but you committed to master 😱

What do you do in this case? Do you copy your code and paste it in the right branch and then commit again?

Now this is exactly why you need git cherry-pick . It allows you to "cherry-pick" commits from one branch and put them elsewhere (on another branch).

방법을 보자

Now that you have an understanding of why you might need it, let's see how you can use it with a small example.

설정

First, I'll cd to my Desktop and create a brand new folder called "learning" with this command:

cd Desktop && mkdir learning

Now let's cd into our new directory:

cd learning

Now let's initialize a new git repository in this new folder with the command git init :


좋습니다. git 저장소가 준비되었습니다. 이제 새 파일을 만들고 변경 사항을 커밋하겠습니다...


이제 새 분기를 만들고 거기에 커밋 하나를 추가해 보겠습니다.


자, 이제 git 로그를 빠르게 확인하여 현재 커밋을 확인하겠습니다. 각 분기에 대해 다음 명령을 사용합니다.

git log --oneline --graph

ℹ️ : -oneline will give us all info for each commit in a single line and --graph will make it look nice in a tree like format.

마스터 브랜치에 대한 로그

some-awesome-feature 브랜치에 대한 로그

이제 오류를 시뮬레이션해 봅시다 😋

오류 시뮬레이션

Now to simulate the error, we will make a commit to the master branch that should have been made to the some-awesome-feature branch.

Let's do that:


잘 했어! 🥳
이제 체리 따기 🍒

체리 따기🍒

First, checking the wrong branch (the master branch in this case), we see the commit that we want to pick and copy to the right branch.

마스터 브랜치에 대한 로그

some-awesome-feature 브랜치에 대한 로그

이제 먼저 master에서 올바른 분기로 커밋을 복사하려면 해당 커밋의 커밋 해시가 필요합니다.

잘못된 분기(우리의 경우 master 분기)를 주의 깊게 살펴보면 커밋 해시는 67d2e2f입니다.

이는 복사해야 하는 커밋을 cherry-pick에 알려야 하기 때문에 중요합니다.

이제 선별하기 위해 우리는 항상 오른쪽 분기git checkout를 먼저 선택합니다. 다음과 같이 해보자:

git checkout some-awesome-feature

이 분기에 대한 빠른git log:


여기서 원하는 커밋이 거기에 없다는 것을 알 수 있습니다.

기다리던 명령인 cherry-pick의 마법 ✨을 사용합시다!

커밋을 원하는 분기에서 다음을 실행합니다.

git cherry-pick <commit_hash_of_the_commit_you_want_here>

As you saw earlier, the hash of the commit we want is 67d2e2f so we'll use that.

팔! 💥. 끝났어! 점검 해보자?

이 분기에 대한 git 로그를 다시 확인하겠습니다.


우와 🎊

그러나 커밋에는 다른 해시가 있습니다. 😯. 그것이 우리가 이 포스트의 마지막 부분에서 논의할 것입니다...

이것을 명심하십시오

For the final time, let's check the commit logs for both the branches

마스터 브랜치에 대한 로그

some-awesome-feature 브랜치에 대한 로그

1.

=======
우리가 선별한 커밋이 잘못된 브랜치(우리의 경우 master 브랜치)에서 이동되지 않았지만 복사된 것을 볼 수 있습니다.

이것이 바로 "리플레이"입니다. Git은 커밋을 이동하지 않고 대신 올바른 브랜치에서 변경 사항을 재생합니다. 이것이 바로 커밋이 원래 해시와 다른 해시를 갖는 이유입니다.

원래 커밋은 항상 있던 위치에 유지되며 거기에서 커밋을 삭제하는 것은 사용자의 책임입니다(git reset와 같은 사용).

2.

=======
복사된 커밋의 해시가 원본과 어떻게 다른지 보았고, 변경 사항을 이미 원격 저장소(예: GitHub)에 푸시한 경우 이러한 명령을 사용하지 않아야 합니다. 프로젝트의 공동 작업자는 귀하의 역사와 다른 역사를 갖게 될 것이며 이로 인해 많은 일이 엉망이 될 수 있습니다.


Aaaand 그것이 나에게서 온 것입니다! 끝까지 읽어주셔서 정말 감사합니다. 당신은 굉장합니다! 🥳

당신이 그것을 사랑한다면, 당신은 약간의 사랑을 보여주고/또는 아래에 당신의 아름다운 댓글을 남길 수 있습니다.

수정 및 제안을 환영합니다.