Git setara dengan perintah Mercurial yang paling umum?

Saya telah menggunakan Mercurial tetapi ingin melakukan demo singkat tentang Git.

Apa padanan Git dari:

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?

Batu rosetta Git-HG lumayan

Ada beberapa gotcha lain di antara keduanya yang tidak disebutkan di sana. Daftar ini diambil dari posting blog saya sendiri ketika saya pergi ke arah lain (git -> hg).

Hg .hgignore , sintaks: glob adalah perilaku yang sama seperti .gitignore git.

Git .git/config , ~/.gitconfig, penggunaan git-config untuk memodifikasi nilai-nilai
Hg .hg/hgrc , ~/.hgrc, penggunaanhg 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 tidak mengirimkan GUI untuk memilih set perubahan, hanya hg recordperintah konsol .

Git git rebase<br> Hg hg rebase . Untuk git rebase --interactiveada histedit hg , atau Mercurial Queues

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 . ; Perhatikan titik
Hg hg add ; Tidak perlu titik.

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

Hanya untuk mengisi kekosongan, beberapa perintah paling berguna dari Mercurial:

Hg hg record
Git git add -p; git commit

Hg hg inc [URL]
Git Tidak ada padanan nyata. Anda hanya dapat melakukan yang setarahg pull; hg log -r .:

Hg hg out URL
Git Silakan tambahkan jika Anda tahu caranya.

Untuk menggabungkan resolusi konflik, hg resolveperintah di Mercurial memiliki beberapa opsi yang mengubah perilaku:

Hg hg resolve -m FILE (menandai file sebagai telah diselesaikan dengan memperbaiki masalah konflik secara manual)
Git git add FILE

Hg hg resolve -u FILE menandai file sebagai
Git yang belum terselesaikan git reset HEAD FILEuntuk menghapus file

Hg hg resolve -l (daftar file dengan konflik yang diselesaikan / tidak terselesaikan)
Git git status - file yang digabungkan dengan rapi ditambahkan ke indeks secara otomatis, file yang tidak memiliki konflik

Hg hg resolve FILE (setelah penggabungan, mencoba untuk menggabungkan kembali file)
Git tidak ada yang setara untuk penggabungan ulang yang saya tahu.

Catatan: salah satu perbedaan terbesar antara Git dan Mercurial adalah keberadaan indeks atau area pementasan secara eksplisit .

Dari Mercurial untuk Pengguna Git :

Git adalah satu-satunya DistributedSCM yang mengekspos konsep indeks atau area pementasan. Yang lain mungkin mengimplementasikan dan menyembunyikannya, tetapi tidak ada kasus lain pengguna sadar atau harus menghadapinya.

Persamaan kasar Mercurial adalah DirState, yang mengontrol informasi status copy pekerjaan untuk menentukan file yang akan disertakan dalam komit berikutnya. Namun bagaimanapun, file ini ditangani secara otomatis.
Selain itu, dimungkinkan untuk lebih selektif pada waktu komit baik dengan menentukan file yang ingin Anda komit pada baris perintah atau dengan menggunakan RecordExtension.

Jika Anda merasa tidak nyaman berurusan dengan indeks, Anda beralih ke yang lebih baik ;-)

Triknya adalah, Anda benar-benar perlu memahami indeks untuk memanfaatkan Git sepenuhnya. Seperti yang diingatkan oleh artikel dari Mei 2006 ini (dan itu masih berlaku sampai sekarang):

“Jika Anda menolak Index, Anda benar-benar menolak git itu sendiri.”

Sekarang, artikel itu berisi banyak perintah yang sekarang lebih mudah digunakan (jadi jangan terlalu mengandalkan isinya;)), tetapi gagasan umumnya tetap:

Anda sedang mengerjakan fitur baru dan mulai membuat sedikit modifikasi pada file.

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

Pada titik ini, komit Anda berikutnya akan memulai 2 modifikasi kecil di cabang saat ini

# working, making major modification for the new features
# ... damn! I cannot commit all this in the current branch: nothing would work

$ git commit

Hanya mencatat perubahan yang ditambahkan ke staging area (indeks) pada saat ini, bukan perubahan besar yang saat ini terlihat di direktori kerja Anda.

$ git branch newFeature_Branch
$ git add myFile

Komit berikutnya akan merekam semua perubahan besar lainnya di cabang baru 'newFrature_Branch'.

Sekarang, menambahkan secara interaktif atau bahkan memisahkan komit adalah fitur yang tersedia dengan Mercurial, melalui perintah ' hg record' atau ekstensi lain: Anda perlu menginstal RecordExtension, atau CrecordExtension.
Tapi ini bukan bagian dari alur kerja normal Mercurial.

