Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Tools

Git untuk desainer

by
Read Time:15 minsLanguages:

Indonesian (Bahasa Indonesia) translation by fodal fadel (you can also view the original English article)

Anda mungkin akrab dengan alat-alat, seperti Git dan Subversion. Tapi, sebagai web designer, itu sangat mungkin bahwa, meskipun Anda mungkin berkata Anda memanfaatkan kontrol versi dalam proyek Anda, kebenaran adalah bahwa, lebih sering daripada tidak, Anda hanya tidak.

Jika Anda sesuai dengan uraian ini, jangan khawatir; Anda tidak sendirian. Pada kenyataannya, itu adalah pendapat penulis ini sepenuhnya unresearched yang mayoritas besar web designer tidak! Dilema adalah bahwa ada kepercayaan umum bahwa kontrol versi secara ketat untuk hardcore coders, yang menghabiskan hari-hari mereka dalam kegelapan, dan yang jarang datang untuk udara, kecuali ketika microwave dings, menandakan bahwa saku panas sudah siap untuk dimakan.

Pada kenyataannya, jika Anda kode untuk web, baik di front-end atau back-end, itu adalah tugas Anda untuk kode bertanggung jawab: menggunakan kontrol versi.


5 tanda-tanda bahwa Anda terlambat untuk kontrol versi

  1. Anda tidak memiliki konsep kontrol versi apa, atau mengapa itu mungkin berguna.
  2. Anda kode lokal, dan tidak memiliki cadangan sistem.
  3. Anda melakukan backup atas proyek Anda oleh sporadis duplikasi direktori root.
  4. Anda secara tidak sengaja menghapus file secara permanen, dan harus recode dari awal.
  5. Saat Anda membuat beberapa editan, aplikasi Anda istirahat, di mana titik Anda harus tahan Command + Z untuk sejumlah menyakitkan detik, ketika Anda menonton editor membalikkan perubahan Anda.

Mengakuinya: setiap pengembang telah mengidentifikasi salah satu tanda mencatat sebelumnya pada satu titik atau lain dalam karir nya. Tapi ingat: langkah pertama untuk pemulihan adalah mengakui bahwa Anda memiliki masalah!


5 manfaat langsung ke kontrol versi

  1. Sengaja dihapus itu kelas atau PSD? Menjalankan sebuah perintah di terminal untuk kembali ke keadaan sebelumnya dalam proyek. Bencana dihindari!
  2. Pernah terkesiap dengan ngeri, seperti website Anda entah bagaimana menghilang dari desktop Anda? Itu ada di sana kemarin, tapi hari ini, itu hilang! Sebuah layanan gratis yang disebut GitHub, membuat ini non-isu.
  3. Siapa sih akan menulis sedikit kode yang saya sekarang harus menghabiskan berjam-jam menulis ulang? Tidak perlu bertanya-tanya siapa yang menyalahkan; Git akan memberitahu Anda!
  4. Kode dengan meninggalkan, saat mengetahui bahwa, dengan setiap commit, "snapshot" dari aplikasi Anda yang disimpan, hanya dalam kasus Anda perlu roll kembali ke negara ini di beberapa titik di masa depan.
  5. Jika karena alasan lain, menerima bahwa pengembang yang mungkin jauh lebih berpengalaman daripada Anda telah dianggap penerapan terbaik. Hal ini membantu untuk meniru orang-orang kepada siapa kita kagumi.

Git?

Git adalah sistem kontrol versi paling populer yang tersedia.

Jadi bagaimana Git faktor ke hal kontrol versi seluruh? Well, definisi super kutu buku adalah bahwa Git adalah sebuah sistem kontrol versi terdistribusi, dikembangkan oleh Linus Torvalds, dimana setiap direktori kerja adalah repositori sendiri dengan sejarah penuh tersedia setiap saat. Selain itu, Git menawarkan kemampuan untuk berbagi kode, dan membuat beberapa cabang (atau jadwal) untuk proyek Anda, sehingga sangat cocok untuk tim Tangkas pengembangan.

Definisi yang lebih dimengerti mungkin: Git adalah alat Command-Line Anda - dan pengembang lain dalam tim Anda - gunakan untuk menyimpan sering snapshot dari proyek Anda. Pada titik tertentu, hotel ini menawarkan fleksibilitas untuk memutar kembali perubahan ke Serikat sebelumnya, dengan hanya satu perintah.

