git (버전 제어)에서 데이터베이스를 어떻게 배치 할 수 있습니까?

나는 웹 응용 프로그램을하고 있으며 주요 변경 사항을 분기해야합니다.이 변경 사항은 데이터베이스 스키마를 변경해야하므로 전체 데이터베이스를 git에 넣고 싶습니다.

어떻게합니까? 자식 저장소에 보관할 수있는 특정 폴더가 있습니까? 어느 것을 어떻게 알 수 있습니까? 올바른 폴더를 넣었는지 어떻게 확인할 수 있습니까?

이러한 변경 사항은 이전 버전과 호환되지 않기 때문에 확실해야합니다. 망쳐 놓을 여유가 없어

필자의 경우 데이터베이스는 PostgreSQL입니다.

편집하다:

누군가 백업 대신 백업 파일을 데이터베이스 대신 버전 관리하에 두도록 제안했습니다. 솔직히 말해서, 나는 그것을 삼키기가 정말 어렵다는 것을 알았습니다.

더 좋은 방법이 있어야합니다.

최신 정보:

그래, 더 좋은 방법은 없지만 여전히 확신하지 못하므로 질문을 조금 바꿀 것입니다.

전체 데이터베이스를 버전 제어하에두고 싶습니다. 실제 데이터베이스를 덤프 대신 버전 제어하에 둘 수 있도록 어떤 데이터베이스 엔진을 사용할 수 있습니까?

sqlite가 자식 친화적입니까?

이것이 개발 환경 일 뿐이므로 원하는 데이터베이스를 선택할 수 있습니다.

편집 2 :

내가 정말로 원하는 것은 개발 이력을 추적하는 것이 아니라 "새로운 급진적 변화"브랜치에서 "현재 안정된 브랜치"로 전환하고 예를 들어 현재의 버그 / 문제 등을 수정할 수있는 것입니다. 안정적인 지점. 따라서 지점을 전환하면 데이터베이스가 현재 켜져있는 지점과 자동으로 호환됩니다. 실제 데이터에 대해서는별로 신경 쓰지 않습니다.

데이터베이스 덤프를 가져 와서 대신 버전을 제어하십시오. 이 방법은 플랫 텍스트 파일입니다.

개인적으로 데이터 덤프와 스키마 덤프를 모두 유지하는 것이 좋습니다. diff를 사용하면 스키마에서 개정판에서 변경된 내용을 쉽게 확인할 수 있습니다.

큰 변경을 수행하는 경우 분기를 작성한다고 말한 것처럼 새 스키마를 변경하고 이전 스키마를 건드리지 않는 보조 데이터베이스가 있어야합니다.

