Примечание: одно из самых больших различий между Git и Mercurial заключается в явном присутствии index или области подготовки .
С Mercurial для Git User :
Git является единственным DistributedSCM , который раскрывает понятие индекса или промежуточной области. Другие могут реализовать и скрыть это, но ни в каком другом случае пользователь не знает и не должен иметь дело с этим.
Грубым эквивалентом Mercurial является DirState, который управляет информацией о состоянии рабочей копии для определения файлов, которые будут включены в следующий коммит. Но в любом случае этот файл обрабатывается автоматически.
Кроме того, можно быть более избирательным во время фиксации, либо указав файлы, которые вы хотите зафиксировать в командной строке, либо используя RecordExtension.
Если вам неудобно работать с индексом, вы переходите к лучшему; -)
Хитрость в том, что вам действительно нужно понимать индекс, чтобы полностью использовать Git. Как эта статья за май 2006 года напоминает нам тогда (и это все еще верно сейчас):
«Если вы отрицаете Индекс, вы действительно отрицаете сам мерзавец».
Теперь эта статья содержит много команд, которые теперь проще в использовании (поэтому не слишком полагайтесь на ее содержимое;)), но общая идея остается:
Вы работаете над новой функцией и начинаете вносить незначительные изменения в файл.
# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile
На этом этапе ваш следующий коммит внесет 2 незначительные модификации в текущую ветку
# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work
$ git commit
Записывает только изменения, добавленные в промежуточную область (индекс) на данный момент, а не основные изменения, которые в настоящее время видны в вашем рабочем каталоге.
$ git branch newFeature_Branch
$ git add myFile
В следующем коммите будут записаны все другие важные изменения в новой ветке 'newFrature_Branch'.
Теперь добавление в интерактивном режиме или даже разделение коммита - это функции, доступные в Mercurial с помощью команды hg record или других расширений: вам необходимо установить RecordExtension или CrecordExtension.
Но это не является частью нормального рабочего процесса для Mercurial.
Git рассматривает коммит как серию « содержимого файла изменений», и позволяет вам добавлять эти изменения по одному.
Вы должны изучить эту особенность и ее последствия: Большая часть силы Git (например, способность легко отменить слияние (или разделить задачу, или отменить коммит) , вопреки Mercurial ) исходит из этой парадигмы «содержимое файла».
tonfa (в профиле: "Hg dev, pythonist": цифры ...) включили, в комментариях:
В индексе нет ничего по сути "мерзавца", hg может использовать индекс, если он считается ценным, на самом деле mq или shelve уже делают часть этого.
О, мальчик. Здесь мы идем снова.
Во-первых, я здесь не для того, чтобы один инструмент выглядел лучше другого. Я нахожу Hg отличным, очень интуитивно понятным, с хорошей поддержкой (особенно на Windows, моей основной платформе, хотя я работаю на Linux и Solaris8 или 10 тоже).
Индекс на самом деле находится спереди и по центру в пути Линус Торвальдс работает с VCS :
Git использовал явные обновления индекса с первого дня, даже до первого слияния. Это просто, как я всегда работал. У меня, как правило, грязные деревья, с некоторым случайным патчем в моем дереве, который я не хочу зафиксировать, потому что это просто обновление Makefile для следующей версии
Теперь комбинация индекса (что не встречается только в Git), и парадигма «контент - король» делает ее довольно уникальной и ГИТ-иш "
git - это средство отслеживания содержимого , и имя файла не имеет значения, если оно не связано с его содержимым. Следовательно, единственное вменяемое поведение для git add filename - это добавление содержимого индекса и его имени в индекс.
Примечание: «содержание» здесь определяется следующим образом :
Индекс Git в основном очень определяется как
- достаточно, чтобы содержать общее " содержимое " дерева (и это включает все метаданные: имя файла, режим и содержимое файла - все части из «содержание», и все они сами по себе бессмысленны! )
- дополнительная информация "stat" для очевидной и тривиальной (но чрезвычайно важной!) Оптимизации сравнения файловой системы.
Так что вы действительно должны видеть индекс как , являющийся содержимым .
Контент не является «именем файла» или «контентом файла» как отдельные части. Вы действительно не можете разделить два .
Имена файлов сами по себе не имеют смысла (они тоже должны иметь содержимое файла), а содержимое файла само по себе также бессмысленно (вы должны знать, как его достичь).
Я пытаюсь сказать, что git принципиально не позволяет вам видеть имя файла без его содержимого. Все понятие безумно и не действует. Это не имеет отношения к «реальности».
С FAQ , основными преимуществами являются:
- коммит с мелкой гранулярностью
- поможет вам сохранить незафиксированные изменения в вашем дереве в течение достаточно длительного времени
- выполните несколько небольших шагов для одного коммита, проверив, что вы сделали с
git diff, и подтвердите каждый маленький шаг с помощью git add или git add -u.
- позволяет отлично управлять конфликтами слияния:
git diff --base, git diff --ours, git diff --theirs.
- позволяет
git commit --amend изменять только сообщение журнала, если за это время индекс не был изменен
Лично я считаю, что такое поведение не должно быть по умолчанию, вы хотите, чтобы люди совершали что-то проверенное или хотя бы скомпилированное
Хотя в целом вы правы (в отношении "протестированной или скомпилированной" части), способ, которым Git позволяет вам выполнять ветвление и слияние (выбор вишни или перебазирование), позволяет фиксировать так часто, как вы хотите, во временной частной ветке. (выдвигается только в удаленный «резервный» репозиторий), при этом повторяя эти «уродливые коммиты» в публичной ветке со всеми правильными тестами на месте.