Git melihat komit sebagai rangkaian " perubahan konten file ", dan membiarkan Anda menambahkan perubahan itu satu per satu.
Anda harus mempelajari fitur tersebut dan konsekuensinya: Sebagian besar kekuatan Git (seperti kemampuan untuk dengan mudah mengembalikan penggabungan (atau membagi dua masalah, atau mengembalikan komit) , bertentangan dengan Mercurial ) berasal dari paradigma "konten file".

tonfa (di profil: "Hg dev, pythonist": figures ...) menimpali, di komentar:

Tidak ada yang secara fundamental "git-ish" dalam indeks, hg dapat menggunakan indeks jika dianggap berharga, sebenarnya mqatau shelvesudah melakukan sebagian dari itu.

Oh Boy. Baiklah, kita lanjut lagi.

Pertama, saya di sini bukan untuk membuat satu alat terlihat lebih baik dari yang lain. Saya menemukan Hg hebat, sangat intuitif, dengan dukungan yang baik (terutama di Windows, platform utama saya, meskipun saya bekerja di Linux dan Solaris8 atau 10 juga).

Indeks sebenarnya berada di depan dan di tengah cara kerja Linus Torvalds dengan VCS :

Git menggunakan pembaruan indeks eksplisit dari hari pertama, bahkan sebelum penggabungan pertama dilakukan. Begitulah cara saya selalu bekerja. Saya cenderung memiliki pohon yang kotor, dengan beberapa tambalan acak di pohon saya yang tidak ingin saya lakukan , karena ini hanya pembaruan Makefile untuk versi berikutnya

Sekarang kombinasi indeks (yang bukan gagasan yang hanya terlihat di Git), dan paradigma "konten adalah raja" membuatnya sangat unik dan "git-ish" :

git adalah pelacak konten , dan nama file tidak memiliki arti kecuali jika dikaitkan dengan isinya. Oleh karena itu, satu-satunya perilaku yang masuk akal untuk nama file git add adalah menambahkan konten file serta namanya ke indeks.

Catatan: "konten", di sini, didefinisikan sebagai berikut :

Indeks Git pada dasarnya sangat banyak didefinisikan sebagai

• cukup untuk memuat total " konten " dari pohon (dan ini termasuk semua metadata: nama file, mode, dan konten file adalah semua bagian dari "konten", dan semuanya tidak ada artinya sendiri! )
• informasi "stat" tambahan untuk memungkinkan pengoptimalan perbandingan sistem file yang jelas dan sepele (tapi sangat penting!).

Jadi Anda benar-benar harus melihat indeks sebagai menjadi konten .

Konten bukanlah "nama file" atau "konten file" sebagai bagian yang terpisah. Anda benar-benar tidak dapat memisahkan keduanya .
Nama file sendiri tidak masuk akal (mereka harus memiliki konten file juga), dan konten file sendiri juga tidak masuk akal (Anda harus tahu bagaimana menjangkaunya).

Apa yang ingin saya katakan adalah bahwa git pada dasarnya tidak mengizinkan Anda melihat nama file tanpa isinya. Seluruh gagasan itu gila dan tidak valid. Tidak ada relevansinya dengan "realitas".

Dari FAQ , keuntungan utamanya adalah:

• berkomitmen dengan perincian yang bagus
• membantu Anda menyimpan modifikasi tanpa komitmen di pohon Anda untuk waktu yang cukup lama
• melakukan beberapa langkah kecil untuk satu komit, memeriksa apa yang Anda lakukan dengan git diff, dan memvalidasi setiap langkah kecil dengan git addatau git add -u.
• memungkinkan manajemen yang sangat baik dari menggabungkan konflik: git diff --base, git diff --ours, git diff --theirs.
• memungkinkan git commit --amenduntuk hanya mengubah pesan log jika indeks belum dimodifikasi untuk sementara

Saya pribadi berpikir perilaku ini seharusnya tidak menjadi default, Anda ingin orang melakukan sesuatu yang diuji atau setidaknya dikompilasi

Meskipun Anda benar secara umum (tentang bagian "diuji atau dikompilasi"), cara Git memungkinkan Anda untuk bercabang dan menggabungkan (cherry-picking atau rebasing) memungkinkan Anda untuk melakukan sesering yang Anda inginkan di cabang pribadi sementara (hanya didorong ke repositori "cadangan" jarak jauh), saat melakukan kembali "komitmen buruk" itu di cabang publik, dengan semua pengujian yang benar sudah siap.

Lincah:

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?

Setara Git:

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

Ini kira-kira sama, tanpa 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

Namun, ini adalah perintah yang akan Anda gunakan saat bekerja sendiri. Anda masuk ke hal-hal yang rapi ketika Anda ingin menggabungkan perubahan Anda dengan pekerjaan orang lain dengan git pulldan git push, dan perintah terkait.