Git을 사용하여 가장 최근의 커밋을 새로운 브랜치로 옮깁니다.


4981

마지막으로 몇 가지 커밋을 새 지점으로 마스터하고 해당 커밋이 수행되기 전에 마스터로 다시 가져 가려고합니다. 불행히도 내 Git-fu는 아직 충분히 강하지 않습니다.

즉, 나는 이것을 어떻게 갈 수 있습니까

master A - B - C - D - E

이에?

newbranch     C - D - E
             /
master A - B 

114
참고 : 나는 여기서
Benjol

3
eddmann.com/posts/… 이것은 작동합니다
Sagar Naliyapara

6
여기에 의견이 정리 되었습니까? 격월로이 질문을 방문하는 동안 나는 항상 그 의견으로 스크롤하기 때문에 묻습니다.
Tejas Kale

답변:


6449

기존 지점으로 이동

커밋을 기존 브랜치 로 옮기려면 다음과 같이 보일 것입니다.

git checkout existingbranch
git merge master         # Bring the commits here
git checkout master
git reset --keep HEAD~3  # Move master back by 3 commits.
git checkout existingbranch

--keep유사 무슨 - 옵션은 해당 변경 내용을 덮어했을 경우 관련없는 파일되거나 중단에있을 수 있음을 커밋되지 않은 변경 보존 git checkout수행합니다. 중단 된 경우 git stash변경 사항을 다시 시도하거나 --hard커밋간에 변경되지 않은 파일에서도 변경 사항을 잃어 버릴 때 사용하십시오 !

새로운 지점으로 이동

이 방법은 첫 번째 명령 ( git branch newbranch) 으로 새 분기를 작성 하지만 전환하지는 않습니다. 그런 다음 현재 지점 (마스터)을 롤백하고 새 지점으로 전환하여 작업을 계속합니다.

git branch newbranch      # Create a new branch, containing all current commits
git reset --keep HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits
# Warning: after this it's not safe to do a rebase in newbranch without extra care.

그러나 얼마나 많은 커밋을 되돌릴 수 있는지 확인하십시오. 또는 대신에 되돌리려 HEAD~3는 커밋의 해시 (또는 같은 참조 origin/master)를 간단히 제공 할 수 있습니다 .

git reset --keep a1b2c3d4

경고 : Git 버전 2.0 이상에서는 나중에 git rebase새 분기 ( master) 분기에 새 분기가있는 --no-fork-point경우 마스터 분기에서 이동 한 커밋이 손실되지 않도록 리베이스 중에 명시적인 옵션 이 필요할 수 있습니다 . 데 branch.autosetuprebase always설정하면이 가능성이 있습니다. 자세한 내용은 John Mellor의 답변 을 참조하십시오.


249
특히, 마지막으로 다른 사람이 가져 왔을 수있는 다른 저장소에 커밋을 푸시 한 시점보다 더 멀리 돌아 가려고 하지 마십시오 .
Greg Hewgill

107
왜 이것이 효과가 있는지 설명 할 수 있는지 궁금합니다. 나에게 새 브랜치를 만들고, 기존 브랜치에서 3 개의 커밋을 제거한 다음 만든 브랜치를 확인하십시오. 그렇다면 제거한 커밋이 어떻게 새 브랜치에 마술처럼 나타 납니까?
Jonathan Dumaine

142
@Jonathan Dumaine : 이전 분기에서 커밋을 제거하기 전에 새 분기를 만들었 기 때문에. 그들은 여전히 ​​새로운 지점에 있습니다.
sykora

86
git의 브랜치는 히스토리에서 커밋을 가리키는 마커입니다. 마커를 제외하고 복제, 생성 또는 삭제되는 것은 없습니다
knittl

