Programing

여러 Git 커밋 (이미 푸시 됨)을 게시 된 저장소로 되돌리려면 어떻게해야합니까?

lottogame 2020. 11. 20. 08:24
반응형

여러 Git 커밋 (이미 푸시 됨)을 게시 된 저장소로 되돌리려면 어떻게해야합니까?


git을 처음 접했고 이미 엉망입니다.

원격 개발 시스템에 몇 가지 변경 사항을 적용하고 푸시했습니다. 이전 버전을 복구해야하지만 지금까지 "나쁜 진행 상황"을 유지하여 별도의 브랜치에서 계속 작업합니다.

나는 다음과 같이 생각하고 있었다.

  1. "tested-thing"이라는 로컬 분기를 만듭니다.
  2. 로컬 저장소 를 작동했던 상태로 되돌립니다 (의미있는 커밋이 도움이되기를 바랍니다) .
  3. 원격으로 푸시

  4. 테스트 대상에 대한 테스트 완료

  5. "테스트 된 것" 을 dev에 병합
  6. 원격으로 푸시

3 단계와 5 단계 사이에 다른 개발자가 커밋하고 푸시 할 수 있으며 "병합 비극"이 발생할 수 있습니다.-어쨌든, 이것이 적절한 방법일까요?

최신 정보:

여기서 주요 문제는 2)에 있습니다.

여기, 주제 : "토픽 브랜치로 작업 나누기 " http://learn.github.com/p/undoing.html

그들은 제안합니다 :

  1. $ git 브랜치 테스트
  2. $ git reset --hard a6b4c974

이렇게함으로써 다른 개발자는 다음을 수행 할 수 있습니다.

$ git commit (개발 브랜치에서)

체크 아웃하여 병합 시간 까지 테스트 하고 해결할 수 있습니다 .

모든 옵션에도 불구하고 이것은 따라야 할 좋은 접근 방식 인 것 같습니다. 그러나 우리가?를 누른 후에 이것이 할 수 있는지 여부는 명시되어 있지 않습니다.

다음 사항에 유의하십시오. 변경 사항을 적용하고 모든 것을 엉망으로 만들었 으므로 지금까지 아무도 저장소에서 작업하지 않았습니다 . 따라서 작업 디렉토리를 되 돌리면 아무도 눈치 채지 못할 것입니다.


문제

사용할 수있는 여러 워크 플로가 있습니다. 요점은 브랜치를 소비 할 수 있고 모든 클론에 대해 기꺼이 수술을 할 의향이있는 모든 사람과 소통하지 않는 한 게시 된 브랜치의 역사를 깨지 않는 것입니다. 피할 수 있다면 그렇게하지 않는 것이 가장 좋습니다.

게시 된 지점을위한 솔루션

설명 된 단계에는 장점이 있습니다. dev 브랜치가 즉시 안정적이어야한다면 그렇게하세요. 올바른 분기점을 찾는 데 도움이 되는 Git 으로 디버깅을 위한 여러 도구 가 있으며, 마지막 안정적인 커밋과 HEAD 사이의 모든 커밋을 되돌릴 수 있습니다.

한 번에 하나씩 커밋을 역순으로 되돌 리거나 <first_bad_commit>..<last_bad_commit>범위를 사용합니다 . 해시는 커밋 범위를 지정하는 가장 간단한 방법이지만 다른 표기법이 있습니다. 예를 들어 5 개의 잘못된 커밋을 푸시 한 경우 다음을 사용하여 되돌릴 수 있습니다.

# Revert a series using ancestor notation.
git revert --no-edit dev~5..dev

# Revert a series using commit hashes.
git revert --no-edit ffffffff..12345678

이것은 당신의 작업 디렉토리에 역방향 패치를 순서대로 적용하고 당신의 알려진 좋은 커밋을 향해 거꾸로 작동합니다. 으로 --no-편집 각 반전 패치가 적용된 후 플래그, 작업 디렉토리에 변경 사항이 자동으로 커밋됩니다.

참조 man 1 git-revert더 많은 옵션을 위해, 그리고 man 7 gitrevisions다른 방법을 커밋이 복귀를 지정할 수 있습니다.

또는 HEAD에서 분기하고 필요한 방식으로 수정 한 다음 다시 병합 할 수 있습니다. 그 동안 빌드가 중단되지만 상황에 따라 의미가있을 수 있습니다.

