Mercurial:

hg init . # start a project in the current directory
hg addremove # look for any added or deleted files
hg commit -m "comment" # commit any uncomitted changes
hg status # what have i changed since the last commit?

Эквиваленты Git:

git init
git add -A
git commit -am "comment" # -a is not necessary along with the above add -A
git status

Примечание: одно из самых больших различий между Git и Mercurial - это явное присутствие индекса или промежуточной области .

From ] Mercurial для пользователя Git :

Git - единственный DistributedSCM , который раскрывает концепцию индекса или промежуточной области. Другие могут реализовать и скрыть его, но ни в каком другом случае пользователь не знает об этом и не должен иметь с этим дело.

Примерным эквивалентом Mercurial является DirState , который управляет информацией о состоянии рабочей копии для определения файлов. для включения в следующий коммит. Но в любом случае этот файл обрабатывается автоматически.
Кроме того, можно быть более избирательным во время фиксации, указав файлы, которые вы хотите зафиксировать, в командной строке или используя RecordExtension .

Если вам было неудобно работать с индексом, вы переключаются к лучшему; -)

Хитрость в том, что вам действительно нужно понимать индекс, чтобы полностью использовать Git. Как эта статья от мая 2006 г. напоминает нам тогда (и это все еще верно сейчас):

«Если вы отрицаете Индекс, вы действительно отрицаете сам git».

Теперь эта статья содержит много Команды, которые теперь стали проще в использовании (так что не слишком полагайтесь на их содержимое;)), но общая идея остается:

Вы работаете над новой функцией и начинаете вносить незначительные изменения в файл.

# working, add a few lines
$ git add myFile
# working, another minor modification
$ git add myFile

На данном этапе, Но это не часть обычного рабочего процесса для Mercurial.

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

tonfa (в профиле: "Hg dev, pythonist": цифры ...) вмешивается в комментарии:

Нет ничего принципиально "git-ish "в индексе hg могла бы использовать индекс, если бы он считался ценным, на самом деле mq или shelve уже частично в этом участвуют.

О, мальчик. И снова.

Во-первых, я здесь не для того, чтобы один инструмент выглядел лучше другого. Я считаю Hg отличным, очень интуитивно понятным, с хорошей поддержкой (особенно в Windows, моей основной платформе, хотя я также работаю с Linux и Solaris8 или 10).

Индекс фактически является передним и центральным в способе Линус Торвальдс работает с VCS :

Git использовал явные обновления индекса с первого дня, даже до того, как он произвел первое слияние. Я просто так работал всегда. У меня есть грязные деревья с каким-то случайным патчем в моем дереве, который я не хочу зафиксировать, потому что это просто обновление Makefile для следующей версии

Теперь комбинация индекса (что характерно не только для Git), и парадигма «контент - король» делает его довольно уникальным и «мерзким» :

git является трекером контента , и имя файла не имеет значения, если оно не связано с его содержимым. Следовательно, единственное разумное поведение для git add filename - добавить содержимое файла, а также его имя в индекс.

Примечание: «контент» здесь определяется следующим образом :

Индекс Git в основном определяется как

• , достаточный для того, чтобы содержать общий « контент "дерева (и это включает в себя все метаданные: имя файла, режим и содержимое файла - все это части " содержимого ", и все они сами по себе бессмысленны! ])
• дополнительная «статическая» информация, позволяющая очевидные и тривиальные (но чрезвычайно важные!) Оптимизации сравнения файловых систем.

Так что вам действительно следует увидеть индекс как , являющийся содержанием .

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

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

Из FAQ , основные преимущества:

• фиксация с высокой степенью детализации
• поможет вам сохранить незавершенные модификации в вашем дереве на некоторое время. достаточно долгое время
• выполнить несколько небольших шагов для одной фиксации, проверить, что вы сделали, с помощью git diff , и подтвердить каждый маленький шаг с помощью git add или git add -u .
• позволяет превосходно управлять конфликтами слияния: git diff --base , git diff --ours , git diff --theirs .
• позволяет git commit --amend изменять только сообщение журнала, если индекс за это время не был изменен

Я лично считаю, что это поведение не должно быть по умолчанию, вы хотите, чтобы люди для фиксации чего-то, что протестировано или хотя бы скомпилировано

. Хотя вы в целом правы (насчет «протестированной или скомпилированной» части), способ, которым Git позволяет выполнять ветвление и слияние (выбор вишни или ребазирование), позволяет вам фиксировать так часто, как вы хотите, во временной частной ветке (помещенной только в удаленный «резервный» репозиторий), повторяя эти «уродливые коммиты» в публичной ветке со всеми необходимыми тестами.

Это примерно то же самое, без addremove:

git init # Start a project in the current directory
git status # Displays both changes and added/removed files
git commit -m "comment" # commit any uncommited changes

Однако это команды, которые вы бы использовали при работе в одиночку. Вы попадаете в изящные вещи, когда хотите объединить свои изменения с работой других людей с помощью git pull и git push и связанных команд.