Git еквіваленти найпоширеніших команд Mercurial?

Я використовував Mercurial, але хотів би швидко зробити демонстрацію Git.

Які еквіваленти Git:

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-HG непоганий

Між двома, про які там не згадувалося, є ще кілька помилок. Цей список був викладений із мого власного допису в блозі, коли я пішов іншим шляхом (git -> hg).

Hg .hgignore , синтаксис: glob - це та сама поведінка, що і git .gitignore.

Git .git/config , ~/.gitconfigвикористовуйте ГИТ-конфігурації , щоб змінити значення
Hg .hg/hgrc , ~/.hgrcвикористовуйтеhg help -c config

Git git commit -v<br> Hg hg diff | less; hg commit

Git gitk<br> Hg hg view, or thg from [TortoiseHg][1]

Git git gui<br> Hg Mercurial не постачає графічний інтерфейс для вибору наборів змін, лише консольну hg recordкоманду.

Git git rebase<br> Hg hg rebase . Бо git rebase --interactiveіснує hg histedit , або ртутні черги

Git git push URL ; git remote add origin URL<br> Hg hg push URL; $EDITOR .hg/hgrc ; [paths] default = URL

Git gitk, git log origin/master..HEAD<br> Hg hg outgoing

Git git format-patch RANGE<br> Hg hg email -m filename -o

Git git add . ; Зверніть увагу на крапку
Hg hg add ; Крапка не потрібна.

Git git checkout REVISION-KEY<br> Hg hg update CHANGESET

Щоб заповнити порожні місця, деякі найбільш корисні команди від Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Немає реального еквівалента. Ви можете зробити лише еквівалентhg pull; hg log -r .:

Hg hg out URL
Git Будь ласка, додайте, якщо знаєте як.

Для вирішення конфліктів злиття hg resolveкоманда в Mercurial має кілька параметрів, які змінюють поведінку:

Hg hg resolve -m FILE (позначає файл як вирішений шляхом ручного вирішення проблеми конфлікту)
Git git add FILE

Hg hg resolve -u FILE позначає файл як невирішений
Git git reset HEAD FILE для зняття файлу з файлу

Hg hg resolve -l (перелічує файли з вирішеними / невирішеними конфліктами)
Git git status - файли, які об'єднані чисто, додаються до індексу автоматично, ті, що не мають конфліктів

Hg hg resolve FILE (після злиття, спроби повторного злиття файлу)
Git не є еквівалентом повторного злиття, про який я знаю.

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

Від 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

На цьому етапі ваш наступний коміт внесе 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": цифри ...) вписався, у коментарях:

В індексі немає нічого принципово "git-ish", hg міг би використовувати індекс, якщо він вважався цінним, фактично mqабо shelveвже робить частину цього.

О, малюк. Ось ми знову.

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

Індекс насправді є фронтом і центром у тому, як Лінус Торвальдс працює з VCS :

Git використовував явні оновлення індексу з 1-го дня, навіть до того, як здійснив перше злиття. Це просто, як я завжди працював. У мене, як правило, брудні дерева з випадковим патчем у моєму дереві, який я не хочу робити, оскільки це просто оновлення Makefile для наступної версії

Тепер комбінація індексу (що не є поняттям, яке можна побачити лише в Git) і парадигма "content is king" робить його досить унікальним і "git-ish" :

git - це інструмент відстеження вмісту , і ім'я файлу не має значення, якщо воно не пов'язане з його вмістом. Отже, єдиною розумною поведінкою git add ім'я файлу є додавання вмісту файлу, а також його імені до індексу.

Примітка: тут "вміст" визначається таким чином :

Індекс Git в основному визначається як

• достатньо, щоб містити загальний " вміст " дерева (і це включає всі метадані: ім'я файлу, режим і вміст файлу - це всі частини "вмісту", і всі вони самі по собі безглузді! )
• додаткову "статистичну" інформацію, яка дозволяє зробити очевидну та тривіальну (але надзвичайно важливу!) оптимізацію порівняння файлової системи.

Таким чином , ви дійсно повинні побачити індекс , як бути змістом .

Вміст не є "ім'ям файлу" або "вмістом файлу" як окремі частини. Ви насправді не можете розділити ці два .
Назви файлів самі по собі не мають сенсу (вони також повинні мати вміст файлу), а вміст файлів сам по собі також безглуздий (ви повинні знати, як його отримати).

Я намагаюся сказати, що git принципово не дозволяє бачити ім'я файлу без його вмісту. Усе поняття божевільне і не дійсне. Це не має відношення до "реальності".

З часто заданих питань основними перевагами є:

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

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

Хоча ви в цілому праві (щодо "перевіреної або складеної" частини), спосіб, яким Git дозволяє вам розгалужуватись та зливати (збирати вишні або перебазувати), дозволяє вам робити коміти так часто, як ви хочете, у тимчасовій приватній гілці (лише до віддаленого сховища "резервного копіювання"), одночасно виконуючи ці "потворні коміти" у загальнодоступній гілці з усіма правильними тестами.

Меркуріал:

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 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 pulland git pushта пов’язаних команд.