Git Reset Soft: Panduan Lengkap dengan Contoh

Langkah demi Langkah: Menggunakan Git Reset Soft

Menguasai penerapan praktis soft reset membutuhkan pemahaman mekanismenya dan alur kerja di mana ia memberikan nilai terbesar. Izinkan saya memandu Anda melalui teknik-teknik esensial yang telah menjadi naluri dalam proses pengembangan saya.

Alur kerja langkah demi langkah untuk menggunakan perintah git reset --soft.

Melakukan soft reset ke commit tertentu

Sintaks dasar soft reset itu sederhana: git reset --soft <commit>. Tantangannya ada pada mengidentifikasi commit target yang benar dan memahami hasilnya. Berikut alur kerja khas saya:

git log --oneline -10
git reset --soft m0n1o2p
git statusDidukung oleh

Saya mulai dengan git log --oneline -10 untuk melihat riwayat commit terbaru dalam format ringkas. Setelah mengidentifikasi commit target, saya menjalankan git reset --soft m0n1o2p. Perintah ini memundurkan penunjuk branch saya sambil mempertahankan semua pekerjaan dari commit yang lebih baru. Terakhir, git status mengonfirmasi bahwa semua perubahan dari commit yang di-reset kini di-stage dan siap untuk di-commit ulang.

Berikut kiat yang saya pelajari dari mentor di awal karier: selalu gunakan git log --oneline terlebih dahulu untuk mendapatkan gambaran visual riwayat commit. Saya juga sering menggunakan git log --graph --oneline --all saat bekerja dengan banyak branch untuk memahami hubungan antar lini pengembangan.

Anda juga dapat menggunakan referensi relatif seperti HEAD~2 untuk mundur dua commit dari posisi saat ini. Saya merasa ini sangat berguna untuk operasi cepat: git reset --soft HEAD~1 mungkin adalah perintah yang paling sering saya ketik, karena membatalkan commit terakhir saja sambil menjaga semuanya tetap di-stage untuk percobaan ulang.

Memperbaiki commit terbaru (amend)

Salah satu penerapan paling praktis dari soft reset adalah memperbaiki commit terbaru, baik Anda perlu menyesuaikan pesan commit, menambahkan perubahan yang terlupa, atau menata ulang struktur commit. Alur kerja ini berkali-kali menyelamatkan saya dari rasa malu.

git log -1
git reset --soft HEAD~1
git add forgotten_file.py
git commit -m "Implement user authentication with proper validation

- Add login/logout endpoints
- Include password validation logic
- Add forgotten error handling module
- Update tests for new authentication flow"Didukung oleh

Saya baru saja commit tetapi lupa menyertakan file penting. Saya menggunakan git log -1 untuk meninjau commit yang belum lengkap, lalu git reset --soft HEAD~1. Perintah ini membatalkan commit sambil menjaga semua perubahan tetap di-stage. Setelah menambahkan file yang terlupa dengan git add forgotten_file.py, saya membuat commit baru yang mencakup semuanya dengan pesan commit yang tepat.

Alur kerja ini sudah seperti refleks bagi saya. Saya mungkin menggunakan pola ini beberapa kali seminggu, terutama saat saya dalam kondisi fokus dan sering melakukan commit. Ada kepuasan tersendiri bisa membereskan pekerjaan secara retroaktif—seperti memiliki tombol "undo" untuk version control Anda.

Saya juga mendapati teknik ini sangat berguna saat bekerja dengan konvensi pesan commit. Banyak tim menggunakan format seperti Conventional Commits, dan jika saya sadar tidak mengikuti formatnya dengan benar, soft reset cepat memungkinkan saya memperbaikinya tanpa membuat commit tambahan.

Memecah commit besar

Commit besar melanggar prinsip perubahan atomik dan menyulitkan code review. Soft reset menyediakan solusi elegan untuk memecah commit berukuran besar menjadi bagian-bagian yang logis dan mudah direview. Ini salah satu teknik yang paling meningkatkan kualitas umpan balik code review saya selama bertahun-tahun.

