문서 및 프로젝트 관리에 Git을 사용해야합니까? 코드가 별도의 저장소에 있어야합니까?

68

그룹 프로젝트를 위해 Git 리포지토리를 시작하고 있습니다. 코드와 동일한 Git 리포지토리에 문서를 저장하는 것이 합리적입니까? 이것은 git 개정 흐름의 특성과 충돌하는 것처럼 보입니다.

내 질문에 대한 요약은 다음과 같습니다.

코드와 문서가 모두 같은 저장소에 체크인 되면 Git 개정 스타일이 혼란 스러울 까요? 이것에 대한 경험?
Git이 문서 개정 관리에 적합합니까?
나는 NOT 일반적으로 개정 제어 시스템이 나 문서에 사용하지 않아야한다 묻는 - 그것은해야한다.

지금까지 의견을 보내 주셔서 감사합니다!

git version-control project-management

— EmpireJones
소스

아, 알겠습니다 ... 설명해 주셔서 감사합니다. 왜 그것이 문제가 될지 모르겠지만, GIT에 대한 개인적인 경험 (이론적 이해)이 없으므로 더 직접적인 경험을 가진 사람이 그 질문에 대답하도록 할 것입니다.

— Flimzy 2016 년

1

이것이 어떻게 주제에 관한 것인지 잘 모르겠습니다. 당신은 소프트웨어 문서에 대해 이야기하고 DVCS와 커밋

— Tim Post

문서와 요구에 따라 다를 수 있습니다. diff가 필요하고 처리 할 수있는 형식입니까? 자식이 필요한 서비스를 제공한다면. 별도의 문서 관리 시스템을 보유하고 있습니다.

— Rig

문서가 평문 인 경우-좋습니다. 이진 형식 인 경우에는 이진 형식을 이해하는 버전 제어 시스템이 필요합니다.이 형식은 가장 순수한 형태의 공급 업체입니다.

관련 : 프로젝트의 어떤 부분이 소스 코드 제어에 있어야합니까?

— gnat

53

우리는 항상 SVN에 문서를 저장합니다. 사실, 전체 사용자 설명서는 LaTeX로 작성되었으며 SVN에 저장됩니다. LaTeX는 텍스트 기반 언어이기 때문에 LaTeX를 구체적으로 선택했으며 한 줄씩 다른 diff를 쉽게 표시 할 수있었습니다.

또한 필요한 경우 Microsoft Office .doc 파일, 스프레드 시트, .zip 파일 등과 같이 텍스트가 아닌 형식의 파일도 저장하지만 증분을 볼 수 없으면 RCS의 이점 중 일부가 손실됩니다 diffs.

핵심은 사람들이 필요할 때 문서 (및 소스)를 찾아서 업데이트 할 수 있도록 문서가 잘 정리되어 있는지 확인하는 것입니다.

— 어렴풋한
소스

11

Microsoft 매장 인 경우 TortoiseSVN은 MS Office line-by-line diff를 지원합니다.

— Phil

2

이진 문서 형식을 삭제하면 세상을 더 나은 곳으로 만들 수 있습니다. o 문서가 일반 텍스트 인 경우 DVCS에도 실제 문제가 없어야합니다.

— Kai Inkinen 2016 년

아, 그리고 TortoiseSVN 및 doc 파일에 대해 처음 들었으므로 +1입니다. 나중에 언제라도 Tortoise [AnyDVCS]로 끝날지 궁금합니다.

— Kai Inkinen

@ 필 : TortoiseSVN은 어떻게 이것을 달성합니까? doc-diff 뷰어는 SVN 클라이언트와 통합되어 있습니까? 아니면 독립적으로 사용할 수 있습니까?

— Flimzy 2016 년

1

멋진 옵션은 Pandoc을 사용 하여 대부분 의 문서가 Markdown에 있지만 중요한 부분은 여전히 TeX를 사용할 수 있다는 것입니다. 마크 다운을 LaTeX로 컴파일하기 때문에 결과는 동일하게 보입니다. 그러나 이렇게하면 다른 형식으로 내 보내서 소스를보다 쉽게 읽을 수 있습니다.

— Tikhon Jelvis

22

문서에 어떤 형식을 사용 하느냐에 따라 다릅니다. 텍스트 기반이라면 모두 좋습니다.

Git은 바이너리 콘텐츠를 저장할 수 있으며 수정 내용을 추적 할 수 있지만 diff 출력은 의미가 없습니다.

perldoc pod와 같은 코드 자체에 문서를 저장할 수도 있습니다. java는 이것에 대한 형식 / 주석이 있습니다.

— 성기
소스

