checkins должен быть небольшими шагами или полными функциями?
Слабое свойство становится равным нулю, как только нет других сильных ссылок на значение, которое оно имеет.
Таким образом, у вас слабое свойство содержит единственную ссылку на экземпляр альбома, и оно сразу становится нулевым после присвоения.
Исправление будет зависеть от способа использования / создания ваших данных. Если альбом хранит ссылки на его песни, тогда вы должны сначала создать и сохранить альбомный объект, а затем использовать его для инициализации своих песен. Если у альбома нет ссылок на его песни (что, вероятно, было бы странно), тогда вы можете просто сделать переменную альбома сильной.
7 ответов
Прелесть систем DVCS в том, что вы можете иметь оба , потому что в DVCS, в отличие от CVCS, публикация ортогонален фиксации . В CVCS каждый коммит публикуется автоматически, но в DVCS коммиты публикуются только тогда, когда они отправлены .
Итак, совершают небольшие шаги, но только публикуют рабочие функции.
Если вас беспокоит загрязнение вашей истории, вы можете ее переписать. Возможно, вы слышали, что переписывать историю - зло, но это неправда: зло только переписывать опубликованную историю, но, опять же, поскольку публикация и фиксация отличаются, вы можете переписать свою неопубликованную историю перед ее публикацией.
Так, например, работает разработка под Linux. Линус Торвальдс очень озабочен сохранением истории в чистоте. В одном из самых ранних электронных писем о Git он сказал, что опубликованная история должна выглядеть не так, как вы на самом деле ее разработали, а как вы разработали ее , если бы вы были всеведущ, умел заглядывать в будущее и никогда не делал ошибок.
Linux немного особенный: в нем совершается одна фиксация каждые 11 минут в течение 24 часов в сутки, 7 дней в неделю, 365 дней в году, включая ночи, выходные, праздники и естественные праздники. бедствия. И этот показатель продолжает расти. Только представьте, насколько больше было бы коммитов, если бы каждая отдельная опечатка и мозговые перья тоже приводили к фиксации.
Но сами разработчики делают коммиты в своих частных репозиториях так часто, как захотят.
Так что же делать разработчику? Отметить маленькие шаги или полные функции?
Можно получить лучшее из обоих миров, особенно с git и другими DVCS, которые позволяют вам выбирать, какую историю публиковать. Вот простой рабочий процесс, который иллюстрирует это.
-
Ваш проект имеет master и релиз ответвлений. Каждый разработчик поддерживает свои собственные развивающие ветви, которые они не продвигают.
-
Вы используете Develop , чтобы выполнять свою повседневную работу. Здесь появляются коммиты размером с укус, отражающие постепенные изменения состояния проекта с течением времени. Вы можете создать ветку topic - * для работы с более длинными функциями, которые охватывают более нескольких дней, или крупными рефакторингами. Вы обязуетесь развивать очень часто, возможно, несколько раз в час. Это как нажать «Сохранить» в редактируемом документе.
-
Когда у вас есть некоторые коммиты, подходящие для следующего выпуска, вы объединяете соответствующие коммиты с выпуском . релиз теперь содержит несколько отдельных коммитов, которые были выборочно взяты из вашей ветки Develop . Вы обязуетесь выпускать всякий раз, когда вы достигаете хорошей точки остановки. Обычно это несколько раз в день.
-
Когда релиз готов к работе, ваш ведущий разработчик объединяет все коммиты с момента последнего слияния с master в один коммит слияния, который появляется на мастер [+1137]. Затем вы помечаете этот коммит идентификатором релиза (например, v.1.0.4). Это случается нечасто, возможно, один раз итерация или каждые несколько недель.
Здесь вы получите свой торт и съесть его тоже. Перед выпуском вы можете откатить изменения, которые не должны были произойти или которые вы не хотите включать в выпуск, и вы можете сделать это по одному за раз. Разработчик удобно! Но пользователи тоже получают то, что хотят: большие, потертые коммиты на master , которые представляют то, что изменилось со времени последнего выпуска.
Маленькие шаги. Есть причина, по которой это называется контроль версий , а не контроль релизов :)
Фиксируйте так часто, как вам нравится. Не сдерживайся. Не должно быть негативных последствий для фиксации кода в ветке «в процессе». Магазины разработки, которые ожидают, что не "сломают сборку", неправильно используют RCS. Аналогично, приписывать любое значение какого-либо коммита является опасной политикой просто потому, что она вступает в противоречие с целью контроля версий. Вместо этого значение должно быть приписано тегам, ветвям, клонам, тайникам или тому, как их называет RCS. Эти вещи имеют метаданные (возможно, такие же минимальные, как имя ), предназначенные для передачи цели. Изменения - это просто история того, что вы изменили.
Последнее, что вы хотите сделать, - это ввести политику, запрещающую разработчикам вводить свой код по любой причине.
Я рекомендую создать ветку или даже отдельный репозиторий для экспериментов. Затем, как только функция будет завершена, вы можете объединить код из ветви обратно в основную часть кода. Надеюсь, это позволит вам получить лучшее из обоих миров.
Одна вещь, которая мне действительно нравится в Git, это то, что репо у твоего разработчика. среда это ваше РЕПО. Это копия репозитория сопровождающего. Вы свободны делать все, что захотите, в этом репо, и вы не будете отмечать сопровождающего, если не добавите несколько сумасшедших историй.
Для этого используйте ветвление и слияние в своих интересах настолько, насколько это возможно, чтобы помочь в развитии и экспериментах. Нажимайте только те изменения, которые вам наиболее удобны. Git даже дает вам возможность разделить историю ваших коммитов на меньшее количество наборов изменений, если это необходимо, чтобы вы могли перенести серию коммитов, которые вы выполнили, в один коммит.
Гибкость чрезвычайно расширяет возможности вашего личного рабочего процесса, а также политики ваших коллег.
Маленькие шаги действительно хороши. Вы всегда можете объединить их в более крупные шаги в другом репо. Чтобы сделать обратное, вы должны «переписать историю», что может быть сделано в некоторых системах (особенно git), но это не так хорошо поддерживается, как вам хотелось бы.
Еще одна причина, по которой мне нравятся маленькие шаги, заключается в том, что мои коллеги могут легко увидеть, что я сделал. Если я работаю в течение трех или четырех часов, для меня гораздо более разумным будет откатить полдюжины коммитов, чтобы мои коллеги могли видеть соответствующие различия. (И я ценю то, что они оказывают мне такую же любезность.)
Наконец, маленькие шаги снижают вероятность возникновения конфликтов или того, что когда вы это сделаете, они будут меньше.
Я использую маленькие шаги, даже когда работаю один, на нескольких ветвях.
Резюме: Для ежедневного рабочего процесса небольшие шаги имеют много преимуществ. Если вам нужен рабочий процесс, ориентированный на распространение, создайте репозиторий и филиал только для распространения, и вы можете настроить свои большие шаги именно так, как вы этого хотите.
Большую часть времени я могу сойти со следующего эмпирического правила - проверять наименьшее количество за раз, которое имеет смысл (и все же быть полезным или улучшением). Я считаю, что это помогает мне лучше планировать свою работу, которая имеет несколько преимуществ, включая (но не ограничиваясь) ...
- Лучшие оценки развития.
- Лучшие тестовые оценки.
- Более быстрое время разработки.
- Меньше общих ошибок.
- Меньше связи между модулями.
- Раньше выяснялось, неумышленно ли мой код что-то сломал.
- и многое другое
Бывают случаи, когда необходимо создать ветвь, а затем, когда работа завершена, объединить ее обратно с основной линией. Однако, работая над веткой, я все еще пытаюсь следовать правилу, поскольку оно автоматически отменяет все эти преимущества.
Надеюсь, это поможет.