git log --oneline -3
git reset --soft HEAD~1
git status
git reset
git add models/user.py
git commit -m "Add user model with validation rules"
git add controllers/user_controller.py
git commit -m "Implement user CRUD operations"
git add tests/test_user_model.py tests/test_user_controller.py
git commit -m "Add comprehensive user model and controller tests"
git add templates/user/ static/css/user.css
git commit -m "Add user interface templates and styling"Didukung oleh

Saya mulai dengan git log --oneline -3 untuk mengidentifikasi commit yang terlalu besar, lalu menggunakan git reset --soft HEAD~1. Perintah ini membatalkan commit sambil menjaga perubahan tetap di-stage. Menjalankan git reset (tanpa flag) menghapus staging semuanya, memberi saya titik awal yang bersih. Sekarang saya bisa membuat commit terfokus: model terlebih dahulu, lalu controller, lalu test, dan akhirnya komponen UI. Pendekatan ini mengubah satu commit masif menjadi bagian-bagian yang logis dan mudah direview.

Pendekatan ini telah mengubah bagaimana reviewer merespons pull request saya. Alih-alih mendapatkan masukan seperti "Commit ini terlalu besar untuk direview secara efektif," kini saya mendapat umpan balik spesifik dan dapat ditindaklanjuti pada setiap komponen logis dari perubahan saya.

Satu hal yang saya pelajari adalah memikirkan cerita yang disampaikan commit saya. Setiap commit harus mewakili satu pemikiran lengkap yang masuk akal dengan sendirinya. Jika saya tidak bisa menjelaskan apa yang dilakukan sebuah commit dalam satu kalimat yang jelas, kemungkinan commit itu terlalu besar dan perlu dipecah.

Kompresi riwayat (squashing)

Ketika Anda membuat banyak commit kecil selama pengembangan—memperbaiki typo, menanggapi komentar review, atau membuat kemajuan inkremental—menggabungkannya menjadi satu commit yang rapi menghasilkan riwayat yang lebih bersih. Teknik ini menjadi esensial dalam alur kerja saya, terutama saat mengerjakan fitur selama beberapa hari.

git log --oneline -6
git reset --soft HEAD~5
git status
git commit -m "Implement comprehensive user registration system

- Add user registration endpoint with validation
- Include password strength requirements
- Add comprehensive test coverage
- Update documentation with usage examples"Didukung oleh

Saya menggunakan git log --oneline -6 untuk melihat riwayat pengembangan yang berantakan, lalu git reset --soft HEAD~5. Perintah ini menggabungkan lima commit inkremental sambil otomatis men-stage semua pekerjaan. Menjalankan git status menunjukkan semuanya siap untuk di-commit ulang. Saya lalu membuat satu commit rapi dengan pesan profesional yang menjelaskan fitur lengkap, bukan perjalanan debuggingnya.

Saya sangat suka menggunakan teknik ini sebelum menggabungkan feature branch. Ini memungkinkan saya memiliki commit yang granular selama pengembangan (yang membantu debugging dan pelacakan progres) sekaligus menyajikan riwayat yang bersih dan profesional ke main branch.

Salah satu alur kerja yang saya kembangkan adalah menggunakan konvensi penamaan untuk commit yang masih dalam pengerjaan. Saya gunakan awalan seperti "WIP:" atau "temp:" untuk commit yang saya tahu akan saya squash nanti. Ini memudahkan mengidentifikasi commit "bercerita" versus commit "checkpoint".

Mendorong perubahan (push) setelah soft reset

Setelah menulis ulang riwayat lokal dengan soft reset, mendorong ke repository remote memerlukan pertimbangan cermat. Karena Anda telah mengubah struktur commit, Git akan menolak operasi push biasa. Di sinilah pemahaman force-push yang aman menjadi krusial.

git push origin feature-branch
git push --force-with-lease origin feature-branchDidukung oleh