위험 지역

물론, 잘못된 푸시 이후에 아무도 저장소에서 가져 오지 않았다고 확신 하고 원격 저장소베어 저장소 인 경우 빠른 전달이 아닌 커밋을 수행 할 수 있습니다.

git reset --hard <last_good_commit>
git push --force

이렇게하면 시스템과 업스트림 호스트에서 reflog가 그대로 유지되지만 잘못된 커밋은 직접 액세스 할 수있는 기록에서 사라지고 풀에 전파되지 않습니다. 이전 변경 사항은 저장소가 정리 될 때까지 유지되지만 Git 닌자 만 실수로 만든 커밋을 보거나 복구 할 수 있습니다.


이미 원격 서버에 작업을 푸시 한 경우 (다른 개발자가 동일한 원격 지점에서 작업하는 경우) 명심해야 할 중요한 사항은 기록을 다시 작성하고 싶지 않다는 것입니다.

git reset --hard를 사용하지 마십시오.

변경 사항을 되돌려 야합니다. 그렇지 않으면 기록에서 제거 된 커밋이있는 체크 아웃이 다음에 푸시 할 때 해당 커밋을 원격 저장소에 다시 추가합니다. 그리고 다른 체크 아웃은 그 이후에 다음 풀 때 그들을 끌어 올 것입니다.

변경 사항을 리모컨에 푸시 하지 않은 경우 다음 사용할 수 있습니다.

git reset --hard <hash>

당신은 경우 밀려 변경,하지만 당신이 사용할 수있는 아무도 그들을 뽑아 없다 확신

git reset --hard
git push -f

당신이 경우 변경을 추진, 누군가가 자신의 체크 아웃로 뽑아있다 당신은 공동 작업을해야하는 것입니다 그것은 그러나 다른 팀 멤버 / 체크 아웃을 여전히 수 있습니다 :

(you) git reset --hard <hash>
(you) git push -f

(them) git fetch
(them) git reset --hard origin/branch

그러나 일반적으로 말해서 그것은 엉망으로 변하고 있습니다. 따라서 되돌리기 :

제거 할 커밋이 가장 최신입니다.

This is possibly the most common case, you've done something - you've pushed them out and then realized they shouldn't exist.

First you need to identify the commit to which you want to go back to, you can do that with:

git log

just look for the commit before your changes, and note the commit hash. you can limit the log to the most resent commits using the -n flag: git log -n 5

Then reset your branch to the state you want your other developers to see:

git revert  <hash of first borked commit>..HEAD

The final step is to create your own local branch reapplying your reverted changes:

git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .

Continue working in my-new-branch until you're done, then merge it in to your main development branch.

The commits to remove are intermingled with other commits

If the commits you want to revert are not all together, it's probably easiest to revert them individually. Again using git log find the commits you want to remove and then:

git revert <hash>
git revert <another hash>
..

Then, again, create your branch for continuing your work:

git branch my-new-branch
git checkout my-new-branch
git revert <hash of each revert commit> .

Then again, hack away and merge in when you're done.

You should end up with a commit history which looks like this on my-new-branch

2012-05-28 10:11 AD7six             o [my-new-branch] Revert "Revert "another mistake""
2012-05-28 10:11 AD7six             o Revert "Revert "committing a mistake""
2012-05-28 10:09 AD7six             o [master] Revert "committing a mistake"
2012-05-28 10:09 AD7six             o Revert "another mistake"
2012-05-28 10:08 AD7six             o another mistake
2012-05-28 10:08 AD7six             o committing a mistake
2012-05-28 10:05 Bob                I XYZ nearly works

Better way®

Especially that now that you're aware of the dangers of several developers working in the same branch, consider using feature branches always for your work. All that means is working in a branch until something is finished, and only then merge it to your main branch. Also consider using tools such as git-flow to automate branch creation in a consistent way.


git revert HEAD -m 1

In the above code line. "Last argument represents"

  • 1 - reverts one commits. 2 - reverts last commits. n - reverts last n commits

or

git reset --hard siriwjdd

참고URL : https://stackoverflow.com/questions/10780228/how-can-i-revert-multiple-git-commits-already-pushed-to-a-published-repository

반응형