Sebagai Team Lead salah satu perannya adalah merancang alur kerja tim agar lebih optimal dan produktif. Di tempat saya bekerja, kami menggunakan perkakas Git untuk manajemen kode.
Ada empat metode yang saya ketahui dalam penggunaan Git, beberapa diantaranya adalah sebagai berikut:
Ketika saya baru bergabung di perusahaan, alur kerja Git yang digunakan adalah Centralized Workflow. Selang beberapa bulan seiring bertambahnya anggota tim code conflict makin sering terjadi lalu kami mencoba Gitflow Workflow. Singkat cerita Gitflow Workflow sangat membantu mengoptimalkan alur kerja pengguna Git. Code conflict berkurang, tidak ada lagi fitur yang belum selesai terbawa ke production, dan lain sebagainya.
Sampai suatu hari terjadi lagi, mulai sering code conflict dan pekerjaan yang belum selesai malah terbawa ke production. Jelas tidak ada yang salah dengan Gitflow Workflow sekalipun ada yang mengomentari bahwa Gitflow Workflow tidak bagus, ribet dan lain-lain.
Memang perkakas Gitflow ini membungkus perintah-perintah Git dengan tujuan memudahkan pengguna untuk praktek Gitflow Workflow, sekalipun tetap saja ada yang kebingungan dengan alur penggunaanya. Memang sudah cukup banyak artikel yang membahas Gitflow Workflow sayangnya saya masih melihat beberapa tim member kesulitan mengikuti konsepnya. 
Singkat cerita, daripada semakin tidak produktif akhirnya saya mencoba merancang ulang alur kerja pengguna Git. Alur kerja yang saya buat mirip dengan Feature Branch Workflow. Hanya saja saya coba terangkan menggunakan bahasa saya sendiri dan memvisualisasikannya supaya lebih mudah dicerna, dicetak dan ditempel di dinding biar tidak lupa. 
Motivasi dari alur kerja ini adalah:
- Branch master haruslah siap dan aman di deploy kapanpun
- Mengurangi gap perbedaan source code diantara branch
Penjelasan gambar diatas adalah sebagai berikut:
- Ketika memulai pekerjaan, buatlah branch baru dari master branch. Tentu saja ada tata cara penamaan branch yang saya rancang juga, mungkin akan dibahas di artikel yang lain
- Disebut working branch karena pekerjaan aktif ada di branch ini, dan branch ini menjadi tanggung jawab pembuatnya tidak boleh di share ke orang lain jika tidak ada kolaborasi kode bersama
- Jika pekerjaan sudah selesai, maka merge working branch dengan development branch. Selanjutnya biasanya sudah di ambil alih oleh CI/CD untuk menarik kode di server development
- Dan jika testing atau UAT di development environment sudah OK, selanjutnya adalah melakukan merge working branch dengan staging branch. Staging environment biasanya digunakan untuk UAT dengan stakeholder atau pengguna utama, sebelum di rilis ke production environment
- Setelah UAT dengan stakholder dianggap PASS atau lolos atau telah diterima. Selanjutnya lakukan merge working branch dengan master branch. Melalui proses CI/CD kode yang kita kerjakan akan bisa digunakan oleh orang banyak
Tidak ada pull request ya 
Singkat cerita itulah hal yang dibolehkan. Tidak berhenti sampai disitu, untuk lebih memperjelas alur kerja pengguna Git, saya juga membuat aturan “TIDAK BOLEH”. Melalui diagram dibawah ini saya terangkan apa yang tidak boleh dilakukan.
Inti dari diagram diatas adalah untuk menjaga agar tiap-tiap branch aman dari perubahan-perubahan yang terjadi di working branch dan development branch.
Coba teman-teman bayangkan jika development branch di merge dengan staging branch. Development branch berisi kode-kode yang belum teruji atau bahkan setengah jadi. Lalu di merge ke branch staging dimana branch staging ini digunakan untuk UAT atau 3rd party integration. Amburadul tentunya ya, apalagi klo langsung di merge ke master branch
Selain itu jika diperhatikan ada Friends Working Branch, maksudnya adalah ketika kita mendapatkan tugas mengerjakan suatu fitur dan dikerjakan lebih dari satu orang maka bisa terjadi kolaborasi di working branch. Dan ini harus dengan supervisi agar gap kode antar branch tidak semakin jauh.
Sudah hampir 1.5 tahun dan alur kerja pengguna Git ini berhasil menjadi salah satu faktor stabilitas produktivitas teman-teman.
Photo by Pankaj Patel on Unsplash