Получение Git-концепции "этап"
Все еще с трудом справляюсь с концепцией постановки в применении к Git.
Можно ли провести аналогии с SVN? Какова основная цель наличия уровня в Git?
3 ответа
сходства:
Файлы, которые должны быть частью репозитория, должны быть добавлены для отслеживания. Оба инструмента используют add Команда для достижения этой цели. Добавление файлов означает подготовку коммита.
Отличия:
Git допускает некоторые дополнительные детализации при добавлении файлов. Вы можете добавить целый файл или отдельные строки кода. Добавление файлов в индекс или на сцену обеспечивает большую гибкость. SVN автоматически фиксирует все изменения в файле, который уже был добавлен в хранилище. Git оставляет решение о том, какие изменения связать с каждой операцией фиксации, пользователю. Другими словами: следующий коммит в Git содержит только те изменения (строки или файлы), которые были размещены, независимо от статуса отслеживания файлов. SVN автоматически включает все изменения в отслеживаемых файлах.
Дополнительная информация:
Попробуйте прочитать некоторые сообщения, описывающие рабочие процессы Git, такие как сообщение от Оливера Стила. Но имейте в виду, что не существует одного способа использовать Git - их много. Если вы хотите, вы можете использовать Git, как если бы вы работали с SVN.
Не ждите, чтобы понять философию Git в течение короткого периода времени. Мне потребовался год, чтобы понять это, и я все еще изучаю новые способы его использования. Я думаю, что это еще сложнее, если вы выросли с SVN мышлением. Там множество материалов: статьи, видео, ... - не торопитесь и попробуйте некоторые из них. Вот выбор из списка, который я собрал.
Основным преимуществом промежуточной области является то, что вы можете легко зафиксировать только часть изменений в данном файле. (С помощью git add -p например.) Насколько я знаю, единственный способ сделать "частичный" коммит в SVN - это на уровне файлов или вручную создать резервную копию файла, а затем временно отменить изменения, которые вы не хотите фиксировать,
Это замечательно, если (как и я) вы не высокоорганизованный разработчик и хотите иметь возможность сортировать изменения в "аккуратные" коммиты после факта. Это соответствует общему подходу Git, заключающемуся в том, что вы предпочитаете предоставить вам гибкость по сравнению со строгостью. Если вам это не нужно, вы всегда можете просто не использовать его, а использовать git commit -a ...,
Нет никаких аналогий с SVN, потому что SVN не является Git и не имеет такой концепции.
Вот некоторые из сценариев, которые показывают полезность постановки:
Вы работаете над определенной частью и внесли несколько изменений в свой проект. Вы не хотите совершать их еще до того, как полностью протестируете их. Но эти изменения часто могут быть достаточно независимыми, чтобы сделать несколько логических коммитов, чем один большой. Это когда вы ставите отдельные части и делаете несколько коммитов.
Постановка была особенно полезна при отладке. Вы можете разбросать по операторам журнала, чтобы отследить источник ошибки. Затем вы делаете исправление и тестируете снова, используя эти операторы журнала. Но затем вы хотите зафиксировать исправление, прежде чем вносить какие-либо изменения в код, чтобы удалить эти операторы журнала.
Другой сценарий, в котором это оказалось полезным, - это когда вы делаете что-то и находите что-то не связанное, например, ошибку опечатки, которую хотите исправить, и быстро устраните ее.
Есть несколько других таких сценариев, и, вероятно, вы не сможете работать с чем-то, что лишено этой концепции, если вы овладеете им:).
PS: я вообще не использовал SVN, поэтому не могу сделать сравнения между ними.