데이터베이스를 git(버전 제어) 아래에 배치하려면 어떻게 해야 합니까?

데이터베이스를 git(버전 제어) 아래에 배치하려면 어떻게 해야 합니까?

저는 웹 앱을 하고 있는데, 몇 가지 주요 변경 사항을 위해 지점을 만들어야 합니다. 중요한 것은 이러한 변경 사항은 데이터베이스 스키마를 변경해야 하기 때문에 전체 데이터베이스도 포함시켜야 한다는 것입니다.

그걸 어떻게 하는 거죠?깃 저장소 아래에 보관할 수 있는 특정 폴더가 있습니까?어느 쪽인지 어떻게 알 수 있죠?올바른 폴더를 넣었는지 확인하려면 어떻게 해야 합니까?

저는 확신할 필요가 있습니다. 왜냐하면 이러한 변경 사항들은 하위 호환성이 없기 때문입니다. 저는 그것을 망칠 여유가 없습니다.

제 경우의 데이터베이스는 Postgre입니다.SQL

편집:

데이터베이스 대신 백업을 수행하고 백업 파일을 버전 관리 하에 둘 것을 제안했습니다.솔직히 말해서, 저는 그것을 받아들이기가 정말 어렵습니다.

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

업데이트:

좋아요, 그래서 더 좋은 방법은 없지만, 저는 여전히 확신할 수 없습니다. 그래서 저는 질문을 조금 바꾸겠습니다.

데이터베이스 전체를 버전 관리로 하고 싶은데, 덤프 대신 실제 데이터베이스를 버전 관리로 할 수 있도록 어떤 데이터베이스 엔진을 사용할 수 있습니까?

sqlite가 비트 친화적일까요?

이것은 단지 개발 환경이기 때문에, 나는 내가 원하는 데이터베이스를 선택할 수 있습니다.

편집 2:

제가 정말 원하는 것은 개발 기록을 추적하는 것이 아니라, "새로운 근본적인 변경" 분기에서 "현재 안정된 분기" 분기로 전환하고, 예를 들어 현재 안정된 분기로 버그/문제 등을 수정할 수 있는 것입니다.분기를 전환하면 데이터베이스가 자동으로 현재 사용 중인 분기와 호환됩니다.저는 실제 데이터에 대해 별로 신경 쓰지 않습니다.

대신 데이터베이스 덤프를 사용하여 버전을 제어합니다.이렇게 하면 플랫 텍스트 파일이 됩니다.

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

큰 변경을 하는 경우 새 스키마를 변경하는 보조 데이터베이스가 있어야 하며 분기를 만든다고 했으므로 이전 데이터베이스를 건드리지 않아야 합니다.

정말 간단한 해결책이 생각나기 시작했는데, 왜 전에는 생각하지 못했는지 모르겠어요!!

• 데이터베이스(스키마와 데이터 모두)를 복제합니다.
• 새 주요 변경 분기에서 새 중복 데이터베이스를 사용하도록 프로젝트 구성을 변경하기만 하면 됩니다.

이렇게 하면 데이터베이스 스키마 변경에 대한 걱정 없이 분기를 전환할 수 있습니다.

편집:

이란 다른 이름: 중된다것다이은예가름만다를것든스입는니다다이베데터이른복는진른을예▁with것▁database▁another▁by(:▁i입)을 가진 데이터베이스를 만드는 것을 합니다.my_db_2 않습니다; 덤프나 그런 것을 하지 않습니다.

• Irmin(지점 + 시간 여행)
• Flur.ee (불변 + 시간 여행 + 그래프 쿼리)
• XTDB(이전의 'CruxDB')(시간 여행 + 쿼리)
• TerminalDB(불변 + 분기 + 시간 이동 + 그래프 쿼리!)
• DoltDB(지점 + 시간여행 + SQL 쿼리)
• 쿼드러블(분기 + 원격 상태 확인)
• EdgeDB(실시간 이동은 없지만 스키마 변경 후 컴파일러에 의해 파생된 마이그레이션)
• Migra(Postgres 스키마/데이터에 대해 다름).마이그레이션 스크립트 자동 생성, db 상태 자동 동기화)
• ImuDB(불변 + 시간 여행)