리팩토링 데이터베이스를 확인하십시오 ( http://databaserefactoring.com/코드 변경과 함께 데이터베이스를 유지 관리하기위한 유용한 기술에 대해서는 )를 .

당신이 틀린 질문을하고 있다고 말하기에 충분합니다. 데이터베이스를 git에 넣는 대신 스키마 변경 사항을 쉽게 마이그레이션 / 롤백 할 수 있도록 변경 사항을 확인 가능한 작은 단계로 분해해야합니다.

완전한 복구 기능을 원하면 postgres WAL 로그를 보관하고 PITR (특정 복구 시점)을 사용하여 알려진 특정 상태로 트랜잭션을 재생 / 전달해야합니다.

나는 정말로 간단한 해결책을 생각하기 시작했습니다. 왜 전에 그것을 생각하지 못했는지 모르겠습니다!!

• 데이터베이스 (스키마와 데이터 모두)를 복제하십시오.
• 새로운 주요 변경 사항의 분기에서 단순히 새 중복 데이터베이스를 사용하도록 프로젝트 구성을 변경하십시오.

이 방법으로 데이터베이스 스키마 변경에 대한 걱정없이 분기를 전환 할 수 있습니다.

편집하다:

복제한다는 것은 다른 이름으로 다른 데이터베이스를 만드는 것을 의미합니다 (예 my_db_2:). 덤프 등을하지 않는 것.

LiquiBase 와 같은 것을 사용하면 Liquibase 파일의 개정 제어를 유지할 수 있습니다. 프로덕션에 대해서만 변경 사항을 태그하고 프로덕션 또는 개발 (또는 원하는 구성표)에 대해 DB를 최신 상태로 유지할 수 있습니다.

비슷한 요구에 직면했고 여기에 데이터베이스 버전 제어 시스템에 대한 연구가 제기 한 내용이 있습니다.

1. Sqitch-펄 기반 오픈 소스; PostgreSQL을 포함한 모든 주요 데이터베이스에서 사용 가능 https://github.com/sqitchers/sqitch
2. Mahout-PostgreSQL 전용 오픈 소스 데이터베이스 스키마 버전 관리. https://github.com/cbbrowne/mahout
3. Liquibase-또 다른 오픈 소스 DB 버전 제어 소프트웨어. Datical의 무료 버전. http://www.liquibase.org/index.html
4. Datical - Liquibase의 상용 버전 - https://www.datical.com/
5. BoxFuse에 의한 비행-상업용 SW. https://flywaydb.org/
6. 다른 오픈 소스 프로젝트 https://gitlab.com/depesz/Versioning Author는 여기에 가이드를 제공합니다 : https://www.depesz.com/2010/08/22/versioning/
7. Red Gate Change Automation-SQL Server 전용. https://www.red-gate.com/products/sql-development/sql-change-automation/

이 목적을 위해 만들어진 Doctrine에는 마이그레이션이라는 훌륭한 프로젝트가 있습니다.

여전히 알파 상태이며 PHP 용으로 빌드되었습니다.

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

비슷한 문제가있어서 DB 기반 디렉토리 구조와 비슷한 것으로 '파일'을 저장하고 그것을 관리하기 위해 자식이 필요합니다. 복제를 사용하여 클라우드 전체에 분산되므로 액세스 지점은 MySQL을 통해 이루어집니다.

위의 답변의 요지는 데이터베이스에서 무언가를 관리하기 위해 Git을 사용하는 요점을 놓친 문제에 대한 대안 솔루션을 유사하게 제안하는 것 같습니다. 그래서 그 질문에 대답하려고합니다.

힘내 시스템은 본질적으로 델타 (차이점)의 데이터베이스를 저장하고 컨텍스트를 재현하기 위해 재 조립할 수 있습니다. git의 일반적인 사용법은 컨텍스트가 파일 시스템이라고 가정하고 해당 델타는 해당 파일 시스템에 차이가 있지만 실제로 모든 git는 델타의 계층 데이터베이스입니다 (대부분의 경우 각 델타는 최소 1의 커밋이기 때문에 계층 적) 부모님, 나무에 배열).

델타를 생성 할 수있는 한 이론적으로 git은 저장할 수 있습니다. 문제는 일반적으로 git이 델타를 생성하는 컨텍스트가 파일 시스템이 될 것으로 예상하고, 마찬가지로 git 계층의 포인트를 체크 아웃하면 파일 시스템이 생성되는 것으로 예상한다는 것입니다.

데이터베이스에서 변경 사항을 관리하려면 두 가지 불연속 문제가 있으며 별도로 해결해야합니다 (내가 있다면). 첫 번째는 스키마이고 두 번째는 데이터입니다 (질문에서 데이터는 걱정하지 않아도됩니다). 내가 과거에 겪었던 문제는 Dev 및 Prod 데이터베이스였습니다 .Dev 및 Prod 데이터베이스는 Dev가 스키마를 점진적으로 변경할 수 있으며 이러한 변경 사항을 CVS로 문서화하고 여러 '정적'중 하나에 추가하여 라이브로 전파해야했습니다 테이블. 정적 데이터 만 포함하는 Cruise라는 세 번째 데이터베이스를 사용하여이를 수행했습니다. 어느 시점에서나 Dev와 Cruise의 스키마를 비교할 수 있었고,이 두 파일의 차이점을 파악하고 ALTER 문이 포함 된 SQL 파일을 생성하여 적용 할 수있는 스크립트가있었습니다. 새로운 데이터와 마찬가지로 INSERT 명령이 포함 된 SQL 파일로 증류 될 수 있습니다. 필드와 테이블 만 추가되고 삭제되지 않는 한 프로세스는 델타를 적용하기 위해 SQL 문 생성을 자동화 할 수 있습니다.

git이 델타를 생성 diff하는 메커니즘과 하나 이상의 델타를 파일과 결합하는 메커니즘을이라고 merge합니다. 다른 컨텍스트에서 diffing 및 병합하는 방법을 생각해 낼 수 있다면 git은 작동해야하지만 논의 된 것처럼 당신을 위해 그것을하는 도구를 선호 할 수 있습니다. 그것을 해결하기위한 나의 첫 번째 생각은 https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools 입니다 .git의 내부 diff를 바꾸는 방법과 병합 도구. 문제에 대한 더 나은 해결책을 제시함에 따라이 답변을 업데이트 할 것입니다. 그러나 DB 기반 파일 저장소가 변경 될 수있는 한 데이터 변경 만 관리하면됩니다. 정확히 필요한 것이 아닐 수도 있습니다.

