ÖNEMLİ : Kendim için aldığım notlar. Umarım size de bir faydası olur. Kullanılan her bir makale referans olarak eklenmiştir.
Git-Bisect Nedir?
Git versiyon kontrol sisteminde bisect komutu, çoğunlukla projenizin geçmişinde hataya ilk neden olan taahhüdü(commit) bulmak için kullanır. Bunu, önce “bug(hata)” içerdiğini bildiğiniz bir taahhüdü(commit) “bad(kötü)” olarak işaretleyerek yaparsınız. Ve bu hata ortaya çıkmadan önce sorunsuz çalıştığını bildiğiniz bir taahhütü ise “good(iyi)” olarak işaretlersiniz. Bisect komutu, Git’teki taahhütler arasında ikili arama(binary search) algoritması uygular.
Tabii bu işaretlemelerden önce bisect state’ine girmemiz gerekmektedir. Bunun için ise bisect start
komutunu kullanırız.
Git bisect start
Bisect state’ini başlatmanın birkaç yolu vardır. Bunlardan biri git bisect start
komutudur.
Görüleceği üzere bu komutun çıktısı olarak “waiting for both good and bad commits (hem iyi hem de kötü taahhütler bekleniyor)” şeklinde bir durum mesajı alıyoruz. Bu mesaj sonrasında düzgün çalıştığını bildiğiniz bir commit’e “good”, düzgün çalışmadığını bildiğiniz bir commit’e ise “bad” işaretini verebiliriz. Bunun nasıl yapıldığına birazdan geleceğim.
Diğer bir bisect başlatma yöntemi ise aramanın yapılacağı aralığı tanımlayarak yapılan bisect komutudur.
Bu komut otomatik olarak HEAD‘i bad commit, HEAD~15‘i yani HEAD‘den 15 commit önceki commit’i ise good commit olarak işaretler. Tabii ki 15 commit öncesinin sorunsuz çalışan bir commit olduğunu biliyor olmanız gerekmektedir.
Git bisect bad
git bisect start
komutu kullanarak bisect state’ini başlattığımızı varsayalım. Görüleceği üzere, bisect bizden bad ve good commit’leri belirlememizi bekler. Farzedelim ki son commit’imiz düzgün çalışmıyor. Ama hatanın da ilk nerede başladığını bulmak istiyoruz.
Son commit’imiz olan versiyon 10‘u bad olarak işaretlediğimizde, komut sonrası durum mesajımız, “waiting for good commit(s), bad commit known“(bad commit biliniyor, good commit’ler bekleniyor) şeklinde olacaktır. Tabii ki bu komutu HEAD yazmadan da, yani git bisect bad
şeklinde de yazabilirdik. Bu komut, otomatik olarak HEAD işaretçisinin olduğu commit’i bad olarak işaretler.
Git bisect good
Aşağıdaki komut vasıtasıyla HEAD işaretçisinin bulunduğu commit’ten 10 commit geriye gitmek istiyorum.
Kodun bu versiyonunun düzgün çalıştığını varsayalım. git bisect good
komutu ile bu commit’i good olarak işaretliyorum.
Bu, bisect’in bu revizyonu good olarak işaretlemesine ve ardından bizim değerlendirmemiz için bad ve good revizyonları arasında, kabaca ortalarda bir taahhüt döndürmesine neden olur. Yani koddan da anlaşılacağı üzere versiyon 1‘i good olarak işaretlediğimizde ikili arama algoritması bize commit-5‘i rastgele döndürür.
Bisect kendini, otomatik olarak versiyon 5‘i temsil eden commit-5’e çekeceği için ekstra bir işlem yapmama gerek olmadan tekrardan git bisect good
veyahut git bisect bad
komutlarını yazabilirim.
Farzedelim ki commit-5’in, yani resimden de anlaşılacağı üzere version 5‘in düzgün çalıştığına karar verdik. Şayet bu versiyonu good olarak işaretlersek, commit-5 ve öncesindeki bütün commit’ler otomatik olarak good olarak işaretlenir. Akabinde ikili arama algoritması bu sefer version 5 ile version 10 arasındaki rastgele bir commit’i döndürecektir.
Görüleceği bu sefer commit-7’yi temsil eden versiyon 7 rastgele döndürülüyor. Farzedelim ki bu commit düzgün çalışmıyor ve bad olarak işaretlemek istiyoruz. Bu seferde version 7 ile versiyon 10 arasındaki commitler otomatikman bad olarak işaretlenecek ve geriye son commit olan commit-6, bisect tarafından rastgele döndürülecektir.
Diyelim ki versiyon 6‘yı da test ettik ve düzgün çalışmadığına hükmettik. Bunu da bad olarak işaretlersek hatanın ilk çıktığı noktayı bulmuş oluruz. Çünkü version 5 ve öncesinin good olarak işaretli olduğunu biliyoruz.
Git bisect visualize
Bu komut sayesinde ise ilgili commit’i gitk yardımcı programı aracılığı ile görselleştirebilirsiniz. Bu sayede commit hakkında daha detaylı bilgi alabilirsiniz. Örneğin hataya ilk neden olan kişinin kullanıcı bilgilerini de bu komut sayesinde görüntüleyebilirsiniz.
Git bisect log
commit’leri good veya bad olarak işaretledikten sonra, şu ana kadar yapılanları göstermek için git bisect log
komutunu kullanabilirsiniz. Özetle bu komut, git bisect state’i süresince yapılan işlemlerin kayıtlarını karşınıza çıkaracaktır.
Git bisect reset
Hataya neden olan ilk commit’i bulduktan sonra bisect state’inden çıkmak isteyeceksiniz. Bunun için ise git bisect reset
komutunu kullanabilirsiniz.
Git bisect run
Diyelim ki kodunuzun çalışıp çalışmadığını test edecek bir script’te sahipsiniz;
bu komutu kullanarak bad ve good işaretleme işlemlerini otomatize edebilirsiniz. Yalnız, script’inizi çalıştırdığınızda kodunuz iyiyse(yani good/old ise) script’i 0 koduyla, kodunuz kötüyse(yani bad/new ise) 125 dışında 1 ile 127 (dahil) arasında bir kodla döndürmeniz gerektiğini unutmayın. Hatta, script isminden sonra boşluk bırakıp, script’in ihtiyaç duyacağı argümanları bu script’e parametre olarak geçirebilirsiniz. git bisect run
komutuyla ilgili detaylı bilgi için, git bisect --help
komutuna başvurabilirsiniz.
Geçerli kaynak kodu test edilemediğinde 125 rakamı çıktı olarak döndürülmelidir. Komut dosyası bu kodla çıkarsa, geçerli revizyon atlanır (bunun için git bisect skip
bölümüne bakın).
Not: Bu arada good yerine old, bad yerine ise new işaretini de kullanabilirsiniz.
Git bisect komutunun avantajları
Yukarıdaki örnekten de görüleceği üzere hatanın ilk ortaya çıktığı yeri 10 commit’i de tek tek test etmek yerine yaklaşık 3-4 adımda belirlemiş olduk. Bu aralık 10 yerine 100 veyahut 1000 commit’ten de oluşuyor olabilirdi. Git bisect, ikili arama(binary search) algoritması sayesinde test sayısını dramatik bir şekilde azaltır.