Anda sudah menggunakan source control untuk mengelola kode Anda, bukan? Anda bahkan mungkin menggunakan SCM Anda sebagai bagian inti dari alur kerja Anda, seperti yang kami lakukan di New Relic.

Dalam artikel ini, kami tidak akan meninjau dasar-dasar pengelolaan source control, terlepas dari mana yang Anda gunakan. Anggap saja Anda sudah tahu cara berkeliling. Apa yang akan kita bahas adalah bagaimana pro menggunakan git. Kita akan melihat beberapa fitur dan alur kerja lanjutan yang mungkin belum Anda kenal. Mudah-mudahan, Anda akan pergi dengan mulut ternganga karena kemungkinan-kemungkinan yang diberikan oleh git!

Jika Anda seperti saya, Anda suka menjelajahi cara kerja pengembang lain.

Untuk yang tidak tahu, atau yang berasal dari SCM lain, Git adalah sistem kontrol versi terdistribusi. Ini gratis dan open source, memiliki footprint kecil, dan bisa masuk dalam alur kerja yang paling cocok untuk Anda. Secara umum, itu tidak memaksa Anda untuk bekerja dengan cara tertentu, yang berarti ada banyak metodologi yang berbeda tentang cara menggunakan fitur-fiturnya, seperti staging, branching dan tagging release. Jika Anda seperti saya, Anda suka menjelajahi cara kerja pengembang lain. Jadi bersiap-siap untuk mulai memodifikasi .gitconfig Anda, karena Anda sedang dalam perawatan. Mari kita lihat bagaimana para pro menggunakan git.

Stage Perubahan Anda di Hunks

Anda mungkin akrab dengan tidak sengaja memodifikasi file tunggal karena dua alasan yang berbeda tanpa melakukan di antaranya.

Anda tentu akrab dengan menambahkan file ke area stage dengan perintah add. Dan Anda mungkin akrab dengan tidak sengaja memodifikasi file tunggal karena dua alasan yang berbeda tanpa melakukan di antaranya. Jadi Anda pasti akan memiliki git log yang berisi pesan seperti "Edit X dan ubah Y yang tidak terkait". Jika ini terdengar seperti alur kerja Anda, maka penambahan interaktif adalah teman terbaik Anda yang baru.

Menambahkan secara interaktif, atau menambahkan tambalan, menuntun Anda melalui perubahan satu bongkahan sekaligus. Saat Anda menambahkan file dengan perintah -p, Anda akan diminta pada setiap perubahan logis (yaitu, baris yang diedit secara beruntun akan dikelompokkan bersama). Ada sejumlah pilihan yang dapat Anda buat pada setiap hunk, mulai dari membagi hunk yang sekarang menjadi yang lebih kecil, skipping hunk, atau bahkan mengeditnya secara manual. Menggunakan ? pilihan untuk melihat daftar perintah lengkap.

Memulai staging hunk sesederhana ini:

git add -p <FILE>

Checkout Cabang Terakhir Anda

Sebagai warga pengkodean yang baik, ketika Anda menemukan sesuatu yang membutuhkan perbaikan atau pembersihan cepat, Anda mungkin harus meluangkan waktu sejenak untuk mengubahnya. Tetapi jika Anda menggunakan alur kerja fitur-cabang yang berat, maka Anda tidak ingin perbaikan yang tidak terkait di cabang fitur Anda. Ini berarti Anda harus stash perubahan Anda saat ini, ganti ke cabang master Anda dan kemudian perbaiki di sana. Terpental di antara cabang bisa membosankan, tetapi, untungnya, ada pintasan cepat untuk beralih ke cabang terakhir Anda. (via Zach Holman)

git checkout -

Sintaks ini harus terlihat akrab bagi * pengguna NIX. Perintah cd memiliki shortcut yang sama (cd -) yang akan melompat ke direktori terakhir Anda. Anda tidak perlu mengingat apa yang Anda beri nama cabang fitur tersebut ketika Anda perlu beralih kembali; hanya git checkout -.