RedGate SQL 소스 제어를 살펴보십시오.

http://www.red-gate.com/products/sql-development/sql-source-control/

이 도구는 SQL Server Management Studio 스냅인으로 데이터베이스를 Git을 사용하여 소스 제어에 배치 할 수 있습니다.

사용자 당 495 달러로 약간 비싸지 만 28 일 무료 평가판이 있습니다.

참고 나는 어떤 방식 으로든 RedGate와 제휴하지 않습니다.

비슷한 것을 만들고 데이터베이스 변경 사항을 버전 관리 시스템에 추가하고 싶습니다.

이 게시물의 아이디어는 Vladimir Khorikov "데이터베이스 버전 관리 모범 사례" 에서 따를 것 입니다. 요약하면

• 스키마와 참조 데이터를 소스 제어 시스템에 저장합니다.
• 모든 수정에 대해 변경 사항이있는 별도의 SQL 스크립트를 작성합니다.

도움이 될 경우!

• 어민
• Flur.ee
• Crux DB

Postgres (또는 일반적으로 SQL 데이터베이스)와 동일한 기능을 오랫동안 찾고 있었지만 적절한 (간단하고 직관적 인) 도구는 없습니다. 데이터가 저장되는 방식의 이진 특성 때문일 수 있습니다. Klonio는 이상적으로 들리지만 죽은 것처럼 보입니다. Noms DB 는 흥미롭고 생생 합니다. 또한 Irmin (OCaml 기반 Git 속성)을 살펴보십시오 .

Postgres에서 작동한다는 점에서이 질문에 대한 답변은 아니지만 Flur.ee 데이터베이스를 확인하십시오 . 여기에는 임의의 특정 시점에서 데이터를 쿼리 할 수있는 "시간 이동"기능이 있습니다. "분지"모델로 작업 할 수 있어야한다고 생각합니다.

이 데이터베이스는 최근 블록 체인 목적으로 개발되었습니다. 블록 체인의 특성으로 인해 데이터는 증분 단위로 기록되어야합니다. 이것이 정확히 git의 작동 방식입니다. 그들은있다 Q2 2019 년 오픈 소스 릴리스를 대상으로 .

각 Fluree 데이터베이스는 블록 체인이므로 수행 된 모든 트랜잭션의 전체 기록을 저장합니다. 이것은 블록 체인이 정보가 불변하고 안전하도록 보장하는 방법의 일부입니다 .

업데이트 : 또한 Crux 데이터베이스를 확인하십시오.이 데이터베이스 는 삽입의 시간 차원을 통해 쿼리 할 수 ​​있으며 '버전'으로 볼 수 있습니다. Crux는 고도로 평가 된 Datomic의 오픈 소스 구현 인 것 같습니다.

Crux는 트랜잭션 시간과 유효 시간 기록을 저장하는 임시 데이터베이스입니다. [uni] temporal database는 데이터베이스 생성 순간부터 현재 상태까지 트랜잭션 순서의 데이터베이스 상태를 통해 "시간 여행"쿼리를 가능하게하지만, Crux는 불필요한 설계 복잡성없이 별도의 유효한 시간 축에 대한 "시간 여행"쿼리를 제공합니다. 성능 영향. 즉, Crux 사용자는 정보 도착 순서와 상관없이 과거 및 미래 정보로 데이터베이스를 채울 수 있으며, 과거 기록을 수정하여 주어진 도메인의 개선 된 시간적 모델을 구축 할 수 있습니다.

원 자성 없이는 할 수 없으며 pg_dump 또는 스냅 샷 파일 시스템을 사용하지 않으면 원 자성을 얻을 수 없습니다.

내 postgres 인스턴스는 zfs에 있으며 가끔 스냅 샷을 찍습니다. 거의 즉각적이고 일관성이 있습니다.

실제로 원하는 것은 아마도 데이터베이스에 데이터베이스 버전을 저장하는 Post Facto 와 같은 것 입니다. 이 프레젠테이션을 확인하십시오 .

프로젝트는 분명히 아무데도 가지 않았으므로 즉시 도움이되지는 않지만 흥미로운 개념입니다. 버전 1조차도 사람들이 자신의 작업을 신뢰하기 위해 모든 세부 정보를 가져와야하기 때문에 이것을 올바르게 수행하는 것이 매우 어려울 것입니다.