218
참고 : 작업 사본에서 커밋되지 않은 변경 사항 으로이 작업을 수행하지 마십시오! 이것은 단지 나를 물었다! :(
Adam Tuttle

1038

왜 그것이 효과가 있는지 궁금해하는 사람들을 위해 :

C로 돌아가서 D와 E를 새 분기로 이동하려고합니다. 처음에는 다음과 같습니다.

A-B-C-D-E (HEAD)
        ↑
      master

git branch newBranch:

    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

git reset --hard HEAD~2:

    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

브랜치는 단지 포인터이기 때문에 마스터 는 마지막 커밋을 가리 켰습니다. newBranch 를 만들었 을 때 마지막 커밋에 대한 새로운 포인터를 만들었습니다. 그런 다음 사용 git reset하여 마스터 포인터를 두 커밋으로 다시 이동했습니다 . 그러나 newBranch를 이동하지 않았 으므로 여전히 원래 커밋을 가리 킵니다.


56
또한 git push origin master --force메인 리포지토리에 변경 사항을 표시해야했습니다.
Dženan

9
이 답변은 커밋이 손실되도록합니다. 다음 번 git rebase에 3 개의 커밋이에서 자동으로 삭제됩니다 newbranch. 자세한 내용과 더 안전한 대안 은 내 답변 을 참조하십시오 .
John Mellor

14
@ 존, 그건 말도 안돼. 무엇을하고 있는지 알지 못하는 상태에서 재 확보하면 커밋이 손실됩니다. 커밋을 잃어버린 경우 미안하지만이 답변은 커밋을 잃지 않았습니다. 참고 origin/master위의 그림에 표시되지 않습니다. 당신이 밀고 origin/master나서 위의 내용을 변경하면, 일이 재미있을 것입니다. 하지만 그건 "의사, 내가 할 때 아프다"같은 문제입니다. 그리고 그것은 원래의 질문에 대한 범위를 벗어났습니다. 시나리오를 가로채는 대신 시나리오를 탐색하기 위해 자신의 질문을 작성하는 것이 좋습니다.
Ryan Lundy

1
@ 존, 당신의 대답에, 당신은 "하지 마십시오! git branch -t newbranch"라고 말했다. 돌아가서 답을 다시 읽으십시오. 아무도 그렇게 제안 하지 않았습니다.
Ryan Lundy

1
@Kyralessa, 물론, 질문의 다이어그램을 보면 newbranch기존 로컬 master지점을 기반으로 하고 싶다는 것이 분명합니다 . 수락 된 답변을 수행 한 후 사용자가에서 실행 git rebase을 시작 newbranch하면 git은 업스트림 분기를 설정하는 것을 잊었 음을 알려주므로 실행 git branch --set-upstream-to=master한 다음 git rebase동일한 문제가 발생합니다. 그들은 git branch -t newbranch처음부터 잘 사용할 수 있습니다 .
John Mellor

454

일반적으로 ...

이 경우 sykora에 의해 노출되는 방법이 가장 좋습니다. 그러나 때로는 가장 쉬운 방법이 아니며 일반적인 방법이 아닙니다. 일반적인 방법으로 git cherry-pick을 사용하십시오 .

OP가 원하는 것을 달성하기 위해 2 단계 프로세스는 다음과 같습니다.

1 단계-원하는 마스터에서 커밋하는 메모 newbranch

실행

git checkout master
git log

에 대한 커밋 (예 : 3) 커밋에 주목하십시오 newbranch. 여기서는 다음을 사용합니다.
C 커밋 : 9aa1233
D 커밋 : 453ac3d
E 커밋 :612ecb3

참고 : 처음 7 자 또는 전체 커밋 해시를 사용할 수 있습니다

2 단계- newbranch

git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

또는 (Git 1.7.2 이상에서 사용 범위)

git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

git cherry-pick 은 세 가지 커밋을 newbranch에 적용합니다.


13
OP 마스터 에서 새 브랜치 로 이동하지 않았습니까 ? 마스터에서 체리 픽을 선택하면 마스터 브랜치에 추가 될 것입니다. 실제로 커밋을 추가하면됩니다. 분기 헤드 B로 돌아 가지 않습니다. 아니면 내가 얻지 못하는 미묘하고 멋진 것이 있습니까?
RaveTheTadpole 2

6
새로운 기능 브랜치를 생성했을 때 실수로 마스터가 아닌 마스터 브랜치를 잘못 커밋 한 경우에 매우 효과적입니다.
julianc

5
일부 상황에서 유용한 접근 방식으로 +1 이것은 자신의 커밋 (다른 사람들과 산재되어있는)을 새로운 브랜치로 가져 오려는 경우에 좋습니다.
Tyler V.

7
더 나은 답변입니다. 이런 식으로 커밋을 모든 브랜치로 옮길 수 있습니다.
skywinder

8
체리 따기 순서가 중요합니까?
kon psych

328

단 두 개의 명령을 사용하여이를 수행하는 또 다른 방법입니다. 또한 현재 작업 트리를 그대로 유지하십시오.

git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

이전 버전 -배우기 전에git branch -f

git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit 

할 수있는 push것은 .알 수있는 좋은 트릭입니다.


1
현재 디렉토리. 나는 이것이 당신이 최상위 디렉토리에있는 경우에만 작동한다고 생각합니다.
aragaer

1
국부적으로 추진하는 것은 파문을 불러 일으키지 만 반성 할 때 git branch -f여기와 어떻게 다릅니 까?
jthill

2
@ GerardSexton .은 현재 이사입니다. git은 REMOTES 또는 GIT URL로 푸시 할 수 있습니다. path to local directoryGit URL 구문이 지원됩니다. 의 GIT URL 섹션을 참조하십시오 git help clone.
약화

31
왜 이것이 더 높은 등급을받지 않았는지 모르겠습니다. 작지만 잠재적으로 작지만 잠재적으로 git reset의 위험이 없습니다.
대장장이

4
@Godsmith 내 추측에 따르면 사람들은 세 가지 간단한 명령보다 두 개의 조금 더 모호한 명령을 선호합니다. 또한 가장 많이 투표 된 답변은 먼저 표시되는 특성으로 인해 더 많은 투표를 얻습니다.
JS_Riddler

322

대부분의 이전 답변은 위험합니다!

이 작업을 수행하지 마십시오 :

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

다음에 실행할 때 git rebase(또는 git pull --rebase)이 3 개의 커밋은 자동으로 삭제됩니다 newbranch! (아래 설명 참조)

대신 이것을하십시오 :

git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
  • 첫째는 3 가장 최근의 커밋을 삭제 ( --keep같다 --hard,하지만 안전은 던져 멀리 않은 변경보다는 실패).
  • 그런 다음 분기됩니다 newbranch.
  • 그런 다음 3 개의 커밋을 다시 선택합니다 newbranch. 그들은 더 이상 지점에서 참조하고 있기 때문에, 자식의 사용하여 해당하지 않습니다 reflog를 : HEAD@{2}(가) 커밋이다 HEAD우리 1. 체크 아웃하기 전에이 작업 전에 예를 참조하는 데 사용 newbranch과 2를 사용하는 git reset3 개의 커밋을 취소 할 수 있습니다.

경고 : reflog는 기본적으로 활성화되어 있지만 수동으로 비활성화 한 경우 (예 : "bare"git 리포지토리 사용) 실행 후 3 개의 커밋을 다시 가져올 수 없습니다 git reset --keep HEAD~3.

reflog에 의존하지 않는 대안은 다음과 같습니다.

# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(원하는 경우 @{-1}이전에 체크 아웃 한 분기 대신에 oldbranch)를 쓸 수 있습니다 .


기술적 인 설명

git rebase첫 번째 예제 후에 왜 3 개의 커밋을 버릴까요? git rebase인수가 없으면 --fork-point기본적으로 옵션을 사용할 수 있기 때문에 로컬 참조를 사용하여 업스트림 브랜치에 대해 강력한 푸시를 시도합니다.

커밋 M1, M2, M3을 포함 할 때 출발지 / 마스터에서 분기 한 다음 세 개의 커밋을 스스로 수행했다고 가정합니다.

M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic

그러나 누군가가 M2를 제거하기 위해 강제 푸시 원점 / 마스터로 기록을 다시 작성합니다.

M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

로컬 reflog를 사용 git rebase하면 원산지 / 마스터 지점의 초기 구현에서 분기되어 M2 및 M3 커밋이 실제로 토픽 브랜치의 일부가 아님을 알 수 있습니다. 따라서 M2가 업스트림 브랜치에서 제거되었으므로 토픽 브랜치가 리베이스 된 후에는 더 이상 토픽 브랜치에서 원하지 않습니다.

M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)

