초기 상황은 a와 b의 코드베이스가 완전히 동일하다는 것입니다.
1, 코드를 수정한 후 성공적으로 bitbucket에 푸시했습니다.
2. a가 변경한 사항은 다음과 같습니다. 프로그램의 app/storage/sessions/
디렉토리는 처음에는 .gitignore
에 추가되지 않았기 때문에 .gitignore
에 이 디렉토리를 추가했습니다.
3, b 자체에는 코드가 있지만 수정되지 않았습니다. a가 업데이트되었기 때문에 b는
의 충돌 때문일 수 있습니다. Git은 재설정될 것이라고 생각하여 .gitignore
문장을 프롬프트합니다( 재설정(영어로 재설정)하므로 다른 항목을 선택하고(선택한 항목을 잊어버렸습니다) 계속 진행합니다. 일반적인 풀 및 커밋에서는 bitbucket으로의 풀이 성공했다는 메시지가 표시되지만, 코드를 보면 a의 변경 사항이 표시되지 않습니다. b는 주의를 기울이지 않고 계속해서 코드를 수정하고 B는 이를 메시지로 표시합니다. git reset --hard
$ git add --ignore-removal app/storage/sessions/
예를 들어 사진에는 a가 추가한 것들이 있고, 그 외 코드도 많이 있는데...지금은 다 삭제됐네요..
b의 변경 사항을 유지하면서 a가 성공적으로 푸시한 변경 사항을 복원하는 방법은 무엇입니까? A의 커밋에는 160개의 파일 변경 사항이 있고, b의 파일 변경 사항은 60개가 넘습니다... 게다가 a와 b2는 코드를 하나씩 논의하고 비교합니다. 내 아이디어를 복원할 수 있는 더 좋은 솔루션이 있을까요? 감사합니다...
@nightire의 답변에 따르면 a는 다음 작업을 수행했습니다
으아아아
그래서 파일을 수정하고 빈 줄을 추가한 후 다시# git push --force orgin php-v0.0.1:php-v0.0.1
으아아아
b가 또 잘못 연산한 것 같습니다. 이 브랜치가 잘못된 것 같습니다. 그러다가 b가 다시 와서 다음과 같이 매개변수를 추가하지 않고 가져왔습니다으아아아
현재 b는 a가 추가한 파일과 이전에 a가 수정한 파일을 아직 가지고 있지 않습니다(b가 오류를 범하기 전, a가 수정하고 코드를 성공적으로 푸시했습니다)(이번에 a는 빈 줄을 추가했고, b도 성공했습니다.)...
모두의 의견과 계획을 바탕으로
수술
으아아아
을 사용하는데, 코드가 올바른 커밋으로 롤백되지 않습니다. 잘못 사용된 것 같습니다..git revert commit
으아아아
a실행
으아아아
으아아아
나머지는 브랜치 내부의 다른 코드입니다...php_bbb
을 사용하고 수정하도록 하세요...git diff php-v0.0.1 php_bbbb >> 11.txt
(/ □ )
오리진 마스터를 가져오기 전에 b에 abcde와 같은 커밋이 있습니다
으아악B Pull 전의 모습으로 돌아갑니다
그리고 a를 뽑은 적이 없기 때문에 이제 빈 줄을 추가한 a를 제출하는 것을 제외하고는 원래 모습으로 돌아온 것으로 간주할 수 있습니다
즉, 지금은 2와 같은 상태여야 합니다.
을 실행하세요. 으아악현재 귀하의 b도 깨끗한 작업 공간입니다(무단계 변경 없음)
현재 상태가 실제로 2와 같다고 확신한다면 b에서
.gitignore와 같은 충돌이 있다는 알림이 표시됩니다
을 실행합니다. 으아악그런 다음 .gitignore 파일을 열고 충돌을 해결한 다음
리베이스 과정에서 예상하지 못한 일이 발생하면 임의로 조작하지 마시고
git rebase --abort
포기하신 후 질문을 추가해주세요그렇게 복잡하진 않은 것 같은데...
아, 최신 로컬 업데이트는 아직 괜찮죠? 내 말은, B가 마지막으로 밀고 나서 A가 당기지 않았다는 거죠, 그렇죠? 이런 경우에는 A가 B의 마지막 푸시를 직접 덮어쓰도록 강제하고, 그런 다음 B가 이번에는 실수하지 않도록 하세요. 앞으로는 괜찮을 것입니다.
A가 이미 최신(즉, 잘못된) 코드를 가져온 경우 로컬에서 원래 올바른 코드로 재설정한 다음 위의 작업을 반복하세요.
한마디로 중앙 저장소에 무슨 일이 일어나도 원하는 커밋을 항상 찾을 수 있다는 것이 배포의 장점이다.
어지럽고 git 명령줄이 익숙하지 않아서 구체적인 답변은 드리지 않겠습니다.
이 시나리오에서는
git pull
이 명령을 사용하면 안 되며,fetch & rebase
이 올바른 방법이라는 점을 말씀드리고 싶습니다게다가 Git의 사용 자세가 더 문제입니다
기존 코드를 엉망으로 만드는 문제를 해결하는 것보다(언제든지 해결할 수 있는 작은 문제입니다) 팀 내에서 올바른 git 자세를 대중화하는 것이 더 중요합니다
참고: 성공적인 Git 분기 모델 http://www.juvenxu.com/2010/11/28/a-successful-git-branching-model/