Mengapa belajar git ketika ada aplikasi GUI untuk GitHub?


84

Mengingat bahwa GitHub menyediakan aplikasi GUI untuk Mac dan Windows , apa manfaat belajar menggunakan git dari baris perintah?

Saat ini saya menggunakan aplikasi mac mereka untuk memperbarui repositori saya, dan sejauh ini tampaknya memenuhi kebutuhan saya. Apa yang mungkin saya lewatkan?


15
Jangan lupa gitk yang merupakan gui untuk Linux.
PengembangDon

14
Anda melewatkan semua skrip.
SK-logic

3
@KChaloux, ya, ada alasan yang sangat bagus mengapa sebagian besar aplikasi GUI tidak bisa dituliskan sama sekali. Dan orang-orang yang skrip hanya mengerikan (pikirkan COM dan kekejian serupa).
SK-logic

2
@KChaloux, tidak ada alasan yang bukan kualitas. Sangat sulit untuk membuat skrip aplikasi GUI murni. Semua pendekatan masuk akal yang saya tahu, pada dasarnya, dibangun dengan memperkenalkan beberapa bentuk antarmuka baris perintah - baik CLI gaya Unix, atau bahasa perintah berbasis teks, atau beberapa protokol biner yang pada dasarnya sama dengan bahasa perintah , lihat COM. Tetapi pendekatan terbaik, tentu saja, adalah memiliki inti bersama yang dapat diakses melalui berbagai alat CLI dan dari GUI. Yang terakhir juga dapat dibangun di atas CLI untuk kesederhanaan.
SK-logic

13
Kamu tidak. Dengan cara yang sama Anda tidak perlu belajar HTML / CSS karena Dreamweaver dan Frontpage (atau apa pun itu sekarang) ada. Mungkin itu akan bekerja untuk Anda untuk beberapa hal, tetapi ketika itu tidak ada yang lebih tahu cara kerjanya.
DorkRawk

Jawaban:


116

Saya pikir pertanyaan ini hanyalah kasus khusus "Mengapa saya harus mempelajari CLI yang ada alternatif GUI?". Saya menduga pertanyaan terakhir adalah setua GUI, dan saya berasumsi ada banyak upaya untuk menjawabnya selama bertahun-tahun. Saya bisa mencoba untuk menerobos jalan saya sendiri melalui jawaban saya untuk pertanyaan ini, tetapi Neal Stephenson mengartikulasikan apa yang saya setujui sebagai 'jawaban pamungkas' lebih dari sepuluh tahun yang lalu dalam esainya yang luar biasa Dalam Permulaan ... Adalah Baris Perintah .

Sementara esai menyentuh banyak aspek komputasi, dan sementara Stephenson sendiri berpikir bahwa banyak yang sekarang sudah usang, esai menjelaskan dalam hal apa CLI adalah GUI yang lebih baik dengan cara yang sangat menarik yang benar-benar mengubah hidup saya. Ini sudah lama dibaca (~ 40 halaman), tapi saya tidak bisa merekomendasikan cukup untuk siapa pun yang mengajukan pertanyaan seperti Anda bertanya di sini.

Akhirnya, meskipun saya akan menjawab segala jenis pertanyaan CLI vs GUI dalam nada yang sama, saya pikir jawaban saya berlaku terutama untuk pertanyaan spesifik Anda karena semua hal komputer yang Anda pilih untuk ditanyakan git. gitbisa dibilang alat terbaru dalam daftar alat komputer yang tidak terlalu lama yang benar-benar layak untuk metafora hole-hawg seperti yang dijelaskan dalam esai Stephenson. git, seperti beberapa hal Unix-ish lainnya, adalah alasan untuk mengetahui CLI dengan sendirinya. Terkadang terlepas dari 'porselen' yang tidak menentu ; kadang karena itu.

Jadi ya, Anda pasti dapat menjadi produktif dengan GUI github, baik untuk OSX atau bahkan hanya di situs web mereka. Ya, ini sebenarnya cukup ramping, saya sering menggunakan fitur situs. Tetapi tidak, Anda tidak akan pernah memiliki perasaan saleh seperti jari kelingking kanan Anda tergantung di atas git filter-branchperintah gila selama satu atau dua tahun. Jika saya harus menjaga satu hal dari pengalaman saya dalam komputasi - tantangan mental, persahabatan dekat terbentuk di pusat data pada pukul 02:00, tangga kompetensi tak terbatas untuk dipanjat, menyentuh kehidupan pengguna, dan memerintah atas PBs dari data berharga, yang nyaman pekerjaan dan kehidupan yang nyaman - pertahankan hanya satu hal - itu adalah perasaan Tuhan.