Scott Chacon buku, 'Pro Git,' ini tersedia dalam keseluruhan situs web Git.


Menginstall Git

Tentu saja, langkah pertama untuk wreckless, "Koboi Coding" recovery adalah untuk mengunduh Git dari git-scm.com. Menggunakan salah satu URL berikut, tergantung pada OS Anda pilihan.

  • Mac: https://git-scm.com/download/mac
  • Windows: http://git-scm.com/download/win

Selanjutnya, kita perlu mengkonfigurasi instalasi hanya dengan sentuhan, dengan mengaitkan username dan alamat email. Membuka konsol Anda terdekat (Terminal pada Mac), dan jalankan:

Jangan khawatir; ini hanya perlu mengetik sekali, setelah Anda pertama kali menginstall Git. Sekarang, untuk setiap tindakan yang Anda ambil, Git akan menggunakan pengaturan ini.

Ada pilihan konfigurasi lebih lanjut, seperti menentukan editor kode yang harus digunakan, ketika Git membutuhkan Anda untuk mengetikkan pesan commit, tetapi mengabaikan bahwa untuk saat ini.

Selamat, Git berhasil diinstal!


Siklus dasar

Seperti halnya teknologi baru, ada sedikit kecil belajar diperlukan.

Salah satu aspek yang paling sulit untuk belajar Git adalah memecahkan apa berbagai jargon merujuk kepada. Commit? Pementasan? Cabang? Log? Ya?

Seperti halnya teknologi baru, ada sedikit kecil belajar diperlukan. Untungnya, sebagai kompleks seperti Git dapat, khususnya sebagai web desainer, Anda akan menemukan bahwa beberapa perintah akan pergi jauh. Sebagai perbandingan, pertimbangkan Inggris Kamus, dan kemudian jumlah kata yang realistis kita gunakan dalam percakapan sehari-hari. Hal yang sama juga berlaku untuk Git - pada tingkat yang jauh lebih rendah. Jadi jangan merasa kewalahan. Ambil satu perintah pada suatu waktu.

Untuk melumpuhkan ini membingungkan terminologi, yang terbaik pertama berpikir dalam sesuatu yang nyata di dunia nyata: sebuah truk pengiriman.

Bayangkan bahwa Anda telah memulai sebuah website statis yang baru. Anda telah membuat folder untuk JavaScript dan CSS file, serta index.html file dengan sedikit boilerplate HTML. Pada kenyataannya, melakukan hal yang sama sekarang! Ketika selesai, saatnya untuk membuat commit pertama.

Kembali ke Terminal, dan ketik:

Perintah ini, "menginisialisasi Git," memberitahu Git bahwa kita inginkan kontrol versi untuk proyek ini. Atau, "start pengapian." Hanya perlu dijalankan sekali, pada awal siklus hidup sebuah proyek baru.

Selanjutnya, mari kita menentukan apa "status".

Jika bekerja bersama, Anda akan cenderung melihat sesuatu di sepanjang baris:

Meskipun agak membingungkan, jika kita mengambil waktu, kita akan melihat bahwa, secara default, kami bekerja pada "cabang," disebut "penguasa." Selanjutnya, kita memiliki satu berkas terpantau: index.html. Dari ini, kita akan mampu menguraikan bahwa Git tidak ajaib; itu harus diberitahu file yang mana yang mengawasi, sehingga untuk berbicara.

Ingin tahu mengapa direktori JavaScript dan CSS tidak disertakan dalam daftar berkas terpantau? Git melacak file, folder tidak. Teknik umum, meskipun, untuk menyertakan direktori kosong dalam komit adalah untuk menambahkan berkas .gitignore ke setiap subdirektori. Lebih pada nanti!

Memantau berkas

Untuk melacak file, kami harus pertama menambahkannya ke staging area - atau, meletakkannya di atas truk.

Sekarang, jika kita memeriksa status lagi, kita akan melihat:

Sangat baik; Git adalah menonton file ini untuk perubahan. Dalam kasus ini, kami telah hanya menambahkan satu file. Jika, sebaliknya, kita akan lebih suka untuk menambahkan semua file ke staging area, kita dapat menggunakan simbol periode.

