Git 스테이징 서버 및 라이브 서버 관리

Question

새 사이트를 개발하는 동안 Git/Beanstalk을 사용하고 있었으며 로컬 서버에서 스테이징 서버로 변경 사항을 푸시하는 데 이상적이었습니다. 지금 프로덕션 서버로 "라이브"로 가고 싶고 정상적인 절차가 무엇인지 궁금해하고 있습니다 (다른 많은 링크는 이것을 다루지 않습니다 ...).

스테이징 서버에서 지난 6 개월 동안 수천 번 변경 한 내용이 아니라 새로운 프로덕션 서버로 "신선한"상태에서 시작하고 싶습니다. 이것을 할 수있는 방법이 있습니까? 새로운 저장소를 만들고 기존 저장소를 제거하는 등의 작업을 수행합니까? 내역을 지워서 이제는 스테이징 서버에있는 것을 가져 와서이를 푸시 (또는 로컬 서버에서 푸시) 할 수 있습니다. 타워를 사용하므로 문제가 거의 발생하지 않도록 망할 놈에 대해서 충분히 알 수 있습니다 (커맨드 라인은 내 것이 아닙니다). 모든 것을 마무리하고 "이것은 버전 1.0입니다. 여기에서 시작합시다"라고 말 할 수 있습니까?

또한 캐쉬 파일과 이미지 등을 무시할 때 게으름이 많았습니다. 사실 그 후에 .gitignore 파일을 쉽게 추가 할 수 있습니까?

Answer 1

git 리포지토리가 실제로 큰 경우가 아니라면 (실수로 미디어 파일을 추가했기 때문에)이 작업을 수행하지 않아도됩니다. 버전 관리의 전체적인 요점은 변화의 기록을 유지하는 것입니다. 그래서 여러분은 어떤 것을 언제 추가했는지, 그리고 왜 보았는지를 돌아보고 볼 수 있습니다. 튜토리얼에서 다루지 않는 이유는 단순히 git를 일반적으로 사용하는 방법이 아니기 때문입니다.

당신이 이것을 원한다는 유일한 이유는 git (대용량 미디어 파일, 캐시 등)에 속하지 않은 모든 파일을 추가 한 것입니다. 삭제 된 이후 오래 걸리며 프로덕션 서버로 푸시 할 시간 (.gitignore 파일로 시작하는 것을 잊었다고 언급 한 이후). 모든 텍스트 파일은 git으로 압축되어 있기 때문에 작성한 커밋 수에 대해 걱정할 필요가 없습니다 (비교를 위해 PHP source code은 70,000 커밋 이상, 14 년 만기, linux kernel은 300,000 커밋 이상, 다른 많은 성공적인 오픈 소스 프로젝트도 이와 비슷합니다. 따라서 1000 개의 커밋을 작성해도 git이 처리 할 수있는 부분의 표면을 간신히 긁어 모으고 있습니다.

이 경우, 당신이하는 일은 전체 기록을 지우는 것뿐 아니라 새로운 빈 저장소를 만드는 것입니다. /.git 디렉토리를 삭제하고 새 디렉토리 (타워 또는 명령 행 git init)를 초기화하기 만하면됩니다.

참고 신선한 저장소를 만들고 스테이징 서버로 푸시하려고 시도하면 --force 옵션을 사용해야합니다. 그렇지 않으면 내역을 다시 쓰려는 중 불평 할 것입니다. 푸시를 클릭하면 타워에도 비슷한 힘 체크 박스가 나타납니다.

실제로 파일 뒤에 .gitignore 개의 파일을 추가 할 수 있습니다. 그러나 이전에 저장소에 추가 한 파일은 제거되지 않습니다. 따라서 처음부터 파일을 커밋하지 않는 것이 좋습니다. 그렇지 않으면 저장소 기록에 영구적으로 저장됩니다 (기록을 다시 쓰고 오래된 커밋에서도 모든 흔적을 지우는 방법이 있지만 어렵고 범위를 벗어납니다). 이 대답).

Answer 2

Adrian이 말한 것처럼 Git에서 많은 수의 바이너리 파일을 가져야 만 (예 : 이미지 업로드 등) 않는 한이 문제는 실제로 문제가되지 않습니다. 개인적으로 나는 디버깅을하는 데 매우 귀중하므로 내 역사에 신경을 쓰지 않을 것입니다. 물론 커밋과 빈도에 대해 꽤 잘 훈련되어 있습니다.

당신은 당신이 이전에 추가 한 당신의 repo에서 파일을 제거하기를 원하지만 로컬 복사본을 유지하려면이 수행

자식 RM은 --cached/경로//

이 제거됩니다 제거 그것들을 현재 색인 상태에서 제외하고 실제 파일을 보관하십시오. 그런 다음 실제 파일을 .gitignore에 추가 할 수 있습니다. 이것은 실수로 git에 추가 된 파일 또는 repo 크기 나 보안에 관련이없는 작은 파일에 대해 파일에 유용합니다.

이전에 파일을 커밋 한 경우에도 해당 파일은 이전 기록에 남게되므로 전체 repo 크기가 비정상적으로 증가 할 수 있습니다 (예 : PSD 또는 이전에 큰 이미지를 추가 한 경우). 완전히 역사에서 파일을 제거 (도 편리 어떻게 든 민감한 데이터 기었다 경우) 당신은 할 수 있습니다 :

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <NAME OF FILE>' --prune-empty --tag-name-filter cat -- --all 

어떤 사용자가 지정한 파일을 포함 커밋 변경 모든 브랜치와 태그의 전체 역사를 실행이 명령, , 이후의 커밋 이후에 비어있는 커밋 (완전히 Rakefile 만 변경 되었기 때문에) 경고 : 기존 태그를 덮어 씁니다. 좋은데. 파일을 제거하면

당신은 당신의 변경을 밀어 강제해야 할 수도 있습니다

git push <remote> <branch> --force 

그러나 당신은 당신으로하지만 그 시점에서 옳은 일을하고있는 확신되고 싶어 리모컨의 기록도 덮어 쓰게되고 그 시점에서 정말로 사라질 것입니다. 이 경로를 따라 간다면 우수하고 상세한 자습서 here이 있습니다.

Beanstalk을 사용하는 경우 전체 저장소/기록이 아닌 최신 버전의 파일 만 배포하므로 중요한 문제는 아닙니다.

Answer 3

Beanstalk은 최신 버전의 파일 만 배포합니다 (또는 다른 버전을 원할 경우). 따라서 프로덕션 서버를 추가하면 Beanstalk은 현재 저장소에있는 모든 파일을 프로덕션 서버로 업로드합니다.

변경에 따라 변경 사항이 적용되지 않으므로 '기록'이 느려지거나 공간을 사용하지 않습니다.