Git Staging: когда ставить? Что делать, если после этого произошла модификация

Я довольно новичок в широком мире Git. Я прочитал руководство и тренировался, но меня смущают некоторые его аспекты, которые я не смог выяснить после поиска.

Я задаюсь вопросом:

• В проекте (после первой фиксации), когда подходящий момент для создания исходных файлов? Прямо перед совершением? Сразу после добавления / удаления или изменения?

• Если файлы размещаются на полпути между двумя коммитами, а затем они модифицируются, что происходит с Git? Нужно ли заботиться об изменениях контента, когда это было заявлено, и с чем это стало?

• Если я создаю новый файл, ставлю его и затем хочу удалить, почему Git просит меня использовать флаг "-f", а простой файл "git -rm file.ext" не будет работать?

Я прочитал «Что такое стадия» и другие предметы из руководства и других руководств по Git, но, как я уже сказал, я все еще не понимаю вышеизложенного.

Так что, если вы могли бы, пожалуйста, ответьте на вопросы своими словами и примерами, чтобы у меня был лучший шанс понять это.

Спасибо.

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

диверсия

В Subversion вы можете выбрать для фиксации определенных файлов вашей рабочей копии. Но только полные файлы. Теперь: Что делать, если вы хотите подготовить файл A, а не файл B, и части файла, Cкоторые относятся к файлу, Aно не части, которые зависят от изменений в файле B(с тех пор у вас возникнут проблемы с согласованностью фиксации).

Гит

Git решает эту проблему, предоставляя постановку в качестве второй рабочей копии. В области подготовки вы создаете снимок, который вы будете делать (грубо говоря).

Поэтому в области подготовки вы можете создать моментальный снимок, который включает изменения Aи версию файла, Cкоторая отражает только изменения A.

Для конкретных вопросов

• Вы можете поставить в любой момент вы хотите. Я лично предпочитаю ставить прямо перед тем, как запустить коммит.

• При наличии изменений в подготовленном файле и последующем изменении этого файла в рабочей копии вы, конечно, не изменили подготовленный файл. Вы можете либо решить, ставить ли их также, либо нет, ставить эти изменения. Т.е., если вы запустите, git gui citoolвы увидите различия поэтапной и неустановленной версий (хорошие и простые инструменты для поэтапной постановки и фиксации).

• Git здесь осторожен, что, наверное, хорошо.

Общая стратегия коммитов: гранулярные коммиты

Я думаю, когда я говорю о вопросе «Когда я должен выступить», нужно также говорить о коммитах.

Централизованный VCS

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

Гит

В Git фиксация выполняется локально, только их публикация на сервере делает их общедоступными. Поэтому коммит в некотором смысле дешев . Коммит в смысле подрывной деятельности довольно сравним с несколькими, git commitза которыми следует git push. Эта разница имеет значение.

Git позволяет вам фиксировать отдельные строки кода, даже если вы изменили и другие строки в том же файле. Это дает вам много преимуществ, поскольку вы можете, например, зафиксировать исправление безопасности в строке 100, изменив строки 300-350, добавив новую функцию.

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

Итак, где же «контроль качества» и гарантия сборки в коммите, которого ожидает пользователь subversion? Он перенесен на другие действия в git. Вы по-прежнему хотите отправить работающее состояние программы в публичный репозиторий. Поэтому вы должны убедиться, что тесты пройдены успешно, и программа работает, прежде чем выложить свои изменения.

Также постарайтесь максимально использовать ветки. При внесении множества небольших изменений вы получите довольно большую историю версий. Если вы работаете в ветвях, вы можете классифицировать эти гранулированные коммиты по имени ветки и затем объединить их обратно (опция --no-ffтакже сохранит, что эти функции жили в уникальной ветке).

Т.е. вы можете сохранить привычку слияния с masterветкой только, если ветка в хорошем состоянии. Вы также можете использовать теги для отслеживания этапов и выпусков.

Теперь вернемся к постановке. После того, как вы зафиксируете несколько строк на коммит, вы начнете ставить непосредственно перед коммитом. (По крайней мере, так я это делаю).

Я думаю, вы относитесь к этому слишком серьезно. Постановка - это просто выбор материала, который вы хотите включить в следующий коммит. Это очень редко важно, когда или как вы делаете постановку; и если у вас есть много поэтапных и не поэтапных изменений в любой момент, вам, вероятно, нужно пересмотреть процесс разработки.

В проекте (после первой фиксации), когда подходящий момент для создания исходных файлов? Прямо перед совершением? Сразу после добавления / удаления или изменения?

Я обычно делаю это прямо перед фиксацией (если я не замечаю опечатку, поэтому я должен сделать поправку в последний момент и поставить ее тоже). Процесс следующий: редактирование, запуск тестов, этап, фиксация. Если вы приступите к тестированию, скорее всего, тесты не пройдут, и вам придется вносить изменения и ставить их тоже, так почему бы не оставить их до момента фиксации?

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

Он покажет разницу между текущим состоянием репо и (последний коммит + поэтапные изменения). Когда вы вносите некоторые новые изменения, он просто пересчитывает состояние (последний коммит + поэтапные изменения).

Если я создаю новый файл, ставлю его и затем хочу удалить, почему Git просит меня использовать флаг "-f", а простой файл "git -rm file.ext" не будет работать?

Теперь я угадываю здесь, но это, вероятно, потому что поэтапная информация может быть важна (иначе вы бы не ставили ее), но она еще не находится под контролем версии (как файл, который вы можете удалить git -rm). Поэтому gitхочу убедиться, что вы знаете, что делаете.