Perlu diingat bahwa truk belum lagi pergi; kami hanya telah dimuat beberapa kotak (atau file) ke belakang. Untuk melakukan snapshot, dan menyimpan salinan proyek dalam keadaan saat ini dilacak, komit harus dilakukan.

Di atas, kami telah menciptakan komit baru, dan memberikan pesan "Commit pertama." Dengan itu, kami komit pertama telah selesai, dan truk telah meninggalkan untuk pabrik, dengan salinan proyek di belakang.

Untuk memverifikasi pekerjaan Anda, gunakan perintah baru: "log."

Sempurna, komit baru, pada kenyataannya, telah dibuat, dan tampaknya juga bahwa commit memiliki id unik referensi. File yang pergi untuk sekarang.

Jika Anda, sekali lagi, memeriksa status.

Karena tidak ada perubahan yang telah dibuat sejak terakhir commit, Git memberitahu kita sebanyak:

Sukses! 90% dari penggunaan Git Anda akan mengikuti siklus ini.

  • Membuat perubahan
  • Menambahkan file ke staging area
  • Melakukan komit dengan pesan yang menggambarkan tindakan yang terjadi

Bilas dan ulangi!

Mari kita beralih ke langkah berikutnya. Sebagai contoh mudah, mungkin kita ingin menyertakan sederhana reset stylesheet dalam proyek kami. Kami akan menulis paling dasar (mungkin keliru) resets.

Sekarang, kembali ke index.html, dan termasuk referensi ke file ini:

Sebagai aturan dasar, jika Anda dapat menjelaskan kepada orang yang duduk di sebelah Anda perubahan apa yang baru saja Anda buat untuk sebuah proyek, maka mungkin layak komit. Komit sering. Mari kita lakukan sekarang; kembali ke Terminal!

Ketika menulis pesan komit, itu telah umumnya dianggap sebagai praktek terbaik untuk menulis dalam present tense. Jadi, "tambah file" bukannya "menambahkan file."

Cepat-maju untuk besok, dan sekarang bos Anda memberitahu Anda bahwa mereka tidak ingin menggunakan file reset sederhana. Sebaliknya, mereka lebih suka menggunakan stylesheet Normalisasikanlah populer, oleh Nicolas Gallagher.

Tidak masalah; dengan Git, ini adalah memperbaiki yang mudah. Mari kita kembali komit sebelumnya, dan membuat modifikasi yang diperlukan.

Dengan Git, aturan adalah, "tidak pernah menulis ulang sejarah."

Perintah ini akan membalikkan semua perubahan yang Anda buat pada commit terakhir. Pada dasarnya, ini adalah komit yang melakukan kebalikan dari apa yang sebelumnya. Mengapa kembali, daripada melepas komit sepenuhnya? Sekali lagi, karena kita mengikuti praktik terbaik. Dengan Git, aturan adalah, "tidak pernah menulis ulang sejarah." Memulihkan perubahan, tapi tidak pernah menghapus dan membatalkan mereka.

Berdasarkan memukul masuk, Anda akan dibawa ke layar baru dengan teks, "Pulihkan" tambah dan termasuk reset stylesheet. " Pada titik ini, Anda berada dalam modus Vi (meskipun Anda bebas untuk mengkonfigurasi Git menggunakan editor kode apapun yang Anda inginkan.) Untuk sekarang, pergi dengan default, Simpan, dan keluar. Melakukannya dengan mengetik,: wq (menulis dan keluar).

Dan dengan itu satu perintah, perubahan telah dikembalikan. Pergi ke depan dan memeriksa untuk memastikan. Style.css file telah dihapus, dan tidak ada referensi ke stylesheet dalam index.html. Ini adalah kekuatan Git! Karena kami mengadopsi gaya pengembangan melakukan sering, ketika ditempatkan di situasi, mana suntingan perlu dibalikkan, hanya dibutuhkan satu perintah. Tidak lebih menekan perintah-Z untuk enternity!

Setelah permintaan bos, mari kita memperbarui proyek untuk menggunakan Normalize.css, yang kita sudah download dan ditempatkan dalam css/normalize.css.