LiquiBase와 같은 것을 사용하면 Liquibase 파일의 리비전 제어를 유지할 수 있습니다.운영에 대해서만 변경 사항에 태그를 지정할 수 있으며, 운영 또는 개발(또는 원하는 방식)을 위해 DB를 최신 상태로 유지하도록 할 수 있습니다.

DB 기반 디렉토리 구조와 유사한 무언가가 '파일'을 저장하고 이를 관리하는 데 필요한 비슷한 문제가 발생하여 이 문제를 발견했습니다.복제를 사용하여 클라우드 전반에 걸쳐 분산되므로 MySQL을 통해 액세스 지점이 생성됩니다.

위 답변의 요지는 유사하게 질문된 문제에 대한 대안적인 해결책을 제시하는 것 같습니다. Git을 사용하여 데이터베이스의 무언가를 관리하는 것이 요점을 벗어났습니다. 그래서 저는 그 질문에 답하려고 합니다.

Git는 본질적으로 델타(차이)의 데이터베이스를 저장하는 시스템으로, 컨텍스트를 재현하기 위해 재구성할 수 있습니다.git의 일반적인 사용은 컨텍스트가 파일 시스템이고 해당 파일 시스템에서 델타는 다르지만 실제로는 모든 git는 델타의 계층적 데이터베이스입니다(대부분의 경우 각 델타는 적어도 한 부모가 트리에 정렬된 커밋이기 때문에 계층적 데이터베이스입니다).

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

변경사항을 관리하려면 데이터베이스에 두 가지 개별적인 문제가 있습니다. 이 문제를 별도로 처리합니다(내가 당신이라면).첫 번째는 스키마, 두 번째는 데이터입니다(질문에서 데이터는 걱정할 대상이 아니라고 언급했지만).이전에 문제가 있었던 것은 Dev 및 Prod 데이터베이스였는데, Dev는 스키마를 점진적으로 변경할 수 있었고, 이러한 변경 사항은 CVS에 문서화되어 여러 '정적' 테이블 중 하나에 추가된 것과 함께 유지되도록 전파되어야 했습니다.이를 위해 정적 데이터만 포함된 크루즈라는 세 번째 데이터베이스를 구축했습니다.언제든지 Dev와 Cruise의 스키마를 비교할 수 있었고, 우리는 이 두 파일의 diff를 가져와서 ALTER 문이 포함된 SQL 파일을 생성하여 적용할 수 있는 스크립트가 있었습니다.마찬가지로 모든 새 데이터를 INSERT 명령이 포함된 SQL 파일로 증류할 수 있습니다.필드와 테이블이 추가될 뿐 삭제되지 않는 한 프로세스는 델타를 적용하기 위한 SQL 문 생성을 자동화할 수 있습니다.

를 생성하는 은 git가델타생성메는커니은즘하를▁the▁g▁by은즘메니it커▁del▁mechanismt.diff그리고 그것이 하나 이상의 델타를 파일과 결합하는 메커니즘은,merge만약 당신이 다른 맥락에서 분산하고 병합하는 방법을 생각해 낼 수 있다면, Git이 작동해야 하지만, 논의했듯이 당신은 당신을 위해 그렇게 하는 도구를 선호할 수 있습니다.이 문제를 해결하기 위한 제 첫 번째 생각은 git의 내부 디프 및 병합 도구를 대체하는 방법을 자세히 설명하는 https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Tools 입니다.이 답변은 문제에 대한 더 나은 해결책을 제시하는 대로 업데이트하겠지만, 저의 경우 데이터 변경만 관리하면 될 것으로 예상됩니다. DB 기반 파일 저장소가 변경될 수 있으므로 제 솔루션이 필요한 것이 아닐 수도 있습니다.

바로 이 목적을 위해 만들어진 '교리 아래의 이주'라는 위대한 프로젝트가 있습니다.

그것은 여전히 알파 상태이고 php용으로 만들어졌습니다.

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

RedGate SQL 소스 제어를 살펴봅니다.

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

이 도구는 데이터베이스를 Git로 소스 제어 아래에 배치할 수 있는 SQL Server Management Studio 스냅인입니다.

사용자당 495달러로 다소 비싸지만 28일 무료 평가판이 제공됩니다.

참고 저는 어떤 식으로든 레드게이트와 관계가 없습니다.

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

