스택큐힙리스트

저는 리포지토리와 함께 사용되는 composer.lock에 조금 혼동되고 있습니다. 많은 사람들이 우리가 리포지토리에서 composer.lock을 .gitignore 해야하지 않는다고 말하고 있습니다. 개발 환경에서 라이브러리를 업데이트한다면 새로운 composer.lock이 생기지만, 제품 환경으로 업데이트할 수 없을 텐데 맞을까요? 이 파일은 충돌을 생성하지 않을까요?답변 1만약 라이브러리를 업데이트한다면, lockfile도 커밋하고 싶을 것입니다. 이것은 당신의 프로젝트가 사용하고 있는 라이브러리의 특정 버전에 잠겨있음을 나타냅니다. 당신의 변경사항을 커밋하고 다른 사람이 코드를 가져와 의존성을 업데이트하면, lockfile은 수정되지 않아야 합니다. 만약 수정되었다면, 새로운 버전이 있는 것을 의..

원격 상에 더 이상 존재하지 않는 모든 트래킹 브랜치를 삭제하는 간단한 방법이 있을까요? 예시: 브랜치 (로컬 및 원격) master origin/master origin/bug-fix-a origin/bug-fix-b origin/bug-fix-c 로컬에는 오직 master 브랜치만 존재합니다. 이제 bug-fix-a 에 작업을 하기 위해 체크아웃하고, 작업을 진행하고, 변경사항을 원격에 푸시합니다. 그 다음 bug-fix-b 에 대해서도 같은 작업을 수행합니다. 브랜치 (로컬 및 원격) master bug-fix-a bug-fix-b origin/master origin/bug-fix-a origin/bug-fix-b origin/bug-fix-c 이제 로컬에는 master, bug-fix-a, bu..

Git에서 저장소를 가지고 있습니다. 브랜치를 만들었고, 마스터와 브랜치 모두에 일부 변경을 하였습니다. 그런 다음, 수십 개의 커밋 후에, 브랜치가 마스터보다 훨씬 더 좋은 상태임을 깨달았으므로 브랜치를 마스터로 전환하고 마스터의 변경 사항을 무시하고 싶습니다. 병합할 수는 없으므로 마스터의 변경 사항을 유지하지 않으려고 합니다. 어떻게 해야 할까요? 추가: 이 경우에는 '이전' 마스터가 이미 다른 저장소(예: GitHub)로 push되었습니다. 이것은 어떤 영향을 미칩니까?답변 1다른 두 가지 답변의 문제는 새로운 마스터가 이전 마스터를 조상으로 가지고 있지 않기 때문에 푸시할 때 다른 사람들이 꼬이게 됩니다. 다음과 같이 수행해야 합니다: git checkout better_branch git me..

이 질문은 이미 여기에 대한 답변이 있습니다: 'git push'를 취소하는 방법 (17개의 답변) 닫힘 4년 전. 커뮤니티는 이 질문을 다시 열지 여부를 검토했고 2개월 전에 검토했으며 그대로 닫혀있었습니다: 원래의 닫힘 이유가 해결되지 않았습니다 나는 GitHub에 실수로 커밋을 푸시했습니다. 이 커밋을 제거할 수 있을까요? 제가 이 커밋 이전으로 GitHub 저장소를 되돌리고 싶습니다.답변 1 참고: 아래 댓글에서 git rebase -i에 대한 대안을 찾아보세요. git reset --soft HEAD^ 먼저 로컬 저장소에서 커밋을 제거하세요. 이는 git rebase -i를 사용하여 수행할 수 있습니다. 예를 들어, 마지막 커밋인 경우, git rebase -i HEAD~2를 실행하고 팝업된 편..