텍스트가 아닌 문서를 저장할 수는 있지만 git 대신 텍스트를 저장하면 git이 훨씬 잘 작동한다는 데 동의합니다. 단어 (또는 유사한) 문서를 어떻게 다른지 아는 diff 드라이버에 대한 이야기가 있었지만 그것이 구현되었는지 확실하지 않습니다

— Sverre Rabbelier

Word는 형식을 이진에서 XML로 옮겼습니다.

— cledoux

3

@ karategeek6 Word의 'XML'형식은 사람이 읽을 수 없습니다. 그리고 한 줄의 텍스트는 근사하더라도 Word의 한 줄에 해당하지 않습니다. 따라서 이진 일 수도 있습니다.

압축되지 않은 XML로 출력을 저장하도록 Word에 지시 할 수 있습니다. 선택 Save As선택한 다음, Word XML Document (*.xml)대신 기본으로 Word Document (*.docx). XML은 매우 복잡하므로 변경 사항을 쉽게 읽을 수 있다고 보장 할 수는 없지만 적어도 이진은 아닙니다.

— Kyralessa

> diff 출력은 의미가 없습니다. diff의 경우 문서의 2 개정판을 나란히 열고 눈으로 비교할 수 있습니다 :)

— Luke

14

git 또는 다른 버전 제어 시스템을 문서화하는 데 문제가 있다고 생각하는 이유를 상상할 수 없습니다. 소스 코드와 마찬가지로 설명서에는 전체 기록이 있어야하며 필요한 경우 이전 버전으로 되돌릴 수 있어야합니다. 버전 관리 시스템은이 점에 완벽합니다.

6

문서가 텍스트 형식 인 경우에만 해당됩니다. 이진 얼룩은 버전 제어의 이점을 완전히 얻지 못합니다.

2

@ ThorbjørnRavnAndersen : 그렇더라도 바이너리 전용 버전 관리 시스템이 없다면 바이너리 파일조차도 자체 파일이 아닌 Git에 보관하는 것이 좋습니다.

— Tikhon Jelvis

@TikhonJelvis 바이너리 파일을 git에 넣는 것이 좋은 아이디어인지에 대해서는 의문의 여지가 없었습니다. 그러나 Word 문서에서 "git diff"를 실행 해보십시오.

@ user1249 : 당신은 "수출"바탕 화면에 2 개정, 말할 수 my_docs_rev15.docx 및 my_docs_rev14.docx 다음 옆에 그것을 쪽을 열고이 아니 어려운 :), 눈과 뇌 비교

— 누가 복음

14

문서를 저장하기 위해 어떤 종류의 Version Control System을 사용하는 것은 쉬운 일이 아닙니다. 질문의 더 흥미로운 부분은 문서를 동일한 위치에 소스 코드로 저장하는 것이 좋은지 여부입니다. 여기서 가능한 문제점은이 경우 코드 및 문서에 대해 다른 액세스 권한을 설정하기 어려울 수 있다는 것입니다. 그리고 많은 비즈니스 사례에서 사람들은 문서에 액세스해야하지만 마케팅이나 BA 부서와 같은 소스 코드는 필요하지 않습니다.

— Ma99uS
소스

3

예, "동일한 위치"는이 질문의 핵심 부분 중 하나입니다!

부족한 지식이 있거나 (보는 곳을 알 필요가 있거나) 물건의 위치를 찾아야 할 필요가 없으므로 관리 할 수 있으면 같은 위치가 좋습니다.

— quick_now

코드에 액세스 할 필요는 없지만 액세스 할 수있는 것은 아프지 않아야합니다. 그들은 그것을 볼 필요가 없습니다. 비밀은 일반적으로 버전 관리에 있어서는 안됩니다.

— bdsl

9

내가 일하는 회사에서는 SVN에 문서를 넣었습니다. 그러나 갈등이 적고 공유해야 할 필요성이 발생한 후에 우리는이를 Mediawiki로 옮기기로 결정했습니다.

처음에는 trac이었고, 그 후에 Mediawiki로 옮겨서 사용하기가 더 쉬워졌습니다 ...

SVN의 주요 문제점은 SVN에 대한 권한 부여 시스템이있는 공유 원인이었습니다.

— Confiq
소스

2

Wikipedia에서 사용하는 Wiki 엔진 인 Mediawiki를 의미하지 않습니까?

@Martijn, 나는 그렇게 생각 것

— 테오 Klestrup Röijezon

@Martijn : 예, 편집 됨

— confiq