Tampilkan Cabang mana yang Digabung (atau tidak)

Ketika bekerja dengan cabang-cabang fitur, Anda dapat dengan cepat membuat begitu banyak yang mengacaukan keluaran dari git branch --list. Sesekali Anda ingin menyingkirkan cabang-cabang yang telah membuatnya menjadi tuan. Tapi Anda mungkin memiliki jeda cepat sebelum Anda git branch -d <BRANCH> , tetapi dengan perintah di bawah ini Anda dapat menghapusnya tanpa berpikir panjang. (via Zach Holman)

Jika Anda ingin melihat cabang lokal mana yang Anda miliki yang digabungkan ke dalam cabang tempat Anda berada saat ini, maka yang Anda perlukan hanyalah:

git branch --merged

Kebalikannya juga tersedia. Tampilkan cabang mana yang belum digabungkan ke dalam cabang yang dipilih saat ini dengan:

git branch --no-merged

Hancurkan ini dengan beberapa alat UNIX yang mudah dan Anda dapat dengan cepat menghapus semua yang telah digabungkan:

git branch --merged | xargs git branch -d

Ambil File dari Cabang Lain tanpa Mengganti Cabang

Katakanlah Anda sedang bereksperimen dengan beberapa refactorings, dan Anda memiliki beberapa cabang yang memiliki berbagai perubahan yang Anda buat. Jika Anda memiliki perubahan dalam file di beberapa cabang yang jauh yang ingin Anda bawa ke dalam cabang kerja Anda saat ini, maka Anda dapat melakukan sejumlah langkah. Tanpa tip di bawah, Anda mungkin akan menyimpan perubahan Anda saat ini, beralih cabang dan mengambil konten file yang ingin Anda ubah, beralih kembali (dengan git checkout - tentu saja) dan melakukan pengeditan Anda. Atau Anda hanya dapat checkout file yang akan menggabungkannya ke dalam cabang Anda saat ini (via Zach Holman):

git checkout <BRANCH> -- path/to/file.rb

Cabang Git Diurut berdasarkan Komit Terakhir

Jadi Anda punya daftar cabang yang berantakan yang kita bicarakan sebelumnya; beberapa dari mereka yang telah Anda bersihkan dengan --merged Tetapi bagaimana dengan semua cabang lainnya? Bagaimana Anda tahu mana yang berguna atau benar-benar ketinggalan zaman? Perintah for-each-ref akan menampilkan daftar untuk setiap cabang dan menunjukkan informasi referensi untuk commit terakhir. Kami dapat menyesuaikan output untuk menyertakan beberapa informasi yang berguna, tetapi yang lebih penting, kita dapat mengurutkan daftar berdasarkan tanggal. Perintah ini akan memberi kita daftar cabang dengan pesan komit dan komit terakhir, diurutkan dalam urutan tanggal descending. (via Rein Henrichs)

git for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) [%(committername)]'

Meskipun Anda dapat mengetikkan perintah ini setiap kali, saya sangat merekomendasikan menjadikannya sebagai alias dan menyelamatkan diri Anda dari sakit kepala yang serius.

git config --global alias.latest "for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) [%(committername)]'"

Orang-orang di Rumah Kaca Tidak Harus Menggunakan Git Blame

Atau setidaknya mereka tidak boleh menggunakan git blame tanpa salah satu flag opsi di bawah ini. Git blame sangat kuat; pada dasarnya seperti menggunakan sains untuk membuktikan bahwa Anda benar. Tapi hati-hati, banyak perubahan yang dangkal dan untuk menemukan sumber nyata dari kode pertanyaan membutuhkan lebih banyak perburuan. Hal-hal seperti menghapus spasi, memindahkan teks ke baris baru, atau bahkan memindahkan teks dari file lain dapat diabaikan untuk mendapatkan ke penulis asli dari kode jauh lebih mudah.

Sebelum Anda melakukan git blame, pastikan Anda memeriksa salah satu dari ini:

git blame -w  # ignores white space
git blame -M  # ignores moving text
git blame -C  # ignores moving text into other files

Temukan String di Seluruh Riwayat Git (dan Menghapusnya)

Dari waktu ke waktu, Anda perlu memburu baris kode yang Anda tahu Anda tulis tetapi tidak dapat ditemukan. Itu bisa terjebak di beberapa cabang yang jauh, dihapus lama sekali, atau bersembunyi di situs biasa; tetapi dengan cara apa pun Anda dapat menemukan string apa pun di seluruh riwayat git Anda dengan menumbuk beberapa perintah. Pertama, kita akan mendapatkan daftar semua commit, dan kemudian grep masing-masing untuk string kita.

git rev-list --all | xargs git grep -F '<YOUR STRING>'

Anda mungkin memiliki teman yang tidak sengaja membuat data sensitif ke repo: kunci akses, kata sandi, resep rahasia marinara nenek Anda. Hal pertama yang harus mereka lakukan adalah mengubah kata sandi mereka dan mencabut akses dengan kunci tersebut (dan meminta maaf kepada nenek Anda). Selanjutnya, Anda akan ingin memburu file yang menyinggung dan menghapusnya dari seluruh sejarah git, yang terdengar jauh lebih mudah daripada yang sebenarnya. Setelah proses ini selesai, siapa pun yang menarik dalam perubahan yang dibersihkan akan menghapus data sensitif juga. Fork repo Anda yang tidak menggabungkan perubahan hulu Anda masih akan berisi file yang disusupi (jadi jangan lewati mengubah kata sandi dan mencabut kunci akses).

Pertama, kami akan menulis ulang sejarah git untuk setiap cabang, menghapus file dengan data sensitif.

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <FILENAME>' --prune-empty --tag-name-filter cat -- --all

Tambahkan file ke .gitignore dan komit untuk memperbarui .gitignore.

echo <FILENAME> >> .gitignore
git add .gitignore
git commit -m "Add sensitive <FILENAME> file to gitignore"

Karena kita menulis ulang riwayat, Anda harus push perubahan ke remote.

git push origin master --force

File yang dikompromikan masih ada di repo lokal Anda, jadi Anda harus melakukan beberapa tugas pembersihan untuk membersihkannya sepenuhnya.

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

Repo teman Anda harus bebas dari data sensitif dan Anda akan menjadi pahlawan untuk membantu mereka dengan pengetahuan pro git Anda. (melalui StackOverflow dan GitHub)

Abaikan Perubahan File yang Dilacak

Bekerja dengan kode orang lain di lingkungan Anda dapat berarti bahwa Anda perlu membuat sejumlah perubahan konfigurasi untuk menjalankan aplikasi. Terlalu mudah untuk secara tidak sengaja melakukan perubahan pada konfigurasi yang dimaksudkan khusus untuk lingkungan Anda. Jadi, daripada selalu mengawasi file-file itu dan membiarkannya tetap berada di area stage "modified" , Anda dapat dengan mudah memberi tahu indeks git untuk mengabaikan perubahan pada file itu. Anda dapat menganggap ini agak seperti file yang diabaikan git yang tetap dengan repo. (via Arnaud Coomans)

git update-index --assume-unchanged <FILENAME>

Zero Out a Branch's History

Terkadang memulai dari awal adalah hal yang perlu Anda lakukan, karena sejumlah alasan. Mungkin Anda telah mewarisi basis kode yang tidak dapat Anda pastikan aman untuk open source, mungkin Anda hanya akan mencoba sesuatu yang benar-benar baru, atau mungkin Anda menambahkan cabang yang melayani tujuan terpisah yang ingin Anda pertahankan dengan repo (seperti GitHub Pages). Untuk kasus ini, ada cara yang sangat sederhana untuk membuat cabang baru di repo Anda yang pada dasarnya tidak memiliki riwayat. (via Nicola Paolucci)

git checkout --orphan <NEWBRANCH>

Alias, Anda Tidak Bisa Hidup Tanpanya

