Я решил начать использовать систему контроля версий Git для моего проекта C ++. Я новичок в управлении версиями. Для ствола все просто, я просто фиксирую все версии проекта, которые у меня есть. Я держал каждую версию в отдельной папке, потому что знал, что очень скоро буду использовать Git. Но я столкнулся с проблемой с моими ветками.
На каком-то этапе разработки я решил, что есть один класс, который я хочу развивать в отрасли. Без контроля версий мне пришлось бы использовать «ручную» ветку. Я скопировал самый последний заголовочный файл и исходный файл этого класса в отдельную папку и начал там работать. Я сделал там несколько версий для работы одновременно. Одна версия была первым прототипом класса по плану (для которого я сделал «ветку»). Затем я добавил другой файл, в который я скопировал первый, но удалил вещи, которые, как мне казалось, не нужны. Таким образом, у меня есть 2 версии, одна со всеми моими идеями и функциями, другая с тем, что я действительно использую в своем коде, без того, что не используется в данный момент.
Но потом я добавил еще. По мере развития я решил, что может быть хорошей идеей сделать этот класс шаблоном. Поэтому я добавил третью версию, которая похожа на вторую, но теперь некоторые функциональные возможности, реализованные с использованием полиморфизма, реализованы с использованием шаблона. И я пока не могу сказать, какая версия лучшая, так как пока рано говорить, поэтому я хочу собрать все три вместе.
Затем я сделал еще один специальный файл: копию файла заголовка третьей версии, в котором каждая строка может быть помечена или не помечена. Помечено означает, что я использую этот конкретный метод, или я уверен, что он будет использоваться очень скоро, иначе строка не будет помечена.
Затем, через некоторое время, я открыл новую ветку. И для этой ветки мне нужна была новая версия этого класса, разработанная в первой ветке. Поэтому я просто скопировал одну из версий в папку новой ветки и начал там работать. Теперь снова у меня был какой-то вспомогательный файл: у меня было 2 файла, один из которых я удаляю методы класса, которые я использую, и один, в который я пишу новые методы, которые мне нужны.
Теперь я хочу начать использовать Git и задаюсь вопросом: для всех текстовых файлов проекта, планов, диаграмм и т. Д. Это очевидно — я оставляю их вне репозитория Git. Всякий раз, когда требуется совместное редактирование, я могу создать вики или что-то в этом роде. Но что делать с ними для всех этих копий одного и того же заголовочного файла и для этих вспомогательных «помеченных» файлов? Я имею в виду, это нормально для меня, чтобы они все в ветке, но что произойдет, когда я сливаю ветку в ствол? Я не хочу иметь все эти копии, версии и списки, только один последний файл класса, который я сделал.
С одной стороны, это исходные файлы C ++, используемые при кодировании. С другой стороны, они не являются частью чистого исходного кода пакета программного обеспечения, они просто помогают мне, пока я работаю, но никогда не будут скомпилированы, потому что в итоге есть только окончательная версия класса, которую я выбрал для слияния, и все остальные вспомогательные файлы, списки и т. д. хранятся только для справки.
Что было бы лучше всего сделать?
Спасибо за чтение моей длинной истории 🙂
РЕДАКТИРОВАТЬ: Это локальный репо на моем персональном компьютере
То, что вы описываете, — это обычное использование веток: у вас есть основная ветка («официальная», если она есть) и ветка для разработки новой функции (ей не обязательно жить в отдельном каталоге, если я вас понимаю правильно). Периодически вы синхронизируете ветвь объекта с мастером, либо перебирая его на мастере, либо объединяя его изменения. В свою очередь, вы можете иметь подчиненные ветви, в которых вы пробуете подходы к разработке функции, обработанные по отношению к функции. филиал просто так уважать к мастеру. Но в этом случае вы должны быть осторожны, когда вы перебазируете.
Вы должны хранить любые данные, которые нелегко воссоздать в хранилище, будь то исходный код, документация или даже эскизы проекта. Материал, который можно воссоздать (объектный код, автоматически оформленная документация и т. Д.), Следует не пускать (любое изменение в нем создаст разницу, подлежащую регистрации). Ваш репозиторий (особенно не опубликованные ветки) — это ваше собственное рабочее пространство, в нем может быть все, что вам нравится.
Взгляните на книгу, упомянутую на git homepage.
Всегда храните документацию в том же хранилище, что и исходный код. Если вы этого не сделаете, ваша документация сгниет. Это потому, что документация написана против некоторой версии вашего программного обеспечения, поэтому она должна развиваться так же, как и программное обеспечение.
Если ваша документация автоматически сгенерирована или скомпилирована в другой формат, передайте только исходные данные, make-файл и конфигурацию генератора, как вы делаете это с исходным кодом.
Ну, это явно документация, а не исходный код, поэтому вы должны отделить его от исходного кода. Поскольку ваша документация кажется зависимой от ветки, вы все равно должны проверить ее в репозитории, но в отдельном doc
каталог.
О слиянии: как работает слияние, зависит только от вас. У Git просто есть стратегия слияния по умолчанию, которую большинство людей хотят в большинстве случаев. Но если вы говорите, что слияние с основной веткой должно просто принести код, а не документ, то это нормально. Просто слить таким образом:
git merge mybranch --no-commit
rm -rf **docu-dir**
git add -A
git commit