나는 당신이 요구하는 것을 수행하는 sqlite를위한 도구를 발표했습니다. sqlite 프로젝트 도구 'sqldiff', UUID를 기본 키로 활용하는 사용자 지정 diff 드라이버를 사용하고 sqlite rowid를 제외합니다. 여전히 알파 상태이므로 피드백을 부탁드립니다.

이진 데이터는 여러 파일에 보관되므로 스냅 샷이 가능하지 않으면 Postgres와 mysql이 더 까다로워집니다.

https://github.com/cannadayr/git-sqlite

X-Istence가 제대로 진행되고 있다고 생각하지만이 전략을 개선 할 수있는 몇 가지 사항이 더 있습니다. 먼저 다음을 사용하십시오.

$pg_dump --schema ... 

테이블, 시퀀스 등을 덤프하고이 파일을 버전 제어에 배치하십시오. 이를 사용하여 브랜치 간의 호환성 변경을 분리합니다.

다음으로 양식 기본값 및 기타 사용자가 수정할 수없는 데이터와 같이 응용 프로그램 작동에 필요한 구성이 포함 된 테이블 집합에 대해 데이터 덤프를 수행 하십시오 (사용자 데이터를 건너 뛰어야 할 것 등). 다음을 사용하여 선택적으로이를 수행 할 수 있습니다.

$pg_dump --table=.. <or> --exclude-table=..

전체 데이터 덤프를 수행 할 때 데이터베이스가 100Mb 이상에 도달하면 저장소가 실제로 어수선해질 수 있으므로 이는 좋은 생각입니다. 더 나은 아이디어는 앱을 테스트하는 데 필요한 최소한의 데이터 집합을 백업하는 것입니다. 기본 데이터가 매우 큰 경우에도 여전히 문제가 발생할 수 있습니다.

리포지토리에 전체 백업을 배치해야하는 경우 소스 트리 외부의 브랜치에서 백업을 수행하십시오. svn rev와 일치하는 외부 백업 시스템이 가장 적합 할 것입니다.

또한 수정하기 쉽도록 바이너리보다 텍스트 형식 덤프를 사용하는 것이 좋습니다 (적어도 스키마의 경우). 체크인하기 전에 항상 압축하여 공간을 절약 할 수 있습니다.

마지막으로 postgres 백업 설명서 를 아직 보지 않았다면 살펴보십시오 . 덤프가 아닌 '데이터베이스'백업에 대해 언급하는 방식에 따라 파일 시스템 기반 백업을 생각하고 있는지 궁금합니다 (섹션 23.2 절 참조 ).

이 질문에 대한 답은 거의 있지만 X-Istence와 Dana the Sane의 답변을 약간의 제안으로 보완하고 싶습니다.

어느 정도의 세분성을 가진 수정 제어가 필요한 경우 (예 : 매일), 테이블과 스키마의 텍스트 덤프를 rdiff-backup 과 같은 도구로 연결할 수 있습니다 증분 백업을 하는 있습니다. 매일 백업의 스냅 샷을 저장하는 대신 이전 날과의 차이점 만 저장하면됩니다.

이를 통해 개정 관리의 이점을 모두 누릴 수 있으며 공간을 많이 낭비하지 않습니다.

어쨌든 자주 변경되는 큰 플랫 파일에서 git을 직접 사용하는 것은 좋은 해결책이 아닙니다. 데이터베이스가 너무 커지면 git에서 파일 관리에 문제가 발생하기 시작합니다.

내 프로젝트에서 수행하려는 작업은 다음과 같습니다.

• 별도의 데이터와 스키마 및 기본 데이터.

데이터베이스 구성은 버전 제어 (.gitignore)가 아닌 구성 파일에 저장됩니다.

새 프로젝트를 설정하기위한 데이터베이스 기본값은 버전 관리 하의 간단한 SQL 파일입니다.

데이터베이스 스키마의 경우 버전 제어에서 데이터베이스 스키마 덤프를 작성하십시오.

가장 일반적인 방법은 SQL 문 (ALTER Table .. 또는 UPDATE)이 포함 된 업데이트 스크립트를 사용하는 것입니다. 또한 현재 버전의 스키마를 저장하는 데이터베이스에 장소가 있어야합니다)

다른 큰 오픈 소스 데이터베이스 프로젝트 (piwik 또는 선호하는 cms 시스템)를 살펴보십시오. 모두 업데이트 스크립트 (1.sql, 2.sql, 3.sh, 4.php.5.sql)를 사용합니다.