저는 블라디미르 호리코프의 "데이터베이스 버전 관리 모범 사례"의 이 게시물의 아이디어를 따를 것입니다.요약하자면, 나는 할 것입니다.

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

도움이 된다면요!

나는 당신이 요구하는 것을 수행하는 sqlite용 도구를 출시했습니다.SQLite 프로젝트 도구 'sqlddiff'를 활용하는 사용자 지정 diff 드라이버를 사용하고 UUID를 기본 키로 사용하며 sqlite rowid는 생략합니다.아직 알파로 되어 있어서 피드백을 주시면 감사하겠습니다.

바이너리 데이터가 여러 파일에 보관되어 스냅샷을 만들 수 있었다면 유효하지 않을 수도 있기 때문에 Postgres와 mysql은 더 까다롭습니다.

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

원자성 없이는 할 수 없고, pg_dump나 스냅샷 파일 시스템을 사용하지 않고는 원자성을 얻을 수 없습니다.

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

저는 X-Istence가 올바른 방향으로 가고 있다고 생각하지만, 이 전략을 개선할 수 있는 몇 가지가 더 있습니다.먼저, 다음을 사용합니다.

$pg_dump --schema ... 

테이블, 시퀀스 등을 덤프하고 이 파일을 버전 제어 하에 둡니다.이 옵션을 사용하여 지점 간의 호환성 변경 사항을 구분합니다.

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

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

전체 데이터 덤프를 수행할 때 데이터베이스가 100Mb+에 도달하면 레포가 매우 불안정해질 수 있으므로 이 방법이 좋습니다.더 나은 방법은 앱을 테스트하는 데 필요한 최소한의 데이터 세트를 백업하는 것입니다.기본 데이터가 매우 큰 경우에도 문제가 발생할 수 있습니다.

저장소에 전체 백업을 배치해야 하는 경우 원본 트리 외부의 분기에서 백업을 수행하는 것이 좋습니다.그러나 일치하는 svn rev를 참조하는 외부 백업 시스템이 가장 적합할 수 있습니다.

또한 수정 목적(적어도 스키마의 경우)을 위해 바이너리보다 텍스트 형식 덤프를 사용하는 것이 더 쉽기 때문에 제안합니다.체크인하기 전에 공간을 절약하기 위해 언제든지 이러한 항목을 압축할 수 있습니다.

마지막으로 Postgres 백업 설명서를 살펴보십시오.덤프가 아닌 '데이터베이스' 백업에 대해 언급하는 방식을 보면 파일 시스템 기반 백업을 생각하고 있는지 의문이 듭니다(경고는 섹션 23.2 참조).

당신이 원하는 것은 아마도 데이터베이스 버전을 데이터베이스에 저장하는 PostFacto와 같은 것일 것입니다.이 프레젠테이션을 확인하십시오.

그 프로젝트는 분명히 아무 데도 가지 않았기 때문에 아마 당장 도움이 되지는 않겠지만, 흥미로운 개념입니다.버전 1도 사람들이 작업을 신뢰하도록 하려면 모든 세부 정보를 정확하게 파악해야 하기 때문에 이 작업을 제대로 수행하는 것이 매우 어려울 것으로 우려됩니다.

이 질문은 거의 답변이 되었지만 저는 X-Istence와 Dana the Sane의 답변을 작은 제안으로 보완하고 싶습니다.

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

이를 통해 리비전 제어의 이점과 공간 낭비를 방지할 수 있습니다.

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

프로젝트에서 제가 하려는 것은 다음과 같습니다.

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

데이터베이스 구성이 버전 제어 하에 있지 않은 구성 파일에 저장됩니다(.gitignore).

새 프로젝트 설정을 위한 데이터베이스 기본값은 버전 제어 하에 있는 단순 SQL 파일입니다.

데이터베이스 스키마의 경우 버전 컨트롤 아래에 데이터베이스 스키마 덤프를 만듭니다.

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

다른 빅 오픈 소스 데이터베이스 프로젝트(piwik 또는 가장 좋아하는 cms 시스템)를 보면 모두 업데이트 스크립트(1.sql, 2.sql, 3.sh , 4.sql.5.sql)를 사용합니다.

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

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

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