오히려 SCM에 코스가 아닌 많은 파일을 보내는 대신 위키를 고수하고 싶지만 개인 취향과 관련이 있습니다. 당신이 할 수있는 일이 훨씬 더 많습니다. Foswiki 및 웹 사이트 기반 / 프로젝트 기반 템플릿을 특히 좋아합니다. 문제로 인해 위키를 사용하기로 결정한 것이 기쁘다. :) +1.

— Oeufcoque Penteano

9

리포지토리에 소스 코드 이상을 갖는 것이 매우 좋습니다.

모든 리소스를 그룹화하고 흩어져있는 파일 모음이 아닌 응집 된 중앙 집중식 개체로 프로젝트를 전환합니다. 기고자 / 직원은 "기능 x에 대한 문서를 어디에서 변경합니까?"를 보내지 않고 모든 것을 찾을 수있는 위치를 알고 있습니다. 이메일.

일을 체계적으로 유지하고 싶을 것입니다. src에서 를 분리하기위한 시스템이 있어야 images합니다 docs. .gitignore저장소와 히스토리를 깨끗하게 유지하기 위해 항상 디렉토리에 a 를 추가 할 수 있습니다 . Git 커밋은 파일 기반이기 때문에 원하는대로 문서 변경 사항에서 소스 변경 사항을 분리 할 수 있습니다.
다른 사람들이 말했듯이 Git은 텍스트 기반의 문서 버전 관리에 좋습니다.
완전히 동의 해; 문서는 코드와 함께 버전이 지정되어야합니다.

저의 신뢰는 GitHub 사용자로서 하나의 프로젝트에 기여하고 많은 다른 프로젝트를 탐색하는 데 있습니다. 내 경험상 완전하고 통일 된 프로젝트는 반쯤 빠진 프로젝트에서 쉽게 알 수 있습니다. 가능할 때마다 모든 프로젝트를 단일 디렉토리 내에 포함 시키려고합니다.

커밋 할 파일의 일부 를 지정하는 방법이 있기 때문에 이것은 정확하지 않습니다 ( 여기의 예가 있습니다 ).

— 타일러 웨인
소스

4

나는 비슷한 질문으로 여기에왔다. 우리는 SVN 환경에서 왔습니다. 기본적으로 프로젝트와 관련된 모든 자료를 동일한 저장소에 보관하는 것은 쉬운 일이 아닙니다. SVN의 특성으로 인해 리포지토리의 일부를 쉽게 확인할 수 있으므로 소스 코드 (예 : 웹 사이트 배포) 만 있으면 문제가되지 않습니다.

Git을 사용하면 상황이 다릅니다. 체크 아웃은 항상 루트 수준이므로 모든 것을 동일한 저장소에 저장하려면 항상 동일한 디렉토리 구조로 끝납니다. 내가 만난 한 가지 접근 방식은 모든 것을 별도의 분기에 배치하는 것입니다. 즉, 코드 분기 (일반적으로 일반 마스터, 개발 등) 인 분기와 고유 한 별도의 디렉토리 구조를 갖는 문서 분기를 갖는 것입니다. 나는 그것이 최선의 아이디어인지 아직 확실하지 않지만, 내가 상상하는 문제를 피할 수있는 제안입니다.

— 엘케 볼록
소스

근본적으로 다른 디렉토리 구조를 가진 다른 브랜치는 나에게 매우 나쁜 코드 냄새가납니다. 모든 것을 하나의 리포지토리에 남겨두면 기고자들이 코드와 문서를 더 쉽게 추가 할 수 있습니다. 실제로, 문맹 프로그래밍 (Google that!)이 요구합니다.

— tbc0

패키지를 배포 할 때 모든 서버에 실행 파일을 다운로드 할 수있는 .deb 스타일의 일부이며 개발 상자에도 문서 패키지가 있습니다.

— tbc0

1

내부 문서에 위키를 사용하고 있습니다. 문서가 동기화되지 않은 경우 즉시 업데이트하십시오. 최종 사용자 문서의 경우 Madcap Flare 와 같은 전문 도구를 고려하십시오. 문서 를 공유, 작성 및 변환하기 위해 XML 언어를 사용합니다.

— 마이클 브라운
소스

-1

코드에서 생각은 일반적으로 한 줄씩 분리됩니다. 부드러운 줄 바꿈으로 문서를 작성하는 경향이 있습니다. 해당 파일을 커밋 할 때 줄은 전체 단락 길이입니다. 에서 읽는 것은별로 유용하지 않습니다 git diff. 그것이 내가 Google 검색 하고이 페이지를 찾을 때 해결하려고했던 문제입니다. 소개해 주신 Arne Hartherz 에게 감사드립니다 git diff --word-diff. git diff --color-words더 좋을 수도 있습니다 .

— tbc0
소스