Panduan Push Project Node.js ke GitHub
Admin
Penulis Artikel
Panduan Push Project Node.js ke GitHub: Git Init Sampai Repository Online
Di artikel sebelumnya, Todo List API kita sudah lengkap dengan kode, test, dan README.md yang menjelaskan semuanya. Tapi selama ini project itu cuma ada di satu komputer — komputermu sendiri. Kalau laptopnya rusak atau hilang, seluruh kerja kerasmu selama sepuluh artikel bisa ikut hilang.
Artikel penutup ini akan membahas cara paling sederhana mengunggah project ke GitHub: mulai dari membuat akun pakai Gmail, sampai project kita bisa diakses online lewat repository — tanpa perlu setup SSH key atau konfigurasi rumit lainnya. Fokusnya satu: project berhasil ter-upload.
Artikel ini adalah penutup dari seri “Backend Node.js untuk Pemula”, melanjutkan project dari artikel pertama hingga kesepuluh.
1. Kenapa Perlu GitHub?
Analogi: menyimpan project cuma di laptop itu seperti menyimpan satu-satunya salinan tugas sekolah di dalam tas — kalau tasnya basah kehujanan atau ketinggalan di angkot, tugasnya ikut hilang. GitHub itu seperti loker penyimpanan online di perpustakaan sekolah: salinan tugasmu tersimpan aman di tempat lain, bisa diakses dari komputer mana saja, dan gurumu (atau siapa pun yang kamu izinkan) bisa melihatnya tanpa harus kamu kirim file satu-satu lewat WhatsApp.
2. Langkah 1: Membuat Akun GitHub
Buka github.com lewat browser.
Klik tombol Sign up.
Masukkan alamat Gmail kamu, buat username, dan buat password.
Verifikasi email — GitHub akan mengirim kode konfirmasi ke Gmail kamu, masukkan kodenya di halaman pendaftaran.
Setelah akun jadi, kamu akan diarahkan ke halaman utama (dashboard) GitHub.
Penjelasan teknis: GitHub adalah layanan hosting untuk repository Git — ia menyimpan riwayat perubahan kode project kamu secara online. Akun GitHub ini nantinya juga yang dipakai untuk membuat repository (folder project yang di-hosting online) tempat kode Todo List API kita akan disimpan.
3. Langkah 2: Pastikan Git Sudah Terinstall
Buka terminal, lalu cek apakah Git sudah terpasang di komputermu:
git --version
Kalau muncul nomor versi (misalnya git version 2.43.0), berarti Git sudah siap dipakai. Kalau muncul pesan “command not found”, download dan install Git dari git-scm.com terlebih dahulu, lalu ulangi perintah di atas untuk memastikan.
Penjelasan teknis: Git dan GitHub itu dua hal berbeda yang sering tertukar. Git adalah program yang berjalan di komputermu untuk mencatat riwayat perubahan kode (disebut version control). GitHub adalah website/layanan online tempat riwayat itu bisa disimpan dan dibagikan. Git bisa dipakai tanpa GitHub sama sekali (riwayatnya cuma tersimpan lokal), tapi GitHub butuh Git untuk bisa dipakai.
4. Langkah 3: Kenalan Diri ke Git
Analogi: sebelum menulis di buku absen kelas, kamu perlu menuliskan nama dengan benar dulu supaya guru tahu siapa yang mengisi. Git juga begitu — setiap perubahan kode yang kamu simpan (disebut commit) akan mencatat nama dan email pembuatnya. Ini perlu diatur satu kali saja pada Terminal/Git Bash per komputer.
git config --global user.name "Nama Kamu"
git config --global user.email "email-kamu@gmail.com"
Penjelasan teknis: gunakan email yang sama persis dengan email yang kamu daftarkan di GitHub. Ini bukan wajib secara teknis, tapi kalau sama, GitHub akan otomatis mengaitkan setiap commit-mu dengan foto profil dan username GitHub-mu di halaman repository — kalau beda, commit tetap tersimpan tapi tidak "dikenali" sebagai milikmu secara visual di GitHub.
5. Langkah 4: Pastikan .gitignore Sudah Benar
Sebelum menyimpan project ke Git, pastikan file .gitignore yang sudah kita buat sejak artikel kedua masih ada dan lengkap:
.gitignore (final)
node_modules/
.env
.env.test
Penjelasan teknis: ini adalah langkah paling penting sebelum upload ke GitHub. node_modules/ dikecualikan karena isinya bisa di-generate ulang kapan saja lewat npm install (mengunggahnya cuma buang-buang tempat dan waktu upload). .env dan .env.test dikecualikan karena berisi JWT_SECRET, MONGODB_URI, dan EXTERNAL_API_KEY yang kita pelajari harus dirahasiakan sejak artikel kedua dan keempat — kalau file ini sampai ter-upload ke GitHub public, siapa pun bisa melihat kredensialmu.
6. Langkah 5: Menyimpan Project Secara Lokal dengan Git
Analogi: proses git add dan git commit itu seperti memasukkan barang ke keranjang belanja, lalu checkout. git add memasukkan file-file yang berubah ke “keranjang” (disebut staging area), dan git commit adalah proses checkout-nya — menyimpan permanen isi keranjang itu sebagai satu titik riwayat, lengkap dengan “struk belanja” berupa pesan commit yang menjelaskan apa yang berubah.
Di root folder todo-api, jalankan pada terminal / git bash:
git init
git add .
git commit -m "Initial commit: Todo List API boilerplate"
Penjelasan teknis:
git initmengubah foldertodo-apimenjadi repository Git — Git mulai mencatat riwayat perubahan sejak perintah ini dijalankan. Ini membuat folder tersembunyi.git/di dalam project (jangan dihapus, ini “otak” penyimpanan riwayat Git).git add .memasukkan semua file yang berubah di folder saat ini ke staging area, kecuali file/folder yang terdaftar di.gitignore— inilah kenapa langkah 4 (memastikan.gitignorebenar) harus dilakukan sebelumgit add, supayanode_modules/dan.envtidak ikut ter-stage.git commit -m "pesan"menyimpan permanen isi staging area sebagai satu titik riwayat. Pesan commit sebaiknya singkat tapi jelas menjelaskan apa yang berubah — kebiasaan menulis pesan commit yang baik ini akan sangat membantu ketika project sudah punya ratusan commit dan kamu perlu melacak kapan sebuah bug pertama kali muncul.
7. Langkah 6: Membuat Repository Baru di GitHub
Di halaman utama GitHub, klik tombol + di pojok kanan atas, lalu pilih New repository.
Isi Repository name, misalnya
todo-api.Pilih Public (bisa dilihat siapa saja) atau Private (hanya kamu dan yang diundang).
Jangan centang opsi “Add a README file”, “.gitignore”, atau “license” apa pun di halaman ini.
Klik Create repository.
Penjelasan teknis: kenapa opsi “Add a README file” dan sejenisnya sengaja tidak dicentang? Karena kita sudah punya README.md, .gitignore, dan seluruh kode sungguhan di komputer lokal (hasil artikel sebelumnya). Kalau opsi itu dicentang, GitHub akan membuat commit pertama secara otomatis di repository online, sehingga riwayat di GitHub dan riwayat di laptop kita jadi tidak sinkron sejak awal — ini menyebabkan konflik yang membingungkan buat pemula saat mencoba menghubungkan keduanya. Dengan membuat repository benar-benar kosong, kita bisa mengisi riwayatnya langsung dari commit yang sudah kita buat di langkah sebelumnya, tanpa bentrok.
8. Langkah 7: Menghubungkan Project Lokal ke GitHub
Setelah repository kosong berhasil dibuat, GitHub akan menampilkan halaman berisi beberapa baris perintah. Salin perintah di bagian “…or push an existing repository from the command line”, bentuknya seperti ini (ganti username-kamu dan todo-api sesuai punyamu):
git remote add origin https://github.com/username-kamu/todo-api.git
git branch -M main
git push -u origin main
Penjelasan teknis:
git remote add origin <url>memberi tahu Git lokal: “repository online-nya ada di alamat ini, namai koneksinyaorigin” (originadalah nama standar yang dipakai hampir semua orang untuk remote utama, meskipun sebenarnya bisa dinamai bebas).git branch -M mainmemastikan nama branch (cabang riwayat) utama kita bernamamain, sesuai standar yang dipakai GitHub saat ini. Analoginya, satu branch itu seperti satu “jalur cerita” riwayat perubahan kode — untuk project sesederhana seri artikel ini, kita cukup memakai satu jalur cerita saja.git push -u origin mainadalah perintah yang benar-benar mengunggah seluruh commit dari komputer lokal ke repository GitHub. Flag-u(singkatan--set-upstream) menghubungkan branch lokalmaindengan branchmaindioriginsecara permanen, sehingga di kemudian hari kamu cukup mengetikgit pushsaja (tanpa perlu menulisorigin mainlagi setiap kali).
8.1 Kalau Diminta Login
Saat menjalankan git push pertama kali, kemungkinan besar akan muncul jendela login GitHub di browser (untuk pengguna Git versi baru) — tinggal login dengan akun GitHub yang sudah dibuat di langkah 2, lalu izinkan aksesnya. Proses push akan otomatis lanjut setelah login berhasil.
Kalau yang muncul justru kolom isian password di terminal (bukan jendela browser), GitHub tidak lagi menerima password akun biasa untuk proses ini — kamu perlu membuat Personal Access Token (PAT) sebagai gantinya:
Di GitHub, klik foto profil di pojok kanan atas → Settings.
Scroll ke bawah, klik Developer settings (paling bawah sidebar kiri).
Klik Personal access tokens → Tokens (classic) → Generate new token (classic).
Beri nama token, centang scope repo, lalu klik Generate token.
Salin token yang muncul (hanya ditampilkan satu kali!).
Saat terminal minta password, tempelkan token ini sebagai gantinya (bukan password akun biasa).
Penjelasan teknis: Personal Access Token adalah “password khusus” yang dibuat spesifik untuk mengakses GitHub lewat command line, terpisah dari password akun utamamu. Ini konsepnya mirip dengan EXTERNAL_API_KEY yang kita buat di artikel API Key — sama-sama string acak yang berfungsi sebagai “kunci akses” terpisah dari identitas login utama, sehingga kalau token ini bocor atau tidak dipakai lagi, kamu bisa mencabutnya tanpa perlu mengganti password akun GitHub-mu secara keseluruhan.
9. Langkah 8: Verifikasi di GitHub
Buka kembali halaman repository di browser (https://github.com/username-kamu/todo-api), refresh halamannya. Kamu akan melihat:
Seluruh folder
src/,tests/, dan file-file lain sudah muncul di daftar file.Isi
README.mdotomatis ditampilkan sebagai halaman utama repository — ini alasan lain kenapa artikel README penting: begitu project di-push, README-lah yang pertama kali dilihat orang.Folder
node_modules/dan file.envtidak muncul di daftar file — ini konfirmasi bahwa.gitignorebekerja dengan benar.
10. Alur Kerja Setelah Push Pertama
Analogi: push pertama tadi ibarat menyetorkan seluruh isi map tugas ke loker untuk pertama kali. Setelah itu, setiap kali kamu menambah atau mengubah halaman di map (menulis kode baru), kamu tidak perlu menyetor ulang seluruh map — cukup setorkan lembar yang berubah saja, dengan urutan tiga langkah yang sama setiap kali:
git add .
git commit -m "Deskripsi singkat perubahan yang kamu buat"
git push
Penjelasan teknis: perhatikan git push di sini tidak perlu lagi menuliskan -u origin main — itu hanya diperlukan sekali di push pertama (langkah 8), karena flag -u sudah “mengingat” hubungan antara branch lokal dan remote untuk push-push berikutnya. Biasakan menjalankan ketiga perintah ini setiap kali kamu menyelesaikan satu perubahan yang cukup berarti untuk disimpan — misalnya setelah menambah satu endpoint baru, memperbaiki satu bug, atau menyelesaikan satu artikel tutorial yang kamu praktikkan.
11. Perbandingan Sebelum dan Sesudah
Aspek | Sebelum | Sesudah |
|---|---|---|
Lokasi penyimpanan kode | Hanya di satu laptop | Tersimpan online di GitHub, bisa diakses dari mana saja |
Riwayat perubahan | Tidak tercatat | Tercatat lewat commit history |
Berbagi project ke orang lain | Kirim file manual (zip, WA, dll) | Cukup bagikan link repository |
Risiko kehilangan kode | Tinggi (laptop rusak/hilang) | Rendah, tersimpan aman di server GitHub |
12. Penutup Seri
Sampai di sini, perjalanan kita membangun Todo List API sudah lengkap satu putaran penuh: dari merapikan kode CRUD sederhana jadi struktur folder profesional, menambahkan lapisan keamanan dan kualitas kode satu per satu, menuliskan automated test dan dokumentasi, sampai akhirnya project ini benar-benar tersimpan online dan siap dibagikan ke siapa saja lewat GitHub.
Pola-pola yang sudah kamu praktikkan di seluruh seri ini — struktur Controller-Service-Model, middleware, error handling terpusat, autentikasi & otorisasi, validasi, testing, dokumentasi, sampai version control — bukan cuma berlaku untuk Todo List API. Ini adalah fondasi yang akan terus kamu pakai di hampir semua proyek backend Node.js ke depannya, termasuk proyek magangmu berikutnya.
Artikel Terkait
Panduan Membuat Animasi Animated on Scroll di Website Anda
Pelajari cara membuat animasi menarik pada scroll di website Anda dengan tutorial ini. Tampilkan konten dengan cara yang lebih interaktif!
Cara Menangani Error dan HTTP Status Code yang Benar
cara menentukan HTTP status code yang benar untuk tiap jenis error, dan cara membuat custom Error
Cara Restrukturisasi CRUD Node.js: Dari Function ke Folder Controller-Service-Model
cara merestrukturisasi kode CRUD dari kumpulan function menjadi struktur folder yang rapi menggunakan pola Controller-Service-Model.
