Реализация тегов в стиле CVS в git

Я столкнулся со странным вопросом, который я не могу ответить сам, несмотря на то, что я долгое время работал с git.Реализация тегов в стиле CVS в git

Процесс требует отметки одного файла в git, когда это будет считаться готовой продукцией. Когда другие файлы становятся «готовыми», их тоже нужно «помечать». Файл с тегами сначала может измениться до этого момента, но мы все равно должны иметь возможность одновременно извлекать все готовые файлы.

Было бы работать, если можно пометить один файл в commit, но это не так.

Не могли бы вы дать мне какую-либо подсказку, обходной путь, как я мог бы это сделать: получить несколько файлов в нескольких коммитах, связанных друг с другом единым критерием?

источник

2013-02-21 shytikov

Это звучит так, как будто кто-то с фоном CVS проектировал рабочий процесс (где вы применяете теги по отдельности к каждому файлу при определенных версиях). 'git' не работает, но тег применяется к определенному коммиту, что подразумевает конкретное состояние для каждого файла в проекте. Вы можете применить тег к отдельному файлу, но только к одному файлу - вам понадобятся другие теги для каждого отдельного файла, который быстро станет неуправляемым, я думаю ... – twalberg

Вы правы, рабочий процесс был разработан одним из старых и, несмотря на то, что мне нужно хотя бы попытаться реализовать его ... – shytikov

Я вынужден сделать это без смысла на работе, а также по другим причинам. Официальным инструментом рабочего места является устаревший программный пакет, который очень похож на CVS. Я неофициально использую 'git' для всех своих разработчиков, и он держит все красивым и аккуратным. Проблема в том, что для того, чтобы поддерживать верхнюю часть, мне все равно нужно внести изменения в более старую систему. После того, как я зарегистрирую набор изменений, я буду отмечать (тегировать) все эти конкретные файлы (и те конкретные версии) с идентификатором SHA git commit. Это позволяет мне относиться к старой системе так же, как если бы она была git. Выполнение метки 'Get' по методу ~ = для фиксации. – g19fanatic

Спасибо за гибкость git, мы нашли ответ! Решение имеет свои недостатки, но оно работает.

Идея проста. Все изменения production-ready будут отслежены в отдельной ветке, и файлы появятся там не через слияние с веткой развития, а путем проверки только необходимых файлов из него.

Несмотря на то, что мы теряем всю предысторию production-ready, мы получим чистый и простой способ получить все файлы production-ready за один раз.

В нашей защите я могу добавить, что эту проблему можно было бы выровнять, добавив в сообщение фиксации сообщение pre-production идентификатор филиала, из которого был извлечен файл. И также можно упростить процесс, извиняя простую команду git, которая будет выполнять ряд необходимых команд.

Эти команды:

git checkout pre-production

, чтобы переключиться на pre-production ветви.

git checkout development file/name

в чекаут нужный файл из development филиала.

git commit -m "Moving file/name to pre-production from commit id 5364afb23"

передать и наметить движение.

источник

2013-02-24 11:10:12 shytikov

Как вы знаете, что вам не хватает некоторых файлов? –

Это похоже на вопрос, как я узнаю, не пропустил ли я «пометить» некоторые файлы или нет? Когда я 'tagging' файл будет 'pre-production'-ready, я перемещаю его в другую ветку. Если я пропустил эту операцию, я нарушил рабочий процесс. Проблема здесь в том, что рабочий процесс уже нарушен - мне нужно разложить репозиторий с помощью такой маркировки, вместо использования стандартных защищенных тегов 'git'. – shytikov

Этот рабочий процесс - это просто FUBAR ... Что вам нужно сделать, так это создать ветвь 'release' из ветви' development', использовать простой текстовый файл, чтобы отслеживать, какие файлы готовы и объединить все изменения в ветви 'release' вернуться в «развитие». Как только ветвь 'release' будет закончена, пометьте ее и создайте из нее ветвь' maintenance'. –

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

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

источник

2013-02-21 17:00:43 hlovdal

Означает ли это, что у меня должен быть только один файл на предмет фиксации, предназначенный для выбора вишни? – shytikov

Да, наверное. – hlovdal

По вашему запросу

Сделайте свою разработку программного обеспечения с использованием мерзавца. Сделайте нормальный процесс добавления новых изменений в индекс и отправьте их в свой репозиторий по мере необходимости.

В конце дня вы захотите сделать верхушки счастливыми и зарегистрировать всю свою текущую работу в другой системе CM. Проблема в том, что эта система требует, чтобы вы пометили/маркировали каждый файл вместо «набора» файлов. Вы можете справиться с этой проблемой, пометив все файлы продукта, находящегося в старой CM-системе, сразу после регистрации с тегом, который соответствует хэшу SHAID соответствующего git-commit (достижимый, набрав git log).

Это позволяет вам иметь одну-единственную запись для набора файлов, которые соответствуют конкретной фиксации git.

источник

2013-02-22 11:06:30 g19fanatic

Реализация тегов в стиле CVS в git

ответ

Смежные вопросы