이 동작은 의미가 있으며 일반적으로 리베이스 할 때해야 할 일입니다.

따라서 다음 명령이 실패하는 이유는 다음과 같습니다.

git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

그들은 reflog를 잘못된 상태로두기 때문입니다. Git newbranch은 3 개의 커밋을 포함하는 개정판에서 업스트림 브랜치에서 분기 한 것으로 확인한 다음 reset --hard다시 커밋을 제거하기 위해 업스트림 히스토리를 다시 작성하므로 다음에 실행 git rebase하면 업스트림에서 제거 된 다른 커밋처럼 삭제합니다.

그러나이 특별한 경우에 우리는이 3 개의 커밋이 토픽 브랜치의 일부로 간주되기를 원합니다. 이를 위해서는 3 개의 커밋이 포함되지 않은 이전 수정 버전에서 업스트림을 분기해야합니다. 그것이 내가 제안한 솔루션이하는 일이므로 둘 다 reflog를 올바른 상태로 둡니다.

자세한 내용 --fork-pointgit rebasegit merge-base docs 의 정의를 참조하십시오 .


14
이 답변은 "이 작업을 수행하지 마십시오!"라고 말합니다. 아무도 제안하지 않은 것 위에.
Ryan Lundy

3
대부분의 사람들은 특히에 게시 된 기록을 다시 쓰지 않습니다 master. 그래서, 그들은 위험하지 않습니다.
Walf

