Какой рабочий процесс Git для веб-серийной литературы - PullRequest
0 голосов
/ 04 сентября 2018

Я хочу опубликовать художественную литературу в виде веб-сериала, используя git в качестве мультиинструмента. Это фанфик из фильма Worm Дж. С. "Wildbow" МакКрея. Оригинальная художественная литература разделена на дуги, сами разделены на главы и интерлюдии различной длины, и я намерен сохранить ту же структуру. Я думаю, что git будет лучшим инструментом для управления версиями, публикации через github или gitlab и отправки исправлений до и после публикации.

Но хотя я использую git для простого повседневного управления версиями, я недостаточно хорошо знаю инструмент, чтобы выбрать лучший рабочий процесс для такой задачи. Если честно, мне даже не комфортно с ветками. И это не классический проект. Структура отличается от проекта кода: каждая глава публикуется в хронологическом порядке, но не зависит от других.

Пока что я создал схему, чтобы проиллюстрировать, как я хочу создавать и публиковать свой контент. ДАЖЕ, ЕСЛИ ЭТО СМОТРЕТЬ, КАК ОДИН, ЭТО НЕ ГИТ РАБОТАЕТ . Сначала это было, но я подумал, что это плохо отражает реальный рабочий процесс git. После этого это становится более иллюстрацией того, как каждая глава будет развиваться независимо от других, будучи опубликованной в хронологическом порядке и сохраняемой или даже переписанной после.

Итак, как я могу использовать git для производства, публикации и поддержки контента веб-сериалов?
Каков будет лучший рабочий процесс git для моего проекта?

Извините, если мой пост неясен, мой английский не очень хорош, но не стесняйтесь спрашивать меня о каких-либо разъяснениях.

Спасибо, что читаете меня, и каждый конструктивный вклад приветствуется!

enter image description here

РЕДАКТИРОВАТЬ: разъяснения, переписать, переместить некоторую информацию для лучшей видимости

Ответы [ 2 ]

0 голосов
/ 07 сентября 2018

Прежде всего, я должен сказать, я люблю добавление легенды на картинке.

Этот ответ посвящен тому, как выполнить ветвление, фиксацию и слияние. Я действительно не сосредотачиваюсь на том, как настроена файловая система. Я больше смотрю на то, как в конце будет выглядеть журнал коммитов.


Если бы я занялся написанием веб-серии дуг и глав, я мог бы сделать это примерно так.

Я бы использовал главы записи в описательных ветвях, чтобы при слиянии изменений с производством Git автоматически делал хорошее сообщение о слиянии, содержащее основы того, что было сделано в этой ветви.

mkdir arc_01 arc_02  # Create a few directories to start with
git init             # master is the branch automatically created
echo "Worm Serial Table of Contents" >> table_of_contents.txt
git add table_of_contents.txt
git commit -m "Initial commit. Includes table of contents"

git branch published # create publishable branch

# start creating content
git checkout -b arc-01-chapter-01-draft   # Checkout branch for the chapter one
echo "Arc 1, Chapter 1" > arc_01/chapter_01.txt # start writing chapter
git add arc_01/chapter_01.txt
git commit -m "First draft of arc 1, chapter 1"

# continue with first chapter
echo "It was a dark and stormy night and\
 everything was dreary" >> arc_01/chapter_01.txt
git add arc_01/chapter_01.txt
git commit -m "Finished draft of arc 1, chapter 1"

# Merge with production branch
git checkout -b production master # create the production branch at master
git merge --no-ff arc-01-chapter-01-draft

# By checking out production then merging into the branch you were just
#  working on, Git will auto-fill the merge commit with a useful description of:
#      "Merge branch 'arc-01-chapter-01-draft' into production"

# Then you can delete the draft branch because you don't need it right now
git branch -d arc-01-chapter-01-draft

Хорошо, это один этап. Далее: логирование и бета.

# Now we can see our progress by doing some kind of git log
git log --decorate --graph --oneline --all
#  *   726e661 (HEAD -> production) Merge branch 'arc-01-chapter-01-draft' into production
#  |\
#  | * 29c00f7 Finished draft of arc 1, chapter 1
#  | * e8cbcd6 First draft of arc 1, chapter 1
#  |/
#  * d419ebf (published, master) Initial commit. Includes table of contents

Затем, когда вы захотите приступить к созданию бета-версии, вы можете checkout создать новую ветку.

git checkout -b arc-01-chapter-01-beta production
# checkout the next branch at the current production point

# Edit the first chapter (in this case, rewrite it all)
echo "Arc 1, Chapter 1" >> arc_01/chapter_01.txt
echo "It was a dark and silent night, and everything was calm." >> arc_01/chapter_01.txt
git add arc_01/chapter_01.txt

# Finish revisions
git commit -m "Beta revisions for arc 1, chapter 1"