Setelah menulis ulang riwayat, git push origin feature-branch biasa akan gagal dengan error "non-fast-forward". Saya menggunakan git push --force-with-lease origin feature-branch sebagai gantinya. Perintah ini melakukan force-push dengan aman sambil memastikan tidak ada orang lain yang memperbarui branch sejak fetch terakhir saya.

Opsi --force-with-lease telah menyelamatkan tim saya dari beberapa bencana. Ini memberi keamanan dengan memastikan tidak ada orang lain yang telah mendorong commit ke branch sejak fetch terakhir Anda. Ini mencegah secara tidak sengaja menimpa pekerjaan kolaborator—kesalahan yang dapat merusak hubungan tim dan stabilitas proyek.

Saya belajar tentang --force-with-lease dengan cara yang tidak menyenangkan setelah tanpa sengaja menimpa pekerjaan rekan tim dengan force push biasa. Percakapan setelahnya... tidak nyaman. Sejak itu, saya menjadikan --force-with-lease sebagai default untuk operasi force push apa pun, dan saya merekomendasikan hal yang sama bagi siapa pun yang bekerja pada repository bersama.

Aplikasi Praktis dan Contoh

Alur kerja Git di dunia nyata menghadirkan skenario di mana soft reset menjadi tak tergantikan. Izinkan saya berbagi beberapa contoh dari pengalaman pengembangan saya yang menunjukkan cara menangani situasi umum yang akan Anda temui di lingkungan profesional

Mengubah commit berantakan dengan git reset --soft.

Membatalkan commit terakhir namun tetap menyimpan perubahan

Ini adalah use case paling sering untuk soft reset dalam alur kerja harian saya, ketika Anda melakukan commit terlalu dini atau dengan pesan commit yang kurang memadai. Saya mungkin melakukannya setidaknya sekali per hari.

git log -1
git reset --soft HEAD~1
git status
git commit -m "Fix authentication middleware edge case handling

- Resolve null pointer exception when user session expires
- Add proper error handling for malformed JWT tokens  
- Include additional test coverage for session timeout scenarios
- Update error messages to be more user-friendly"Didukung oleh

Ketika saya melihat pesan commit yang memalukan seperti "fix stuff" setelah menjalankan git log -1, saya gunakan git reset --soft HEAD~1. Perintah ini membatalkan commit sambil menjaga perubahan tetap di-stage. Lalu git status mengonfirmasi semuanya siap, dan saya dapat commit lagi dengan pesan profesional yang benar-benar menjelaskan apa yang saya perbaiki.

Alur kerja ini menyelamatkan saya dari pesan commit seperti "asdf," "temp," atau "fix" tercatat permanen dalam riwayat proyek. Pesan commit yang profesional itu penting; mereka berfungsi sebagai dokumentasi bagi developer di masa depan (termasuk diri Anda) yang mencoba memahami mengapa perubahan dibuat.

Saya mengembangkan aturan untuk diri sendiri: jika saya tidak bisa menulis pesan commit yang jelas menjelaskan "mengapa" di balik perubahan saya, kemungkinan commit itu belum siap. Soft reset memberi saya kebebasan untuk commit lebih awal dan sering selama pengembangan sambil tetap menjaga standar profesional dalam riwayat akhir.

Membatalkan beberapa commit

Terkadang Anda perlu memutar balik beberapa commit untuk menata ulang serangkaian perubahan terkait atau mengakomodasi masukan yang memengaruhi beberapa commit. Skenario ini sering muncul selama siklus code review.

git log --oneline -8
git reset --soft HEAD~4
git status
git commit -m "Refactor user authentication system based on security review

This consolidates the previous authentication improvements into a single
cohesive implementation that addresses all security concerns raised
during code review."Didukung oleh