4
@Kyralessa, -t당신이 언급 한 것은 git branch암시 적 으로 발생합니다 git config --global branch.autosetuprebase always. 그렇지 않은 경우에도 OP가 질문을 할 가능성이 있기 때문에 이러한 명령을 수행 한 후 추적을 설정하면 동일한 문제가 발생한다고 이미 설명 했습니다.
John Mellor

2
@RockLee, 예, 그러한 상황을 해결하는 일반적인 방법은 안전한 출발점에서 새로운 지점 (newbranch2)을 만든 다음 유지하려는 모든 커밋 (badnewbranch에서 newbranch2까지)을 선택하십시오. 체리 피킹은 커밋에 새로운 해시를 제공하므로 newbranch2를 안전하게 리베이스 할 수 있습니다 (이제 badnewbranch를 삭제할 수 있음).
John Mellor

2
@ Walf, 당신은 오해 : git rebase 는 히스토리를 다시 쓰는 업스트림에 대해 강력하게 설계되었습니다. 불행히도, 그 견고성의 부작용은 그들이나 그들의 업스트림이 역사를 다시 쓰지 않더라도 모든 사람들에게 영향을 미칩니다.
John Mellor

150

자식 숨김을 사용하는 훨씬 간단한 솔루션

다음은 잘못된 브랜치에 대한 커밋을위한 훨씬 간단한 솔루션입니다. master세 가지 잘못된 커밋이 있는 지점에서 시작 :

git reset HEAD~3
git stash
git checkout newbranch
git stash pop

이것을 언제 사용합니까?

  • 기본 목적이 롤백하는 경우 master
  • 파일 변경 사항을 유지하려고합니다
  • 실수 한 커밋에 대한 메시지는 신경 쓰지 않습니다
  • 아직 밀지 않았습니다
  • 당신은 이것을 암기하기 쉽기를 원합니다.
  • 임시 / 새 브랜치, 커밋 해시 찾기 및 복사 및 기타 두통과 같은 합병증을 원하지 않습니다.

이것이 행 번호로하는 일

  1. 에 대한 마지막 3 개의 커밋 (및 해당 메시지)을 취소 master하지만 모든 작업 파일은 그대로 둡니다.
  2. 모든 작업 파일 변경 사항을 숨기고 master작업 트리를 HEAD ~ 3 상태와 정확히 동일하게 만듭니다.
  3. 기존 지점으로 전환 newbranch
  4. 숨김 변경 사항을 작업 디렉토리에 적용하고 숨김을 지 웁니다.

당신은 지금 사용 git add하고 git commit평소처럼. 모든 새로운 커밋이에 추가됩니다 newbranch.

이것이하지 않는 것

  • 임의의 임시 가지가 나무를 혼란스럽게하지 않습니다.
  • 잘못된 커밋 메시지를 보존하지 않으므로이 새로운 커밋에 새로운 커밋 메시지를 추가해야합니다.
  • 최신 정보! 위쪽 화살표를 사용하여 명령 버퍼를 스크롤하여 이전 커밋을 커밋 메시지와 함께 다시 적용하십시오 (@ARK 덕분에)

목표

OP는 목표는 변경 사항을 잃지 않고 "커밋하기 전에 다시 마스터"하는 것이 목표이며이 솔루션은이를 수행한다고 밝혔다.