5
Tautan yang lebih mudah diakses ke In the Beginning ... Was the Command Line: pauillac.inria.fr/ ~weis
Elias Zamaria

1
Re: usang: itu akan menjadi bagian "BeOS as Batmobile", kan?
naught101

2
Garrett Birkel telah memperbarui esai "In the Beginning ... Was the Command Line" dengan menyelingi komentarnya dengan esai asli Neal Stephenson. Anda dapat membacanya di sini .
Saya Suka Kode

2
... yeah, siapa yang butuh CLI ketika Anda dapat membuat antarmuka GUI menggunakan Visual Basic. Bagus untuk hal-hal seperti melacak alamat IP.
Hei

3
Saya tidak menyarankan 'lebih tua lebih baik', saya menyarankan CLI (untuk banyak pengguna hacker) lebih unggul daripada GUI. CLI juga lebih unggul dari sakelar biner dan kabel patch. Itu sebabnya saya menggunakan CLI. Artikel ini bukan "bukti" karena "dalam artikel", ini prosa dengan argumen yang mengartikulasikan apa yang saya sukai tentang CLI. Sudah tua, tapi begitu juga UNIX, jadi apa. Omong-omong, saya bekerja untuk Google, dan sebagian besar pengembang di sekitar saya menggunakan lingkungan pengembangan berbasis CLI (tapi saya tidak bisa berbicara untuk Google secara keseluruhan, tentu saja).
Yaniv Aknin

108

Jika semua kebutuhan Anda dipenuhi, luar biasa, tidak perlu menggali lebih dalam, git Anda akan lebih baik dihabiskan untuk mempelajari sesuatu yang sebenarnya Anda butuhkan.

git hanyalah alat, ketika Anda harus melakukan sesuatu yang tidak dapat dilakukan dengan aplikasi GUI, Anda akan mengetahuinya. Ingatlah bahwa github! = Git.


1
Saya setuju dengan Anda, tetapi mungkin ada hal-hal yang saya tidak sadari saat ini, yang mungkin berguna bagi saya jika saya menyadarinya. Tidak?
histelheim

28
@AronLindberg Ya, mungkin ada. Tetapi Anda mengajukan pertanyaan yang salah, apa yang harus Anda habiskan untuk menyelidiki adalah alur kerja dan konsep git, bukan baris perintah. Bahkan jika seseorang mencantumkan semua fungsi yang tidak ada aplikasi GUI, bagaimana Anda tahu jika Anda benar-benar membutuhkannya? (juga itu adalah sesuatu yang dapat dengan mudah Anda lakukan sendiri, hanya dengan melihat dokumentasi git)
yannis

//, CLI akan memaksa Anda untuk memikirkan alur kerja dan konsep sedikit lebih banyak, karena semua organisasi, pilihan, dan aliran akan terjadi di kepala Anda, bukan di Wizards dan menu drop-down.
Nathan Basanese

57

Sebagian besar fitur CLI-only hanya berperan ketika Anda secara tidak sengaja membuat repositori Anda dalam keadaan aneh dan ingin memperbaikinya. Di sisi lain, cara paling umum untuk membuat repo Anda menjadi aneh adalah dengan menggunakan fitur-fitur canggih yang tidak Anda mengerti. Jika Anda tetap berpegang pada apa yang disediakan GUI, itu akan memenuhi kebutuhan Anda 99% setiap saat.

Alasan lain Anda mungkin ingin mempelajari CLI adalah karena itu adalah lingua franca git. Itu berarti sementara banyak orang menggunakan GUI yang berbeda pada platform yang berbeda, jika Anda meminta bantuan pada StackOverflow atau di tempat lain, jawabannya kemungkinan besar akan datang dalam bentuk perintah CLI. Jika Anda tidak tahu CLI, opsi Anda untuk mendapatkan bantuan akan jauh lebih terbatas.