그러나이 작업은 시간이 많이 걸리는 작업이므로 업데이트 스크립트를 작성하고 테스트해야하며 버전을 비교하고 필요한 모든 업데이트 스크립트를 실행하는 공통 업데이트 스크립트를 실행해야합니다.

그래서 이론적으로 (그리고 내가 찾고있는 것) 각 변경 후 (수동으로, conjob, git hooks (커밋 전에)) 데이터베이스 스키마를 덤프 할 수 있습니다 (일부 매우 특별한 경우에만 업데이트 스크립트를 만듭니다)

그런 다음 일반적인 업데이트 스크립트에서 (특별한 경우 일반 업데이트 스크립트를 실행 한 후) 스키마 (덤프 및 현재 데이터베이스)를 비교 한 다음 필수 ALTER 문을 자동으로 생성하십시오. 이 작업을 이미 수행 할 수 있지만 아직 좋은 도구는 찾지 못한 도구가 있습니다.

데이터베이스를 제어하는 ​​버전에 neXtep 을 권장 합니다. 설치 방법과 발생한 오류를 설명하는 문서와 포럼이 많이 있습니다. postgreSQL 9.1 및 9.3에서 테스트했지만 9.1에서는 작동하지만 9.3에서는 작동하지 않는 것 같습니다.

개인 프로젝트에서 수행하는 작업은 전체 데이터베이스를 보관 용 계정에 저장 한 다음 바로 MAMP, WAMP 워크 플로를 사용하여 바로 사용하는 것입니다. 이러한 방식으로 데이터베이스는 항상 개발이 필요한 모든 곳에서 최신 상태를 유지합니다. 그러나 그것은 단지 개발자를위한 것입니다! 라이브 사이트는 그 과정에서 자체 서버를 사용하고 있습니다! :)

git 버전 관리에서 각 레벨의 데이터베이스 변경 사항을 저장 하는 것은 커밋마다 전체 데이터베이스를 푸시 하고 풀 당 전체 데이터베이스를 복원하는 것과 같습니다 . 데이터베이스가 중요한 변경 사항에 취약하고이를 풀 수없는 경우 pre_commit 및 post_merge 후크를 업데이트하면 됩니다. 내 프로젝트 중 하나와 동일한 작업을 수행했으며 여기 에서 지침을 찾을 수 있습니다 .

그것이 내가하는 방법입니다.

DB 유형에 대해 자유롭게 선택할 수 있으므로 파이어 버드와 같은 파일 기반 DB를 사용하십시오.

실제 브랜치에 맞는 스키마가있는 템플리트 DB를 작성하고이를 저장소에 저장하십시오.

응용 프로그램을 프로그래밍 방식으로 템플릿 DB의 복사본을 만들 때 다른 곳에 저장하고 해당 복사본으로 작업하십시오.

이 방법으로 DB 스키마를 데이터없이 버전 관리하에 둘 수 있습니다. 스키마를 변경하면 템플릿 DB 만 변경하면됩니다.

우리는 표준 LAMP 구성에서 소셜 웹 사이트를 운영했습니다. 로컬 개발자 컴퓨터뿐만 아니라 라이브 서버, 테스트 서버 및 개발 서버가있었습니다. 모두 GIT를 사용하여 관리되었습니다.

각 컴퓨터에는 PHP 파일뿐만 아니라 MySQL 서비스 및 사용자가 업로드 할 이미지가있는 폴더가 있습니다. 라이브 서버는 약 100K (!)의 반복 사용자를 갖도록 성장했으며 덤프는 약 2GB (!), 이미지 폴더는 약 50GB (!)였습니다. 내가 떠날 무렵, 서버는 CPU, Ram 및 무엇보다도 동시 네트워크 연결 제한에 도달했습니다 (우리는 서버 'lol'을 최대한 활용하기 위해 자체 버전의 네트워크 카드 드라이버도 컴파일했습니다). 우리는 할 수 없었다 ( 도 당신은 당신의 웹 사이트와 가정해야 ) GIT에 2GB의 데이터와 이미지의 50 기가 바이트 넣어.