Ketika masukan code review memengaruhi beberapa commit, saya menggunakan git log --oneline -8 untuk mengidentifikasi commit mana yang perlu ditata ulang, lalu git reset --soft HEAD~4. Perintah ini membatalkannya sambil menjaga perubahan tetap di-stage. Setelah menjalankan git status untuk memastikan semuanya siap, saya membuat satu commit yang menangani seluruh masukan dalam satu implementasi yang koheren.

Saya ingat satu code review yang menantang di mana tim keamanan mengidentifikasi masalah yang membentang di tiga commit berbeda pada fitur autentikasi saya. Alih-alih membuat commit "fix" tambahan, saya menggunakan teknik ini untuk menggabungkan masukan mereka dan menyajikan implementasi yang telah dikoreksi sebagai satu commit bersih. Reviewer menghargai karena tidak perlu melacak perbaikan di banyak commit.

Pendekatan ini sangat berharga saat Anda telah bereksperimen dengan berbagai implementasi dan ingin menyajikan solusi final tanpa menampilkan semua commit coba-coba yang mengantarkan ke sana.

Mereset satu file di index

Meskipun tidak spesifik untuk soft reset, memahami operasi reset tingkat file melengkapi alur kerja soft reset Anda dan memberi kontrol bedah atas staging area.

git add user_model.py user_controller.py debug_helper.py
git status
git reset debug_helper.py
git statusDidukung oleh

Setelah men-stage beberapa file dengan git add user_model.py user_controller.py debug_helper.py, saya sadar file debug tidak boleh disertakan. Saya gunakan git reset debug_helper.py. Perintah ini menghapus staging hanya untuk file tersebut, membiarkan file lain tetap di-stage. Menjalankan git status mengonfirmasi unstage selektif berhasil.

Tingkat kontrol yang granular ini menjadi esensial dalam alur kerja saya. Saya sering mendapati diri men-stage lebih banyak file daripada yang saya niatkan, dan kemampuan untuk menghapus staging file secara selektif tanpa memengaruhi riwayat commit memungkinkan saya menyusun commit yang presisi.

Saya juga mendapati ini berguna saat bekerja dengan file yang dihasilkan otomatis atau ketika IDE saya tanpa sengaja menyertakan file yang tidak saya maksud untuk di-commit. Ini jauh lebih rapi dibanding menghapus staging semuanya dan me-restage secara selektif.

Menyimpan perubahan di working tree sambil membuang commit sebelumnya

Skenario ini terjadi ketika Anda ingin menghilangkan commit dari riwayat sambil mempertahankan perubahan kode aktual untuk kemungkinan integrasi ulang. Saya menggunakan teknik ini saat menyadari struktur commit saya tidak menceritakan kisah yang tepat.

git log --oneline -4
git reset --soft HEAD~3
git reset
git add backend/
git commit -m "Implement backend API changes for user profile feature"
git add frontend/
git commit -m "Update frontend components for user profile display"Didukung oleh

Ketika saya memiliki commit frontend/backend yang tercampur dan seharusnya ditata berbeda, saya menggunakan git log --oneline -4 untuk melihat riwayat yang berantakan, lalu git reset --soft HEAD~3. Perintah ini menghilangkan commit sambil menjaga perubahan tetap di-stage. Menjalankan git reset (tanpa flag) menghapus staging semuanya, memungkinkan saya menata ulang dengan menambahkan file backend terlebih dahulu, lalu file frontend sebagai commit logis yang terpisah.

Alur kerja ini sangat berharga saat mengerjakan fitur full-stack di mana awalnya saya meng-commit perubahan frontend dan backend bersama, tetapi kemudian menyadari keduanya sebaiknya dipisah agar lebih mudah direview dan berpotensi di-rollback.

Membagi satu commit menjadi beberapa commit kecil

Memecah commit meningkatkan kualitas code review dan membuat debugging di masa depan lebih presisi. Teknik ini secara signifikan meningkatkan umpan balik yang saya terima pada pull request.