Berhenti membuang waktu mengetik perintah panjang dan buatlah diri Anda sendiri beberapa alias yang berguna.

Tidak ada diskusi tentang git akan lengkap tanpa berbicara tentang berbagai alias yang secara harfiah akan menghemat menit Anda dalam satu tahun keystrokes disimpan. Berhenti membuang waktu mengetik perintah panjang dan buatlah diri Anda sendiri beberapa alias yang berguna. Alias dapat dibuat dengan menambahkannya ke file .gitconfig Anda atau menggunakan baris perintah git config --global alias.<NAME> "<COMMAND>". Di bawah ini hanya contoh alias yang dapat Anda gunakan sebagai batu loncatan untuk ide.

co: dengan alur kerja fitur cabang, Anda akan berpindah antar cabang secara teratur. Hemat enam karakter setiap saat.

co = checkout

ds: selalu praktik terbaik untuk meninjau perubahan yang akan Anda lakukan sebelum membuat komitmen yang sebenarnya. Ini memungkinkan Anda untuk menangkap kesalahan ketik, memasukkan data sensitif secara tidak disengaja, dan mengelompokkan kode ke dalam kelompok-kelompok logis. Panggung perubahan Anda dan kemudian gunakan git ds untuk melihat diff dari perubahan tersebut.

ds = diff --staged

st: Anda harus cukup akrab dengan output status git yang verbose. Pada titik tertentu Anda akan ingin melewatkan semua formalitas dan turun ke bisnis. Alias ini menunjukkan bentuk singkat status dan menyertakan detail cabang.

st = status -sb

amend: apakah Anda lupa menyertakan file dengan commit terakhir Anda, atau mungkin Anda memiliki satu tweak yang perlu Anda buat? Ubah perubahan bertahap pada komitmen terakhir Anda.

amend = commit --amend -C HEAD

undo: terkadang, mengubah komit terakhir Anda tidak cukup dan Anda harus membatalkannya. Alias ini akan mundur satu commit dan membiarkan perubahan dari commit yang dilakukan. Sekarang Anda dapat melakukan perubahan tambahan, atau kembali dengan pesan baru.

undo = reset --soft HEAD^

ls: bekerja pada basis kode dengan sekelompok pengembang berarti berusaha mengikuti apa yang dikerjakan oleh orang-orang. Alias ini akan memberikan git log satu baris termasuk tanggal dan nama komuter.

ls = log --pretty=format:"%C(yellow)%h %C(blue)%ad%C(red)%d %C(reset)%s%C(green) [%cn]" --decorate --date=short

standup: alias ini sangat bagus untuk meninjau apa yang Anda kerjakan kemarin untuk setiap jenis standup harian, atau hanya untuk menyegarkan ingatan Anda di pagi hari.

standup = log --since '1 day ago' --oneline --author <YOUREMAIL>

graph: riwayat git yang kompleks dapat sulit untuk ditinjau dalam garis lurus. Menggunakan bendera grafik menunjukkan Anda bagaimana dan kapan komit ditambahkan ke cabang saat ini.

graph = log --graph --pretty=format':%C(yellow)%h%Cblue%d%Creset %s %C(white) %an, %ar%Creset'

Kesimpulan

Git dapat menjadi sangat sederhana dan membingungkan. Anda dapat mulai dengan dasar-dasar dan bekerja sendiri menjadi manipulasi grafik yang lebih kompleks dari waktu ke waktu. Tidak perlu menghapal semua itu sebelum Anda dapat menggunakannya. Perintah yang paling kuat saat Anda pelajari adalah man git-<command>-<name>. Coba gunakan sebelum Anda merujuk ke Google untuk sebuah jawaban.

Anda dapat mempelajari lebih lanjut tentang bagaimana perusahaan tempat saya bekerja untuk Anda, New Relic, menggunakan git di blog kami, atau memberi New Relic Pro percobaan gratis. Terima kasih sudah membaca! Jika Anda memiliki pertanyaan, beri tahu kami di bawah ini!