Jawaban terbaik di sini. Bukan bla-bla-bla-filosofi.
john cj

//, Ini adalah pemikiran pertama saya, dan meskipun jawaban filosofis menarik bagi saya, alasan utama saya menggunakan CLI adalah karena mereka jauh lebih mudah untuk dipikirkan, distandarisasi, dan berkomunikasi dengan orang lain melalui teks. Kita mungkin tidak semua tahu cara menggambar, tetapi kita semua tahu cara mengetik.
Nathan Basanese

9

Aplikasi GUI mengandalkan interaksi manual untuk melakukan perilaku kompleks. Ini bagus untuk menyiapkan proyek dan mengembangkan hal-hal baru.

Manfaat dari Command-Line Interface (CLI) berasal dari kemampuan untuk membuat skrip yang telah ditentukan yang dapat diotomatisasi. Semua GitHub's GUI adalah, adalah beberapa grafik bagus dan tombol mewah yang memanggil CLI git.

Apa yang tidak akan dilakukan aplikasi GUI untuk Anda adalah secara otomatis memperbarui trunk repo di server setiap hari pada pukul 1:30 pagi, tetapi tugas cron yang memanggil git CLI adalah cara yang sangat mudah untuk mengaturnya.

Selain itu, ketika mengerjakan proyek dalam sebuah tim, akan lebih mudah untuk mengatur skrip instalasi, membangun skrip, menyebarkan skrip, dan sejenisnya sehingga rekan tim dapat fokus pada penyelesaian masalah alih-alih tugas berulang yang membosankan.


bagasi? Saya pikir maksud Anda master.
jpmc26

@ jpmc26, saya menulis ini ketika saya masih baru untuk git yang berasal dari SVN, maafkan terminologinya.
zzzzBov

6

Alasan lain mengapa CLI mungkin lebih disukai adalah masalah alur kerja. Banyak kerangka kerja dikelola melalui baris perintah. Menggunakan git melalui CLI biarkan saya tetap fokus pada proyek saya dan di direktori proyek itu. Misalnya saya mungkin menjalankan tes dan kemudian memutuskan untuk melakukan perubahan baru semua dari antarmuka dan lokasi yang sama.


+1; dan semakin mudah / semakin mudah diaksesnya untuk digunakan, semakin besar kemungkinan saya untuk menggunakannya ketika pada waktu yang tepat (ketuk ketuk git komit ketuk ketuk) alih-alih (ketuk peluncuran peluncuran GUI git komit 'komitmen akhir minggu')
Abe

5

Baru-baru ini saya harus benar-benar menggali ke dalam Git untuk dapat membantu dengan migrasi SVN-ke-Git. Dan hal yang saya pelajari adalah bahwa alat baris perintah Git bukan bagian yang rumit untuk dipelajari.

Konsep dan ide di balik Git adalah bagian yang kompleks (dan itu bukan karena mereka dirancang dengan buruk, tetapi hanya karena mereka asing bagi kebanyakan orang yang datang dari beberapa VCS lain yang terpusat).

Setelah saya memahami konsepnya, pernyataan baris perintah yang sebenarnya menjadi relatif mudah. Itu berarti bahwa UI tidak benar-benar membantu memahami Git (kecuali untuk operasi yang paling sederhana).


3
Sebenarnya, konsep di baliknya gitsangat sederhana sehingga orang tidak dapat menemukannya - mereka mencari sesuatu yang lebih sulit.
gahooa

4

Mengetahui CLI sangat berguna ketika (tidak jika) Anda berada di lingkungan di mana Anda tidak bisa mendapatkan aplikasi GUI.

Satu skenario potensial: Anda diminta untuk membantu hanya beberapa hari pada proyek di lokasi tertutup di mana sangat sulit dan lama untuk memasukkan alat baru ke dalam sistem. Mereka hanya menggunakan CLI. Produktivitas Anda sangat terpukul karena Anda perlu mempelajari semuanya dari awal.


Satu kalimat jawaban jarang memberikan banyak nilai. Bisakah Anda memperluas jawaban Anda?
Walter

//, Dia adalah @grumpasaurus. Apa yang Anda harapkan, soneta?
Nathan Basanese

2