git show --name-only HEAD
git reset --soft HEAD~1
git reset
git add models/user_profile.py
git commit -m "Add user profile model with validation"
git add api/user_profile_endpoints.py  
git commit -m "Implement user profile API endpoints"
git add tests/test_user_profile.py
git commit -m "Add comprehensive user profile tests"
git add frontend/components/UserProfile.js
git add frontend/styles/user-profile.css
git commit -m "Add user profile frontend components and styling"Didukung oleh

Saya menggunakan git show --name-only HEAD untuk melihat file apa yang berubah pada commit besar, lalu git reset --soft HEAD~1. Perintah ini membatalkan commit sambil menjaga perubahan tetap di-stage. Menjalankan git reset (tanpa flag) menghapus staging semuanya. Sekarang saya dapat membuat commit terfokus: model terlebih dahulu, lalu endpoint API, lalu test, lalu komponen frontend. Pendekatan ini mengubah satu commit besar yang membingungkan menjadi bagian-bagian yang logis dan mudah direview.

Transformasinya luar biasa. Alih-alih reviewer harus memahami commit besar yang menyentuh banyak concern, mereka bisa mereview setiap bagian logis secara terpisah. Ini menghasilkan umpan balik yang lebih baik, review lebih cepat, dan lebih sedikit bug yang lolos ke produksi.

Saya perhatikan ketika saya meluangkan waktu untuk membagi commit dengan benar, reviewer lebih mungkin menangkap isu halus karena mereka bisa fokus pada satu concern pada satu waktu alih-alih kewalahan oleh set perubahan besar.

Praktik Terbaik Menggunakan Git Reset Soft

Alur kerja Git profesional memerlukan praktik disiplin untuk mencegah kehilangan data dan menjaga produktivitas tim. Pedoman ini mewakili pelajaran dari bertahun-tahun mengelola proyek kompleks dan, terus terang, dari beberapa kesalahan mahal di sepanjang jalan.

Protokol keamanan

Sebelum melakukan operasi reset apa pun, saya selalu menyiapkan jaring pengaman yang memungkinkan pemulihan dari kesalahan. Kebiasaan ini berkembang setelah insiden yang cukup menyakitkan di awal karier ketika saya kehilangan beberapa jam kerja.

git branch backup-before-reset-$(date +%Y%m%d-%H%M%S)
git reset --soft HEAD~3
git reset --hard backup-before-reset-20250905-182003Didukung oleh

Saya selalu membuat branch cadangan sebelum operasi berisiko menggunakan git branch backup-before-reset-$(date +%Y%m%d-%H%M%S). Perintah ini membuat jaring pengaman bertimestamp. Jika terjadi sesuatu yang salah setelah operasi reset, saya bisa memulihkan dengan git reset --hard backup-before-reset-20250905-182003.

git status
git log --oneline -10
git diff --stagedDidukung oleh

Setelah operasi reset, saya memverifikasi semuanya dengan git status untuk memeriksa staging, git log --oneline -10 untuk meninjau riwayat commit, dan git diff --staged. Perintah terakhir ini menunjukkan dengan tepat apa yang akan disertakan dalam commit berikutnya.

Aturan terpenting yang saya ikuti: jangan pernah melakukan operasi reset pada commit yang telah dibagikan dengan orang lain kecuali saya memiliki koordinasi eksplisit dengan tim. Aturan ini telah mencegah banyak konflik dan menjaga kepercayaan tim.

Salah satu teknik yang saya kembangkan adalah menggunakan nama branch deskriptif yang menunjukkan status work-in-progress. Misalnya, feature/user-auth-wip jelas memberi sinyal kepada anggota tim bahwa riwayat branch ini mungkin berubah.

Keterbatasan dan jebakan

Soft reset menangani file yang dilacak dengan baik, tetapi ada beberapa nuansa yang dapat menjebak developer. Memahami keterbatasan ini membantu saya menghindari kebingungan dan perilaku yang tidak terduga.

git reset --soft HEAD~2
git status
git add .Didukung oleh