개인 프로젝트에서 제가 하는 일은 전체 데이터베이스를 드롭박스에 저장한 다음 MAMP, WAMP 워크플로우를 지정하여 바로 사용하는 것입니다.이러한 방식으로 데이터베이스는 항상 최신 상태로 유지됩니다.하지만 그건 단지 개발을 위한 것입니다!라이브 사이트는 코스 외에 자체 서버를 사용하고 있습니다!:)

각 데이터베이스 변경사항을 Git 버전 관리 하에 저장하는 것은 각 커밋으로 전체 데이터베이스를 푸시하고 풀로 전체 데이터베이스를 복원하는 것과 같습니다.데이터베이스가 매우 중요한 변경 사항에 노출되기 쉽고 변경 사항을 완화할 수 없는 경우 pre_commit 및 post_merge 후크를 업데이트하면 됩니다.저도 제 프로젝트 중 하나에서 동일한 작업을 수행했습니다. 여기에서 지침을 찾을 수 있습니다.

그게 제가 하는 방식입니다.

DB 유형은 자유롭게 선택할 수 있으므로 firebird와 같은 파일 기반 DB를 사용합니다.

실제 분기에 적합한 스키마를 가진 템플릿 DB를 만들고 저장소에 저장합니다.

응용프로그램을 실행할 때 템플리트 DB의 복사본을 프로그래밍 방식으로 작성합니다. 다른 곳에 저장한 후 해당 복사본으로 작업하십시오.

이렇게 하면 데이터 없이 DB 스키마를 버전 제어 하에 둘 수 있습니다.그리고 스키마를 변경할 경우 템플릿 DB만 변경하면 됩니다.

우리는 표준 LAMP 구성으로 소셜 웹사이트를 운영하곤 했습니다.라이브 서버, 테스트 서버 및 개발 서버와 로컬 개발자 시스템이 있었습니다.모두 GIT를 사용하여 관리되었습니다.

각 기계에는 PHP 파일뿐만 아니라 MySQL 서비스와 사용자가 업로드할 수 있는 이미지가 있는 폴더가 있었습니다.Live 서버는 약 10만 명의 반복 사용자를 보유하게 되었고, 덤프는 약 2GB(!), 이미지 폴더는 약 50GB(!)였습니다.제가 떠날 무렵, 우리의 서버는 CPU, RAM, 그리고 무엇보다도 동시 연결 제한에 도달하고 있었습니다(서버 'lol'을 최대화하기 위해 자체 버전의 네트워크 카드 드라이버까지 컴파일했습니다).GIT에는 2GB의 데이터와 50GB의 이미지를 저장할 수 없었습니다(또한 귀하의 웹사이트에서도 가정해서는 안 됩니다).

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

릴리스가 되면 관리자는 Dev 서버에 로그인하고 활성 분기를 모든 개발자 및 개발 시스템의 필요한 분기와 업데이트 분기로 병합한 다음 테스트 서버에 푸시합니다.테스트 서버에서 Live 서버에 대한 업데이트 프로세스가 여전히 유효한지 확인하고, 신속하게 연속적으로 Apache의 모든 트래픽을 자리 표시자 사이트로 가리키고, DB 덤프를 만들고, 작업 디렉터리를 'live'에서 'update'로 가리키고, 모든 새 SQL 파일을 mysql로 실행하고, 트래픽을 올바른 사이트로 다시 가리킵니다.테스트 서버를 검토한 후 모든 이해 관계자가 동의하면 관리자는 테스트 서버에서 라이브 서버로 동일한 작업을 수행했습니다.그런 다음 프로덕션 서버의 라이브 분기를 모든 서버의 마스터 분기에 병합하고 모든 라이브 분기를 재배치합니다.개발자들은 그들의 지점을 재배치할 책임이 있었지만, 그들은 일반적으로 그들이 무엇을 하고 있는지 알고 있습니다.

테스트 서버에 문제가 있는 경우(예: 병합에 충돌이 너무 많은 경우) 코드를 되돌리고(작업 중인 분기를 다시 'live'로 가리킴) sql 파일을 실행하지 않았습니다.SQL 파일이 실행되는 순간 이 작업은 복구할 수 없는 작업으로 간주되었습니다.SQL 파일이 제대로 작동하지 않는 경우 Dump를 사용하여 DB를 복원했습니다(그리고 개발자들은 테스트가 제대로 되지 않은 SQL 파일을 제공했다고 질책했습니다).