GIT에서이 모든 것을 쉽게 관리하기 위해이 폴더 경로를 .gitignore에 삽입하여 이진 폴더 (이미지를 포함하는 폴더)를 무시합니다. 또한 Apache documentroot 경로 외부에 SQL이라는 폴더가있었습니다. 이 SQL 폴더에서 개발자의 SQL 파일을 증분 번호 매기기 (001.florianm.sql, 001.johns.sql, 002.florianm.sql 등)에 넣습니다. 이 SQL 파일도 GIT에서 관리했습니다. 첫 번째 SQL 파일에는 실제로 큰 DB 스키마 세트가 포함되어 있습니다. GIT에는 사용자 데이터 (예 : users 테이블의 레코드 또는 주석 테이블)를 추가하지 않지만 구성 또는 토폴로지 또는 기타 사이트 별 데이터와 같은 데이터는 sql 파일 (및 GIT에 의해)로 유지됩니다. SQL 스키마 및 데이터와 관련하여 GIT에서 유지 관리하지 않는 내용과 내용을 결정하는 대부분의 개발자 (코드를 가장 잘 아는 사람)

릴리스되면 관리자는 dev 서버에 로그인하여 라이브 분기를 모든 개발자 및 dev 시스템의 필요한 분기와 업데이트 분기로 병합 한 후 테스트 서버로 푸시합니다. 테스트 서버에서 라이브 서버의 업데이트 프로세스가 여전히 유효한지 확인하고 빠른 속도로 Apache의 모든 트래픽을 플레이스 홀더 사이트로 지정하고 DB 덤프를 작성하고 작업 디렉토리를 'live'에서 'update'로 지정합니다. ', 모든 새 sql 파일을 mysql로 ​​실행하고 트래픽을 올바른 사이트로 다시 지정합니다. 테스트 서버를 검토 한 후 모든 이해 관계자가 동의하면 관리자는 테스트 서버에서 라이브 서버로 동일한 작업을 수행했습니다. 그 후 프로덕션 서버의 라이브 브랜치를 모든 서버의 마스터 브랜치에 병합하고 모든 라이브 브랜치를 리베이스합니다.

테스트 서버에 문제가 발생한 경우 (예 : 병합이 너무 많은 충돌을 일으킨 후 코드가 되돌려지고 (작업 분기를 '실시간'으로 다시 지정) SQL 파일은 실행되지 않았습니다. SQL 파일이 실행되는 순간, 이는 되돌릴 수없는 조치로 간주되었습니다. SQL 파일이 제대로 작동하지 않으면 덤프를 사용하여 DB를 복원 한 것입니다 (그리고 개발자는 테스트를 거친 SQL 파일 제공에 대해 알려주었습니다).

오늘날 우리는 sql-up 및 sql-down 폴더를 동일한 파일 이름으로 유지 관리합니다. 여기서 개발자는 업그레이드 sql 파일 모두를 동일하게 다운 그레이드 할 수 있는지 테스트해야합니다. 이것은 궁극적으로 bash 스크립트로 실행될 수 있지만 육안으로 업그레이드 프로세스를 계속 모니터링하는 것이 좋습니다.

훌륭하지는 않지만 관리가 가능합니다. 이것이 실제적이고 실용적이며 비교적 고가용 성인 사이트에 대한 통찰력을 제공하기를 바랍니다. 조금 구식이지만 여전히 따르십시오.

변경 사항의 버전을 제어 할 수있는 iBatis 마이그레이션 ( 수동 , 짧은 튜토리얼 비디오 ) 과 같은 도구를 사용하십시오. 데이터베이스 자체가 아니라 프로젝트 수명주기 동안 데이터베이스 할 수 있습니다.

이를 통해 개별 환경에 개별 변경 사항을 선택적으로 적용하고, 어떤 환경에 어떤 변경 사항이 있는지에 대한 변경 로그를 유지하고, 변경 사항 A부터 N까지 적용하는 스크립트, 롤백 변경 등을 수행 할 수 있습니다.

전체 데이터베이스를 버전 제어하에두고 싶습니다. 실제 데이터베이스를 덤프 대신 버전 제어하에 둘 수 있도록 어떤 데이터베이스 엔진을 사용할 수 있습니까?

데이터베이스 엔진에 의존하지 않습니다. Microsoft SQL Server에는 많은 버전 제어 프로그램이 있습니다. git으로 문제를 해결할 수 있다고 생각하지 않으므로 pgsql 특정 스키마 버전 제어 시스템을 사용해야합니다. 그런 것이 존재하는지 모르겠습니다 ...

2019 년 8 월 26 일 업데이트 :

Netlify CMS 는 GitHub를 통해이를 수행하고 있으며 구현 방법에 대한 모든 정보와 함께 여기에서 예제 구현을 확인할 수 있습니다. netlify-cms-backend-github