Ketika saya menggunakan git reset --soft HEAD~2, menjalankan git status menunjukkan semuanya siap. Perintah ini membatalkan dua commit sambil menjaga perubahan tetap di-stage. Saya kemudian dapat menggunakan git add . untuk men-stage modifikasi tambahan sebelum meng-commit ulang semuanya bersama.

Menulis ulang riwayat melalui operasi reset dapat membingungkan kolaborator dan mengganggu alur kerja bersama. Saya belajar menetapkan protokol tim tentang kapan dan bagaimana menggunakan reset pada branch bersama. Di tim saya saat ini, kami punya aturan: tidak ada penulisan ulang riwayat di main branch atau branch mana pun yang menjadi basis pekerjaan developer lain.

Satu kesalahan yang sering saya lihat adalah menggunakan soft reset pada commit yang telah di-merge ke branch lain. Ini menciptakan riwayat yang menyimpang dan sulit didamaikan serta dapat menyebabkan perubahan yang sama muncul berkali-kali dalam riwayat proyek.

Saya juga belajar berhati-hati saat me-reset commit yang berisi resolusi konflik merge. Informasi resolusi merge akan hilang dalam reset, dan jika Anda perlu merge lagi, Anda harus menyelesaikan konflik yang sama.

Kolaborasi dan pertimbangan branch remote

Mengomunikasikan perubahan riwayat mencegah konflik tim dan menjaga stabilitas proyek. Saya mengembangkan protokol komunikasi yang telah melayani tim saya dengan baik selama bertahun-tahun.

git checkout -b feature/user-auth-history-cleanup
git reset --soft HEAD~4
git commit -m "Implement user authentication system"
git push origin feature/user-auth-history-cleanupDidukung oleh

Saya bekerja pada feature branch yang dinamai jelas seperti git checkout -b feature/user-auth-history-cleanup. Perintah ini membuat branch yang memberi sinyal adanya perubahan riwayat. Setelah melakukan operasi reset seperti git reset --soft HEAD~4, saya push versi yang telah dibersihkan dan membuat pull request dengan riwayat yang terorganisasi.

git push --force-with-lease origin feature-branchDidukung oleh

Ketika force-push diperlukan, saya menggunakan git push --force-with-lease. Perintah ini mendorong dengan aman sambil memastikan tidak ada orang lain yang memperbarui branch.

Saya juga menjaga praktik mendokumentasikan setiap perubahan riwayat besar di deskripsi pull request. Contohnya: "Catatan: Riwayat branch ini dibersihkan menggunakan git reset --soft untuk menggabungkan 5 commit inkremental menjadi 2 commit logis agar lebih mudah direview."

Komunikasi adalah kunci. Saya selalu memberi tahu anggota tim sebelum menulis ulang riwayat pada branch apa pun yang mungkin mereka lihat, dan saya menyediakan hash commit sebelum/sesudah agar mereka dapat memahami apa yang berubah.

Pemecahan Masalah dan Pemulihan

Bahkan developer berpengalaman pun menghadapi situasi di mana operasi reset tidak berjalan sesuai rencana. Memahami teknik pemulihan menumbuhkan kepercayaan diri dalam menggunakan fitur Git tingkat lanjut dan memberikan ketenangan saat bekerja dengan riwayat yang kompleks.

Diagram alur kerja yang menunjukkan bagaimana git reflog memulihkan commit yang hilang setelah hard reset.

Cara memulihkan commit setelah menggunakan git reset --hard

Meskipun bagian ini berfokus pada pemulihan hard reset, memahami prinsipnya membantu untuk semua operasi reset. reflog Git menyimpan riwayat ke mana HEAD pernah mengarah, memungkinkan pemulihan commit yang tampaknya hilang.

git reflog
git reset --hard def5678
git branch recovery-branch def5678
git checkout recovery-branchDidukung oleh