Dalam index.html, referensi:

Dan, akhirnya, kita melakukan perubahan.

Meskipun ini adalah jelas contoh sederhana, Bayangkan bagaimana berguna teknik ini bisa untuk perubahan yang lebih besar, yang meliputi beberapa file dalam aplikasi Anda. Dengan mengelompokkan semua perubahan yang terkait ke satu commit, kita mencapai maksimum fleksibilitas dan keamanan.


Ruang untuk percobaan

Pernah berada pada titik dalam proyek, ketika Anda ingin bereksperimen dengan sebuah ide yang mungkin atau mungkin tidak membuat itu ke dalam aplikasi selesai? Sementara benar bahwa Anda selalu dapat kembali komit jika sesuatu tidak berjalan sesuai rencana, itu adalah ide yang cerdas, untuk berbagai alasan, malah memanfaatkan percabangan.

Cara terbaik untuk menggambarkan konsep cabang Git adalah untuk referensi kembali ke 2 masa depan.

Pada catatan, jika Anda seorang pengembang kutu buku dan belum melihat kembali ke masa depan trilogi, menghentikan apa yang Anda lakukan dan menonton mereka!

Melanjutkan, ingat bagian di belakang untuk 2 masa depan, setelah Marty dan Doc kembali ke 1985 dari masa depan, tetapi menemukan bahwa segala sesuatu berbeda? Setelah pertemuan di Doc, sekarang lab hancur, Doc menarik diagram, menggambarkan bagaimana, di beberapa titik, "timeline miring ke tangen ini, menciptakan alternatif 1985." Ini adalah seperti bercabang!

Mempertimbangkan proyek demo kami saat ini; Sekarang, ada satu timeline: garis lurus. Segera setelah kami membuat cabang untuk bekerja pada gagasan kami, kita melepaskan diri dari waktu ini, dan membuat satu lagi. Pada titik ini, jadwal kedua ada, dan dapat berisi commit masing-masing mereka sendiri, tanpa mengganggu satu sama lain.

Bagaimana Apakah ini berguna? Pertimbangkan Tangkas pengembangan siklus - salah satu yang mana Anda atau tim Anda menyebarkan update beberapa kali setiap minggu. Jika Anda tetap dengan pendekatan "satu timeline", penggelaran, misalnya, memperbaiki kesalahan ketik sederhana, tidak akan tersedia sampai Anda selesai bekerja pada ide Anda juga. Dengan bercabang, namun, kami memiliki fleksibilitas untuk mengambil selama kita perlu pada gagasan kami, sementara masih membebaskan master cabang (default dan satu utama) untuk menggelar memperbaiki kesalahan ketik.

Untuk membuat cabang baru, jalankan:

Selain itu, menggabungkan dua menjadi satu.

Ini diterjemahkan: membuat cabang baru, disebut "ide" (mengganti ini menjadi lebih deskriptif dari apa yang sedang Anda bekerja pada, tentu saja), dan beralih ke itu.

Dari titik ini, setiap perubahan dan commit yang Anda buat tidak boleh dirujuk dalam master branch. Silakan, cobalah. Edit index.html dan membuat perubahan kecil:

Kemudian, melakukan pekerjaan Anda.

Sekarang kami telah membuat kami komit pertama di timeline baru ini. Ide kami fiksi masih perlu bekerja, tapi kami dalam perjalanan! Namun, sekarang, seorang pelanggan hanya melaporkan kesalahan ketik yang kita butuhkan untuk memperbaiki sesegera mungkin. Karena kita dengan benar menggunakan cabang, kita dapat kembali ke master branch, memperbaiki kesalahan ketik, dan menyebarkan.

Setelah fitur ide kami selesai, sekarang saatnya untuk bergabung kembali ke master branch.

Jika semua berjalan sesuai rencana, cabang fitur Anda akan berhasil digabung kembali ke branch master, menyelesaikan kedua 1985 timeline alternatif!

