Git Branches для учебных пособий

Question

, поэтому я пытаюсь определить, является ли этот рабочий процесс идеальным и как решить общую проблему с ним. В настоящее время у меня есть завершенный проект в моей основной ветке git repo. Теперь мне нужно сделать сегмент этого проекта в 20 "главах". Каждая глава представляет собой некоторый прогресс, который берет меня с совершенно пустым проектом в главе 1 до полного проекта в настоящее время я имею в главе 20. В идеале, ветвь Репо бы:

Мастер Chapter1 ... Chapter20 (который аналогичен Мастеру в том, что проект завершен)

Это похоже на разумный способ его структурирования? Кроме того, по мере внесения изменений, я хотел бы знать, как сделать общую фиксацию для всех филиалов в случае, если я что-то забуду. Например, если в главе 10 я понимаю, что я пропустил то, что должно было существовать в главе 2. Я могу вернуться и добавить его в главу 2, но затем я хотел бы, чтобы она добавилась к 3-10, чтобы представить, что изменение было там все время. Это возможно?

Спасибо

Answer 1

Если вы хотите придерживаться ветки для каждой главы, то ваш подход возможен. Это зависит от ваших фактических потребностей и структуры документа/проекта. Но если вы измените sth. в (филиал) «chapter2» вы должны объединить его во всех последующих главах (дочерние ветви), т.е.

git checkout chapter2; 
# edit chapter2.txt, git add, git commit 
git checkout chapter3; git merge chapter2; 
git checkout chapter4; git merge chapter3; 
... 
git checkout chapter20; git merge chapter19; 

---

Update: Если вы хотите, чтобы ваши главы полностью независимы друг от друга, вы можете также использовать git's octopus merge. Это слияние более чем одной ветви в текущую. Из того, что вы описали, я бы не рекомендовал его, но просто показать вам:

Вы бы тогда 20 филиалов chapter1 ... chapter20 которые не зависят друг от друга, т.е. chapter2 является не «chapter1 + редактирует ", это только глава2. Каждая ветвь обрабатывает (и видит) только свою собственную главу, ничего больше. Затем, когда вы хотите, чтобы выпустить новую книгу, вы могли бы сделать

git checkout master 
git merge chapter1 chapter2 chapter3 ... chapter20 

Филиал мастер затем слияние всех глав. Это приводит к смешным фотографиям в gitk, таким образом, имя осьминога ;-)

Недостаток является то, branchX не может зависеть от каких-либо изменений в других отраслях. Как сказано, это зависит от ситуации, если это имеет смысл для вас.

Answer 2

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

Answer 3

Похоже, что tags будет более уместным, чем branches. https://softwareengineering.stackexchange.com/questions/165725/git-branching-and-tagging-best-practices может предоставить вам некоторое представление. Первоначально я задавал это с точки зрения профессионального проекта, но я думаю, что одни и те же идеи одинаково применимы к учебнику.