Reflog Git melacak ke mana HEAD pernah berada, memungkinkan pemulihan commit. Saya menjalankan git reflog untuk melihat riwayat, mengidentifikasi commit yang ingin dipulihkan, lalu menggunakan git reset --hard def5678. Perintah ini memulihkan secara langsung, atau saya dapat menggunakan cara yang lebih aman git branch recovery-branch def5678 diikuti git checkout recovery-branch untuk memeriksa hasil pemulihan terlebih dahulu.

Reflog telah menyelamatkan saya berkali-kali. Saya ingat satu insiden yang sangat menegangkan ketika saya keliru menggunakan git reset --hard alih-alih git reset --soft dan mengira saya kehilangan pekerjaan satu hari penuh. Reflog menunjukkan tepat di mana pekerjaan saya berada, dan dalam hitungan menit saya memulihkan semuanya.

Reflog memberikan jaring pengaman yang substansial, tetapi penting untuk mengetahui berapa lama jaring itu bertahan. Git menyimpan dua tanggal kedaluwarsa berbeda untuk catatan ini:

• Entri untuk commit yang tidak lagi dapat dijangkau—seperti yang dibuang setelah git reset --hard—disimpan selama 30 hari secara default.

• Entri untuk commit yang masih dapat dijangkau (yang masih menjadi bagian dari branch) disimpan selama 90 hari secara default.

Dalam skenario pemulihan seperti ini, Anda dapat mengandalkan kira-kira satu bulan untuk mengambil kembali pekerjaan Anda. Namun, ini hanya berlaku untuk commit yang merupakan bagian dari riwayat repository lokal Anda. Jika Anda tidak pernah meng-commit pekerjaan secara lokal, bahkan reflog pun tidak bisa membantu.

Satu teknik yang saya gunakan ketika hendak melakukan operasi berisiko adalah membuat commit sementara terlebih dahulu, meski pekerjaannya belum siap. Saya selalu bisa me-reset nanti, tetapi memiliki jejak di reflog memberi jaring pengaman ekstra.

Membatalkan commit di remote

Ketika commit telah didorong ke repository remote, proses pemulihan menjadi lebih kompleks dan memerlukan koordinasi tim. Situasi ini memerlukan pertimbangan cermat terhadap dampaknya pada anggota tim lain.

git reset --soft HEAD~1
git commit -m "Corrected implementation with proper error handling"
git push --force-with-lease origin main
git revert abc1234
git push origin mainDidukung oleh

Untuk commit yang belum diambil (pull) orang lain, saya menggunakan git reset --soft HEAD~1. Perintah ini membatalkan commit sambil menjaga perubahan tetap di-stage. Saya kemudian membuat commit yang dikoreksi dan mendorongnya dengan --force-with-lease. Untuk commit yang sudah tersebar luas, git revert abc1234 diikuti push normal lebih aman karena tidak mengganggu pekerjaan developer lain.

Saya belajar pentingnya pembedaan ini selama sebuah proyek ketika saya melakukan force-push penulisan ulang riwayat ke branch bersama yang sudah menjadi basis pekerjaan tiga developer lain. Konflik merge dan kebingungan yang terjadi memakan waktu setengah hari untuk diselesaikan dan mengajarkan saya untuk jauh lebih konservatif dalam menulis ulang riwayat bersama.

Force-push ke branch bersama seharusnya menjadi upaya terakhir dan memerlukan komunikasi tim yang eksplisit. Dalam banyak kasus, git revert memberi alternatif yang lebih aman dengan membuat commit baru yang membatalkan perubahan sebelumnya alih-alih menulis ulang riwayat.

Kesimpulan

Menguasai git reset --soft membantu Anda mengelola commit dengan presisi sambil menjaga pekerjaan tetap utuh. Ini sempurna untuk membersihkan commit, memperbaiki pesan commit, atau menyiapkan riwayat yang rapi untuk kolaborasi, semua tanpa kehilangan progres berharga.

Untuk memperdalam keterampilan Anda, jelajahi Version Control with Git atau kursus GitHub Concepts.