Salah satu alasan untuk mempelajari command-line git adalah kebanyakan dokumentasi ditulis untuk lingkungan itu. Juga, jika Anda mengajukan pertanyaan: "Bagaimana saya melakukan X dengan git?", Kemungkinan jawabannya adalah berisi perintah-perintah baris perintah.


1

Salah satu masalah utama dengan menggunakan GUI versus baris perintah adalah bahwa Anda tidak dapat memiliki kontrol yang sama atas proses Anda, dalam banyak kasus. Sebagai contoh, aplikasi GitHub sangat bagus dalam hal kegunaan untuk banyak alur kerja git, tetapi masih bisa rumit untuk proses git canggih.

Sebagai contoh, berikut adalah beberapa hal yang belum saya ketahui bagaimana melakukannya dengan menggunakan aplikasi GitHub (hal lain yang perlu diperhatikan adalah bahwa masing-masing GUI juga memiliki kurva belajar).

  • Komitmen rebasing
  • Tekan / Tarik / Ambil satu per satu (di GitHub mereka dikelompokkan menjadi satu perintah "sinkronisasi" yang mungkin menyebabkan masalah beberapa kali)
  • Mengubah komitmen

Akhirnya, CLI memungkinkan pengguna untuk menggunakan alat ini saat membuat skrip.


Poin terakhir adalah kunci bagi saya. Membuat skrip, alat, dan server jarang menggunakan gui karena memiliki kontrol versi akses gui. Seseorang harus menggunakan baris perintah.

0

Saya tidak tahu tentang GitHub untuk Mac, tetapi aplikasi Windows hanya melakukan tugas-tugas yang paling umum - tambahkan, komit, dorong, tarik, dll. Tugas yang lebih rumit seperti git merge --no-ffharus dilakukan dari baris perintah.

Juga, ada beberapa kasus dengan git ketika GUI tidak tersedia, misalnya ketika SSHing ke server jauh.

Tetapi sebaliknya, jika GUI memberi Anda semua yang Anda butuhkan maka mempelajari baris perintah mungkin membuang-buang waktu. Pekerjaan saya menggunakan TortoiseSVN di lingkungan khusus Windows, dan saya belum pernah menyentuh baris perintah SVN sekali pun.


0

Saya baru belajar satu kasus di mana CLI bisa lebih baik daripada GUI. Untuk menggambarkan hal ini, saya mengambil contoh dari kontrol versi git buku untuk semua orang.

Saat Anda ingin berbagi melalui intranet, maka Anda dapat menggunakan:

  1. Server Gitolite
  2. Direktori berbagi umum dengan repositori kosong

Lihatlah langkah-langkah untuk membuat repo telanjang.

Membuat repositori kosong dalam mode CLI

Perintah untuk membuat repositori kosong akan sama dengan yang Anda gunakan untuk mengkloning repositori kecuali untuk parameter --bare, yang membuat semua perbedaan. git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench Mengeksekusi kode sebelumnya di konsol Anda harus membuat tiruan kosong dari repositori Workbench kami di folder bersama Anda yang umum yang disebut generic_share.

Membuat repositori kosong dalam mode GUI

Membuat clone kosong dari repositori yang sudah ada menggunakan GUI adalah proses yang mudah. Yang perlu Anda lakukan adalah:

  1. Salin direktori .git dari repositori yang ada dan tempelkan dengan nama_tanggal.game yang berbeda (nama apa pun yang ingin Anda berikan ke repositori telanjang baru) di luar repositori. Dalam kasus kami, kami memiliki repo kosong yang disebut Workbench di C: \ Users \ raviepic3 \ Desktop \ di dalamnya kami memiliki content.docx. Dan sekarang saya ingin membuat repositori telanjang baru dari ini menggunakan GUI. Saya akan menyalin C: \ Users \ raviepic3 \ Desktop \ Workbench.git dan menempelkannya sebagai C: \ generic_share \ Bare_Workbench.git.

  2. Buka bagian config filedalam Bare_Workbench.git dengan editor teks dan temukan baris yang mengatakan bare = falsedan ganti string false dengan true.

  3. Simpan dan keluar.

Di GUI, Anda harus melakukan begitu banyak klik dan ingat file mana yang akan diedit. Di CLI, satu perintah sederhana melakukan semuanya untuk Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.