Yang mengatakan, Anda pasti akan menemukan situasi, ketika Git tampaknya tanaman kakinya ke tanah, dan menolak untuk terus seperti yang diminta. Dalam kasus ini, Git tidak menjadi brengsek tanpa alasan! Kemungkinan besar, masalah yang berkaitan dengan beberapa konflik yang pertama perlu diselesaikan, sebelum Git dapat melanjutkan. Bayangkan mencoba untuk menggabungkan file kembali ke master branch; satu-satunya masalah adalah bahwa, karena cabang diciptakan, file telah diedit di kedua fitur cabang, serta master. Dalam situasi seperti ini, bagaimana bisa Git mungkin tahu yang versi dari file harus mengambil precendence, ketika menggabungkan dua? Tidak, dan ini adalah apa yang kita sebut konflik.

Sebelum Git dapat melanjutkan, Anda harus menyelesaikan konflik, dengan mengedit index.html.


Mengabaikan berkas

Ada kemungkinan akan titik, ketika Anda menentukan bahwa itu terbaik untuk tidak melacak jenis file tertentu dengan Git. Contoh mungkin mencakup umum. DS_STORE (pengguna Mac yang akan akrab dengan), membangun direktori, dan sementara aset dikompilasi.

Mudah cukup, Git, melalui berkas .gitignore, memungkinkan kita untuk mengabaikan jenis file tertentu. Untuk memanfaatkan ini, membuat berkas .gitignore baru di root (namun tidak terbatas pada) proyek Anda. Di dalamnya, memberikan daftar file atau jenis file untuk mengabaikan. Berikut adalah contoh dasar:


Coding sosial

GitHub membuat sosial pengkodean mungkin.

Sejauh ini, Anda telah belajar bagaimana melakukan kode lokal. Tapi, bagaimana bisa modifikasi ini dibagi dengan tim Anda, atau seluruh dunia? Masukkan GitHub.

GitHub memungkinkan Anda untuk berbagi kode Anda dengan dunia. Ini adalah komunitas sumber terbuka terbesar di keberadaan.

Sekali Anda mendaftar untuk account baru di github.com, Anda akan perlu untuk mengikuti beberapa langkah untuk menghasilkan sebuah kunci khusus, untuk menghubungkan komputer Anda dengan akun GitHub. Jangan khawatir; Jika Anda mengikuti langkah-langkah, Anda seharusnya tidak memiliki masalah.

Pada titik ini, kita dapat membuat repositori baru, dan mendorong proyek kecil kami, untuk berbagi dengan dunia. Setelah log in, klik tombol "Repositori baru", memberi repo Anda nama, dan klik "Buat repositori." Selanjutnya, Anda akan disajikan dengan beberapa perintah yang dapat disisipkan ke Terminal. Seperti kita sudah memiliki repo yang ada, kita perlu pilihan kedua:

Ini memerintahkan Git untuk menambah repositori berjarak kami baru, dan alias sebagai "asal." Selanjutnya, kita mendorong Cabang master (bukan ide satu) untuk remote dengan alias "asal."

That's it! Kembali ke browser, refresh halaman, dan Anda akan menemukan repositori baru segar, menunggu untuk digunakan bersama dengan seluruh dunia.

Ketika anggota lain dari tim Anda ingin menarik dalam perubahan yang Anda buat, mereka hanya perlu menjalankan:

Perintah ini akan menarik di update terbaru yang telah mendorong GitHub! Selain berbagi kode, GitHub juga menawarkan kemampuan untuk melacak dan berkontribusi dalam proyek sumber terbuka populer, serta pelacak isu untuk bug dan permintaan fitur. It's sosial pengkodean yang terbaik!


Pikiran penutup

Meskipun kita hanya menggores permukaan dari apa Git mampu, kebenaran adalah bahwa, sekali lagi, 80% dari penggunaan Git Anda, teknik-teknik yang direferensikan dalam artikel ini akan cukup. Membuat cabang fitur, menulis beberapa kode, menambahkannya ke staging area, dan melakukan hal itu dengan pesan. Bila sudah siap, menggabungkan kembali ke master branch, dan menyebarkan! Selanjutnya, bilas dan ulangi!

Jangan lupa: ketika bingung, StackOverflow adalah teman terbaik Anda. Apapun masalahnya mungkin, orang lain telah dalam situasi yang sama persis. Cari tidak pertama.

TryGit menawarkan pengalaman interaktif untuk belajar Git.

Belajar lebih lanjut

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.