오늘날 우리는 sql-up 폴더와 sql-down 폴더를 동일한 파일 이름으로 유지하며, 개발자는 업그레이드 sql 파일이 모두 동일하게 다운그레이드될 수 있는지 테스트해야 합니다.이것은 궁극적으로 bash 스크립트로 실행될 수 있지만, 사람의 눈이 업그레이드 프로세스를 계속 모니터링한다면 좋은 생각입니다.

훌륭하지는 않지만 다루기 쉽습니다.이것이 실제적이고 실용적이며 비교적 가용성이 높은 사이트에 대한 통찰력을 제공하기를 바랍니다.좀 구식이긴 하지만, 그래도 여전히 따라다녔습니다.

2019년 8월 26일 업데이트:

Netlify CMS는 GitHub로 이를 수행하고 있으며, netlify-cms-backend-github을 구현한 방법에 대한 모든 정보가 포함된 구현 예를 여기에서 찾을 수 있습니다.

될 수 .데이터는 언제든지 변경될 수 있습니다. 및 의 데이터 .create database그리고.create table단위 검정을 위한 표본 데이터입니다.이것이 라라벨이 데이터베이스 마이그레이션과 시드를 수행하는 방식입니다.

데이터베이스를 제어하는 버전 관리를 위해 neXtep(링크 제거됨 - 도메인이 NSFW-웹 사이트에 의해 인수됨)을 권장합니다. 설치 방법과 발생한 오류를 설명하는 좋은 문서 및 포럼 세트를 가지고 있습니다.저는 그것을 postgre에 대해 테스트했습니다.SQL 9.1과 9.3은 9.1에서 작동할 수 있었지만 9.3에서는 작동하지 않는 것 같습니다.

버전 제어 데이터베이스를 사용합니다. 이제 여러 개가 있습니다.

https://www.dolthub.com/blog/2021-09-17-database-version-control/

이러한 제품은 다른 유형의 데이터베이스 위에 버전 제어를 적용하지 않습니다. 버전 제어 작업을 지원하는 자체 데이터베이스 엔진입니다.그래서 당신은 그들로 이주하거나 우선 그들을 기반으로 건설을 시작할 필요가 있습니다.

저는 그 중 하나인 DoltDB를 작성하는데, 이것은 MySQL과 Git의 인터페이스를 결합한 것입니다.여기를 확인해 보십시오.

https://github.com/dolthub/dolt

iBatis Migrations(수동, 짧은 튜토리얼 비디오)와 같은 도구를 사용하면 데이터베이스 자체가 아니라 프로젝트의 수명 주기 동안 데이터베이스에 대한 변경 내용을 버전 제어할 수 있습니다.

따라서 개별 변경 사항을 다른 환경에 선택적으로 적용하고, 변경 사항이 어떤 환경에 있는지에 대한 변경 로그를 보관하고, 변경 사항 A~N을 적용하는 스크립트를 생성하고, 변경 사항을 롤백할 수 있습니다.

데이터베이스 전체를 버전 관리로 하고 싶은데, 덤프 대신 실제 데이터베이스를 버전 관리로 할 수 있도록 어떤 데이터베이스 엔진을 사용할 수 있습니까?

데이터베이스 엔진에 종속되지 않습니다.Microsoft SQL Server에는 많은 버전 제어 프로그램이 있습니다.git로는 그 문제를 해결할 수 없다고 생각합니다, 당신은 pgsql 특정 스키마 버전 관리 시스템을 사용해야 합니다.그런 일이 있는지 없는지...

좀 더 단순했으면 좋겠어요.스키마를 텍스트 파일로 체크인하는 것은 DB 구조를 캡처하기 위한 좋은 시작입니다.그러나 콘텐츠의 경우 CSV 파일보다 더 깨끗하고 더 나은 git 방법을 찾을 수 없습니다.한 테이블에 하나씩.그런 다음 여러 분기에서 DB를 편집하고 매우 잘 병합할 수 있습니다.

언급URL : https://stackoverflow.com/questions/846659/how-can-i-put-a-database-under-git-version-control