나는 실수로 master대신에 새로운 커밋을 할 때 적어도 일주일에 한 번이 작업을 수행합니다 develop. 일반적으로 롤백 할 커밋은 하나뿐입니다.이 경우 git reset HEAD^라인 1을 사용하는 것이 하나의 커밋을 롤백 하는 간단한 방법입니다.

마스터 변경 사항을 업스트림으로 푸시 한 경우이 작업을 수행하지 마십시오

다른 사람이 이러한 변경 사항을 가져 왔을 수 있습니다. 로컬 마스터 만 다시 작성하는 경우 업스트림으로 푸시해도 아무런 영향이 없지만 다시 작성된 기록을 공동 작업자에게 푸시하면 두통이 발생할 수 있습니다.


4
고마워, 내가 여기에 도착하기 위해 과거 /를 너무 많이 읽었 기 때문에 너무 기쁘다. 우리는 비정형 적입니까?
Jim Mack

6
우리는 전적으로 전형적인 것으로 생각하며 "실수로 커밋 한 루프"는 커밋을 소수 또는 그 이하로 되돌릴 필요가있는 가장 일반적인 유스 케이스입니다. 운 좋게도이 솔루션은 너무 간단하여 지금 암기했습니다.
슬램

9
이것이 정답입니다. 간단하고 이해하기 쉽고 기억하기 쉽습니다
Sina Madani

1
스 태싱이 필요하다고 생각하지는 않습니다. 나는 방금없이 그것을하고 잘 작동했습니다.
Campos

1
CLI (명령 행) 히스토리에 커밋 메시지가 있으면 커밋 메시지를 쉽게 다시 가져올 수 있습니다. 내가 사용한 명령 git addgit commit명령을 모두 사용하여 위쪽 화살표를 누르고 몇 번 들어가서 붐을 일으켰습니다! 모든 것이 돌아 왔지만 지금은 오른쪽 지점에 있습니다.
Luke Gedeon

30

이것은 기술적 의미에서 "이동"하지 않지만 동일한 효과가 있습니다.

A--B--C  (branch-foo)
 \    ^-- I wanted them here!
  \
   D--E--F--G  (branch-bar)
      ^--^--^-- Opps wrong branch!

While on branch-bar:
$ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

A--B--C  (branch-foo)
 \
  \
   D-(E--F--G) detached
   ^-- (branch-bar)

Switch to branch-foo
$ git cherry-pick E..G

A--B--C--E'--F'--G' (branch-foo)
 \   E--F--G detached (This can be ignored)
  \ /
   D--H--I (branch-bar)

Now you won't need to worry about the detached branch because it is basically
like they are in the trash can waiting for the day it gets garbage collected.
Eventually some time in the far future it will look like:

A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
 \
  \
   D--H--I--J--K--.... (branch-bar)

1
rebase같은 것을 사용할 수 없습니까 ?
Bergi

rebase, 위 시나리오에서 분리 된 분기에서 대신 사용할 수 있습니다 .
Sukima 2016 년

24

기록을 다시 쓰지 않고이 작업을 수행하려면 (예 : 커밋을 이미 푸시 한 경우) :

git checkout master
git revert <commitID(s)>
git checkout -b new-branch
git cherry-pick <commitID(s)>

그러면 두 가지를 강제로 밀 수 있습니다!


그러나 상황에 따라 훨씬 까다로울 수있는 되돌리기 시나리오를 처리해야합니다. 브랜치에서 커밋을 되돌 리더라도 Git은 커밋이 발생한 것으로 계속 인식하므로이를 취소하려면 되돌리기를 되돌려 야합니다. 이것은 특히 병합을 되돌리고 지점을 다시 병합하려고 할 때 상당히 많은 사람들을 태워 버립니다.
Makoto

1
그래서 마지막에 커밋을 새 브랜치로 선택합니다. 그런 식으로 git은 그것들을 새로운 커밋으로 간주하여 문제를 해결합니다.
teh_senaus

이 상태의 의미를 실제로 이해하지 않고 리포지토리 기록의 상태를 변경하기 때문에 처음보다 더 위험합니다.
Makoto

5
나는 당신의 주장을 따르지 않습니다.이 답변의 요점은 당신이 단순히 새로운 커밋을 추가하여 변경 사항을 효과적으로 취소 할 수 있다는 것입니다. 이 새로운 커밋은 정상적으로 푸시하고 병합 할 수 있습니다.
teh_senaus