# Merge production into the new update
git checkout production
git merge --no-ff arc-01-chapter-01-beta

git branch -d arc-01-chapter-01-beta

# Now you are ready to publish chapter 1
git checkout published
git merge --ff-only production

git log --decorate --graph --oneline --all
# *   c9da9d7 (HEAD -> published, production) Merge branch 'arc-01-chapter-01-beta' into production
# |\
# | * a3f9294 Beta revisions for arc 1, chapter 1
# |/
# *   726e661 Merge branch 'arc-01-chapter-01-draft' into production
# |\
# | * 29c00f7 Finished draft of arc 1, chapter 1
# | * e8cbcd6 First draft of arc 1, chapter 1
# |/
# * d419ebf (master) Initial commit. Includes table of contents

Таким образом, вы можете работать над несколькими главами как один раз. Будет одновременно работать несколько веток. Если вы хотите работать с другой главой, вы можете checkout новую главу и продолжить писать.

Этот метод предполагает, что у вас будет не более одной активной ветви для каждой главы.

Существует также много возможностей для добавления git alias es и скриптов для автоматизации повторяющихся задач в вашем рабочем процессе. Например, некоторые простые псевдонимы для некоторых из указанных выше задач могут быть:

git config --local alias.new 'checkout production -b'
git config --local alias.updateProduction '!git checkout production; git merge --no-ff'
git config --local alias.publish '!git checkout published; git merge --ff-only production'

И используйте это как:

git new arc-01-chapter-01-typos
# edit chapter 1...
# commit chapter 1...
git updateProduction arc-01-chapter-01-typos
git publish

Что приводит к:

* 856834e (HEAD -> published, production) Merge branch 'arc-01-chapter-01-typos' into production
|\
| * ed6e595 Added better ending to chapter 1
|/
*   c9da9d7 Merge branch 'arc-01-chapter-01-beta' into production
|\
| * a3f9294 Beta revisions for arc 1, chapter 1
|/
*   726e661 Merge branch 'arc-01-chapter-01-draft' into production
|\
| * 29c00f7 Finished draft of arc 1, chapter 1
| * e8cbcd6 First draft of arc 1, chapter 1
|/
* d419ebf (master) Initial commit. Includes table of contents

Я мог бы также показать пример работы над двумя ветками одновременно, но я думаю, что этого достаточно для продолжения. (Или я могу объяснить больше, если это будет необходимо).

A Примечание: автоматически сгенерированные сообщения слияния могут использоваться без запуска редактора с помощью git merge --no-edit. Однако страница руководства git почему-то обескуражила это.

0 голосов
/ 05 сентября 2018

Редактировать

После просмотра вашего комментария и обновленного изображения, я полагаю, возможно, с помощью git-поддерева Google repo. Эти два рабочих процесса немного сложнее стандартного рабочего процесса Git, но позволяют вам хранить отдельные репозитории в одном основном проекте. Вы можете прочитать краткое введение в git поддерево здесь . Google репо может быть немного сложнее, но документация находится здесь .

Примечание: я не использовал ни один рабочий процесс, только сейчас протестировал рабочий поток поддерева

Быстрое изложение поддерева

Main
|
|_chapter1(subtree)
|_chapter2(subtree)


git subtree add --prefix *your directory here* https://*repo address here* master

Это добавит репо в ваш проект с последними коммитами и сохранит историю изменений. Мы можем использовать --squash в конце, чтобы при желании удалить историю из основного проекта.

git subtree pull --prefix *your directory here* https://*repo address here* master

Это обновит поддерево. В статье , на которую я ссылаюсь, объясняется, как все это можно сделать без использования команд поддерева. Спасибо за информацию Никола Паолуччи

Я полагаю, что то, что вы описываете, очень похоже на разработку на основе транков. У вас будет ветвь Release, ветвь ствола и отдельные ветви для глав. Я был совершенно незнаком с веб-сериалами. Я прочитал абзац в Википедии здесь . Как показано на вашей диаграмме, отдельные главы не являются производными от остальных, но я надеюсь, что наличие файлов из проекта в каждой ветви не является проблемой.

Если не проблема включить ранее существующие файлы из всего проекта, этого рабочего процесса должно быть достаточно. Каждый раз, когда вы начинаете работу над одной из глав, вы создаете ветку на стволе. Затем вы вернете его обратно в ствол, когда он будет готов к производству (где вы позволите читателям увидеть завершенный контент).

У вас будет Мастер , затем создайте ветвь Глава 1 , объедините ее в Мастер , затем Мастер и Производство . Затем вы создадите новую ветку Chapter 1 , чтобы редактировать дальнейшие или другие ветви для каждой главы.

Если вы хотите прочитать об этом как о возможном рабочем процессе, вы можете запустить здесь . Эта ссылка имеет визуальное представление для рабочих процессов на основе соединительных линий.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...