작성한 질문수 1

0

안녕하세요 😄

내 코드를 이전의 상태로 되돌릴 때, reset 또는 revert를 사용하죠.

이때,
개발 이력을 나의 브랜치에 남겨두고 싶은 경우는 revert.
개발 이력을 나의 브랜치에 남겨두고 싶지 않은 경우는 reset을 사용합니다.

복잡하고 어려운 내용을 배울 땐, '사례'가 이해하는데 큰 도움을 주죠!

예를 들어볼게요.

main 브랜치에 A-B-C 커밋이 있습니다.
여기서, C 커밋에 회사의 민감한 정보를 실수로 추가했습니다.
음... API key같은 것을 말이죠!

이때는 revert 보다는 reset을 사용해야 합니다.
C 커밋을 main브랜치에서 제외하기 위함입니다.

추가적으로 궁금하신 부분이 있다면,
언제든 편하게 질문해주세요!

0

안녕하세요, 인프런 AI 인턴입니다. 자영님, 질문 주셔서 감사합니다. reset과 revert를 선택해야 하는 다양한 상황에 관심이 생기셨군요. 두 명령어는 모두 커밋을 되돌리는 역할을 하지만, 상황에 따라 어떤 것을 선택할지 결정해야 하는 경우가 있습니다.

reset과 revert의 일반적인 선택 기준:

1. 협업 시 고려 사항:

   • reset: reset은 커밋 기록을 삭제하거나 수정하기 때문에 공유된 원격 리포지토리에서 사용 시 주의해야 합니다. 이미 다른 개발자들이 해당 커밋에 기반한 작업을 하고 있다면 예상치 못한 충돌이 발생할 수 있습니다.
     
   • revert: revert는 커밋을 대체하지 않고, 새로운 커밋을 추가하여 이전 상태로 변경 사항을 적용합니다. 따라서 팀원과 협업하고 있을 때 더 안전한 선택이 가능합니다.
     

2. 작업 흐름에 따른 차이:

   • reset: 프로젝트의 진행을 빠르게 롤백해야 하거나, 커밋을 완전히 삭제해야 할 때 주로 사용됩니다. reset은 파일의 현재 상태를 과거의 특정 커밋 상태로 변경해버리기 때문에 주의가 필요합니다.
     
   • revert: 특정 기능을 일시적으로 중단하고 싶을 때 자주 사용합니다. 이 방법은 과거 커밋을 취소하면서도 기록을 남길 수 있어 이후의 변경 상황을 명확하게 할 수 있습니다.
     

추가 사례:

1. 리포지토리 클린업 중:
   원치 않는 커밋이 여러 개 발생한 경우 reset을 사용하여 최근 커밋을 정리할 수 있습니다. 그러나 이때는 주의해야 하며, 직접 커밋된 코드가 아니라면 revert로 안전하게 되돌릴 수 있습니다.

2. 버전 관리 중 실수 복구:
   코드의 실수나 잘못된 머지를 발견했을 때 revert를 사용하여 실수만을 되돌리고, 원래의 커밋 기록을 유지함으로써 오류의 추적이 가능합니다.

Git에서 이러한 기능을 사용할 때마다 그 목적과 영향을 신중하게 고려해야 합니다. 사용자가 작업한 내용을 기록으로 남기면서도 변경 관리가 가능한 revert가 안전적으로 선호되는 이유입니다.

유사한 질문과 더 많은 예시는 다음의 유사한 사례를 참조할 수 있습니다:

• Git에서 reset과 revert를 선택하는 다양한 상황 이해하기
  

저는 질문자님의 이해를 돕고자 유사한 주제를 다루는 기존 답변 링크를 추천해드렸습니다. 이 기능은 현재 베타 서비스 중으로, 답변이 기대에 미치지 못할 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 다시 질문해 주세요. 곧 지식공유자께서도 도움을 주실 것입니다.