13

이 상황 만 있었다 :

Branch one: A B C D E F     J   L M  
                       \ (Merge)
Branch two:             G I   K     N

나는 수행했다 :

git branch newbranch 
git reset --hard HEAD~8 
git checkout newbranch

커밋은 HEAD가 될 것이라고 기대했지만 L은 커밋입니다.

커밋의 해시로 작업하기가 더 쉬운 역사의 올바른 지점에 도달하기 위해

git branch newbranch 
git reset --hard #########
git checkout newbranch

7

이걸 어떻게 할 수 있습니까

A - B - C - D - E 
                |
                master

이에?

A - B - C - D - E 
    |           |
    master      newbranch

두 명령으로

  • 자식 분기 -m 마스터 새 분기

기부

A - B - C - D - E 
                |
                newbranch

  • 자식 분기 마스터 B

기부

A - B - C - D - E
    |           |
    master      newbranch

그렇습니다, 이것은 효과적이고 아주 쉽습니다. 소스 트리 GUI는 git 쉘의 변경 사항에 대해 약간 혼란 스럽지만 가져 오기 후에는 다시 정상입니다.
lars k.

예, 그들은 질문에서와 같습니다. 첫 번째 다이어그램은 문제의 다이어그램과 동일하게 만들어졌으며 답의 예시 목적으로 원하는 방식으로 다시 그렸습니다. 기본적으로 마스터 분기의 이름을 newbranch로 바꾸고 원하는 곳에 새 마스터 분기를 만듭니다.
Ivan

4

푸시되지 않은 커밋을 모두 새로운 브랜치 로 옮길 필요가 있다면 ,

  1. 만들 새로운 지점 현재의에서를 :git branch new-branch-name

  2. 당신의 새로운 지점을 밀어 :git push origin new-branch-name

  3. 복귀 하여 기존 (현재) 분기를 마지막 밀어 / 안정된 상태로 :git reset --hard origin/old-branch-name

어떤 사람들은 또한 다른 upstreams것이 아니라 origin적절한 것을 사용해야합니다.upstream


3

1) 새 브랜치를 작성하면 모든 변경 사항이 new_branch로 이동합니다.

git checkout -b new_branch

2) 그런 다음 오래된 지점으로 돌아갑니다.

git checkout master

3) 자식 리베이스 수행

git rebase -i <short-hash-of-B-commit>

4) 그런 다음 열린 편집기에는 마지막 3 개의 커밋 정보가 포함됩니다.

...
pick <C's hash> C
pick <D's hash> D
pick <E's hash> E
...

5) 변경 pickdrop이들 3 커밋 모든있다. 그런 다음 편집기를 저장하고 닫습니다.

...
drop <C's hash> C
drop <D's hash> D
drop <E's hash> E
...

6) 이제 마지막 분기 3 개의 커밋이 현재 분기 ( master) 에서 제거됩니다 . 이제 +지점 이름 앞에 부호를 사용하여 지점을 강제로 밀어 넣으십시오 .

git push origin +master

2

당신이 할 수있는 것은 내가 사용한 3 단계입니다.

1) 최근 업데이트를 커밋하려는 지점을 새로 만듭니다.

git branch <branch name>

2) 새로운 지점에서 커밋 할 최근 커밋 ID를 찾습니다.

git log

3) 해당 커밋 ID를 복사하십시오. 가장 최근의 커밋 목록이 맨 위에 나타납니다. 커밋을 찾을 수 있습니다. 당신은 또한 메시지를 통해 이것을 찾을 수 있습니다.

git cherry-pick d34bcef232f6c...

커밋 ID를 제공 할 수도 있습니다.

git cherry-pick d34bcef...86d2aec

이제 당신의 일이 끝났습니다. 올바른 ID와 올바른 지점을 선택하면 성공합니다. 따라서이 작업을 수행하기 전에주의하십시오. 다른 문제가 발생할 수 있습니다.

이제 코드를 푸시 할 수 있습니다

git push


0

이를 수행하는 다른 방법 :

[1]master 지점의 이름을 바꿉니다 ( 지점에 newbranch있다고 가정 master).

git branch -m newbranch

[2]master 원하는 커밋에서 분기를 만듭니다 .

git checkout -b master <seven_char_commit_id>

예 : git checkout -b master a34bc22

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.