Git ve GitHub Kullanım Rehberi: Her Geliştiricinin Bilmesi Gereken Temel Komutlar

Git komutları, bir projenin her değişikliğini kayıt altına alan, geri almanızı ve ekip olarak aynı kod üzerinde çalışmanızı sağlayan araç setidir. 2012'den beri web projeleri yönetiyorum ve bir projenin sağlıklı ilerleyip ilerlemediğini çoğu zaman sürüm kontrolüne bakarak anlıyorum. Bu rehberde her geliştiricinin günlük olarak kullandığı komutları, dal stratejilerini, pull request akışını ve çakışma çözmeyi kendi deneyimimle anlatıyorum.

Açık kaynak projelere katkı sürecine bu yazıda girmiyorum; fork, upstream ve katkı kuralları ayrı bir konu. Burada odak, kendi projenizde veya şirket ekibinizde Git ve GitHub ile güvenle çalışmak. Diğer teknik yazılara yazılım kategorisinden ulaşabilirsiniz.

Git komutları nedir ve Git ile GitHub arasındaki fark ne?

Git komutları, dağıtık sürüm kontrol sistemi olan Git'i terminalden yönetmek için kullandığınız talimatlardır; dosyaları kaydeder, geçmişi gösterir, dal açar ve uzak depoyla eşitler. GitHub ise bu Git depolarını bulutta barındıran, pull request ve kod incelemesi gibi ekip özellikleri ekleyen bir platformdur.

Bu ayrımı baştan netleştirmek önemli, çünkü yeni başlayan birçok kişi ikisini aynı şey sanıyor. Git, bilgisayarınızda çalışan bir programdır ve internet olmadan da tam işlev görür. GitHub ise bir hizmettir; GitLab ve Bitbucket gibi alternatifleri de vardır. Yani Git'i öğrendiğinizde bu platformların hepsinde işinizi görürsünüz.

Git'i Linus Torvalds 2005 yılında Linux çekirdeğinin geliştirilmesi için yazdı. Resmî belgelerin tamamı ve ücretsiz Pro Git kitabı git-scm.com adresinde duruyor. Takıldığınız her komutun ayrıntısına orada bakabilirsiniz.

Neden her geliştiricinin sürüm kontrolü kullanması gerekir?

Sürüm kontrolü olmadan çalışmak, kaydetme tuşu olmayan bir metin editörüyle roman yazmaya benzer. Bir dosyayı bozduğunuzda dünkü hâline dönemezsiniz. Üstelik iki kişi aynı dosyayı düzenlediğinde kimin değişikliğinin kaybolduğunu kimse bilmez.

Benim sahada gördüğüm en pahalı hatalar, "son_hali_kesin_v3.zip" gibi klasörlerle yürütülen projelerde çıktı. Bir müşteri sitesinde canlıya alınan düzeltme, eski bir kopyanın üzerine yazılınca geri geldi ve kimse fark etmedi. Git kullanan bir ekipte bu durum neredeyse imkânsız, çünkü Git her değişikliği yapan kişiyi ve gerekçesini kayda geçirir.

Sürüm kontrolünün size kazandırdıkları kısaca şöyle:

• Her değişikliğin tarihli ve açıklamalı bir geçmişi.
• Hatalı bir değişikliği dakikalar içinde geri alma imkânı.
• Aynı anda birden fazla özellik üzerinde güvenle çalışma.
• Kod incelemesi ile kaliteyi yayından önce kontrol etme.
• Sunucuya dağıtımı otomatikleştirmek için sağlam bir temel.

Tek başına çalışan bir serbest geliştirici için bile bu faydalar geçerli. Müşteri bir değişikliği beğenmediğinde önceki sürüme dönmek saniyeler alır. Ayrıca bilgisayarınız bozulduğunda uzak depodaki kopya, bütün emeğinizi ve geçmişinizi korur. Kısacası sürüm kontrolü ekip büyüklüğünden bağımsız bir sigortadır.

Git'i nasıl kurar ve ilk ayarlarını nasıl yaparsınız?

Git'i işletim sisteminize göre kurarsınız: macOS'ta Xcode komut satırı araçları veya Homebrew, Windows'ta Git for Windows, Linux'ta paket yöneticisi yeterlidir. Kurulumdan sonra terminalde git --version yazarak sürümü kontrol edersiniz.

İlk iş, kimliğinizi tanıtmaktır. Git her commiti bu bilgiyle imzalar, dolayısıyla doğru e-posta adresini girmeniz gerekir. GitHub hesabınızdaki adresle aynı olursa commitleriniz profilinizle eşleşir.

1. Adınızı tanıtmak için git config --global user.name "Adınız Soyadınız" yazarsınız.
2. E-posta için git config --global user.email "adres@ornek.com" kullanırsınız.
3. Varsayılan dal adını belirlemek için git config --global init.defaultBranch main komutunu girersiniz.
4. Ayarları görmek isterseniz git config --list hepsini listeler.

Son adımdaki dal adı ayarı küçük görünür, ancak ekip içinde tutarlılık sağlar. GitHub da yeni depolarda varsayılan dal adı olarak main kullanıyor. Böylece yerel deponuz ile uzak depo arasında gereksiz bir isim karmaşası yaşamazsınız.

Yeni bir depo başlatırken hangi git komutlarını kullanırsınız?

İki başlangıç yolu vardır: sıfırdan depo oluşturmak veya var olan bir depoyu kopyalamak. Sıfırdan başlıyorsanız proje klasörüne girip git init yazarsınız. Bu komut klasörde gizli bir .git dizini oluşturur ve Git bütün geçmişi artık orada saklar.

Var olan bir projeye katılıyorsanız git clone komutunu depo adresiyle birlikte kullanırsınız. Bu komut dosyaları, geçmişi ve uzak depo bağlantısını tek seferde indirir. Örneğin bir ajans ekibine yeni katılan geliştirici, ilk gününde genellikle yalnızca bu komutu çalıştırır.

Depoyu başlattıktan hemen sonra bir .gitignore dosyası eklemenizi öneririm. Bu dosya, Git'in takip etmeyeceği dosyaları listeler: node_modules gibi bağımlılık klasörleri, derleme çıktıları ve özellikle şifre içeren .env dosyaları. Şifreyi yanlışlıkla depoya gönderen ekipleri gördüm; o şifreyi geçmişten temizlemek, baştan engellemekten çok daha zahmetli. Güçlü parolalar için şifre oluşturucu aracını kullanabilirsiniz, ama onları asla depoya koymayın.

Günlük iş akışındaki temel Git komutları nelerdir?

Git'te bir değişiklik üç alandan geçer: çalışma dizini, hazırlık alanı ve depo geçmişi. Dosyayı düzenlersiniz, kaydetmek istediklerinizi hazırlık alanına eklersiniz ve ardından commit ile kalıcı hâle getirirsiniz. Bu üç adımlı yapı ilk başta fazla gelir, fakat hangi değişikliğin hangi commite gireceğini tam olarak seçmenizi sağlar.

Ben bir alışkanlık olarak her commit öncesinde önce status, sonra diff çalıştırırım. Bu iki komut, yanlışlıkla bir test dosyasını veya hata ayıklama satırını göndermenizi büyük ölçüde engeller.

İyi bir commit mesajını nasıl yazarsınız?

Commit mesajı, altı ay sonra kendinize yazdığınız bir nottur. "düzeltme" veya "güncelleme" gibi mesajlar o gün anlamlı gelir, ama geçmişte bir hatanın kaynağını ararken hiçbir işe yaramaz. İyi bir mesaj neyi değiştirdiğinizi ve neden değiştirdiğinizi söyler.

Git topluluğunda yaygın kabul gören kurallar şöyle:

• Özet satırını kısa tutun; genel teamül yaklaşık 50 karakterdir.
• Özeti emir kipinde yazın: "Ödeme formuna telefon doğrulaması ekle".
• Gerekirse boş bir satır bırakıp ayrıntıyı alt paragrafta açıklayın.
• Her commit tek bir mantıksal değişikliği içersin.
• İlgili iş kaydının numarasını mesaja ekleyin.

Bazı ekipler Conventional Commits adlı bir biçim kullanır; mesajın başına feat, fix veya docs gibi bir tür yazarlar. Bu biçim sürüm notlarını otomatik üretmeyi kolaylaştırır. Küçük bir ekipte zorunlu değil, ancak projeniz büyüdükçe faydasını hissedersiniz.

Git dalları ne işe yarar ve onları nasıl açarsınız?

Dal, ana koddan ayrılan ve bağımsız ilerleyen bir çalışma hattıdır. Yeni bir özellik geliştirirken main dalını bozmadan deneme yapabilirsiniz. İş bittiğinde dalı ana hatta birleştirirsiniz; iş başarısız olursa dalı silip hiçbir şey olmamış gibi devam edersiniz.

Git'te dal açmak çok ucuzdur, çünkü dal aslında bir commite işaret eden hafif bir etikettir. Bu nedenle her iş için ayrı dal açmaktan çekinmeyin. Dallarla ilgili en sık kullandığınız git komutları şunlardır:

• Mevcut dalları görmek için git branch yeterlidir.
• Yeni dal açıp ona geçmek için git switch -c ozellik/iletisim-formu yazarsınız.
• Başka bir dala dönmek istediğinizde git switch main kullanırsınız.
• İşi biten dalı temizlemek için git branch -d ve dal adını girersiniz.

Eski kaynaklarda aynı işler için git checkout göreceksiniz. Git 2.23 sürümüyle gelen switch ve restore komutları, checkout'un üstlendiği iki farklı görevi ayırdı. Ben yeni başlayanlara switch öneriyorum, çünkü yanlışlıkla dosya değişikliklerini silme riski daha düşük.

Hangi dal stratejisini seçmelisiniz?

Dal stratejisi, ekibin dalları nasıl adlandırdığını, ne zaman açtığını ve nasıl birleştirdiğini belirleyen ortak kuraldır. Doğru strateji ekip büyüklüğüne ve yayın sıklığına bağlıdır. Tek bir doğru yoktur, ama yanlış seçim hem yavaşlık hem de karmaşa getirir.

Web sitesi ve web uygulaması projelerinde ben çoğunlukla GitHub Flow kullanıyorum. Kurallar basit: main her zaman yayına hazırdır, her iş ayrı dalda yürür ve birleştirme pull request ile olur. Git Flow ise mobil uygulama gibi sürüm numarasıyla yayınlanan ürünlerde daha anlamlı.

Hangisini seçerseniz seçin, kuralları yazıya dökün. Yeni gelen bir geliştirici, dal adlarının nasıl verildiğini ilk gün öğrenebilmeli.

Dalları birleştirirken merge mi rebase mi kullanmalısınız?

İkisi de bir dalın değişikliklerini diğerine aktarır, ama geçmişi farklı biçimde kaydeder. Merge, iki dalın birleştiği noktada yeni bir birleştirme commiti oluşturur ve gerçek geçmişi olduğu gibi korur. Rebase ise dalınızdaki commitleri hedef dalın ucuna yeniden yazar ve düz bir çizgi elde edersiniz.

Pratikteki farkı şöyle özetleyebilirim:

• Merge güvenlidir, çünkü mevcut commitlere dokunmaz.
• Rebase daha temiz bir geçmiş verir, ancak commit kimliklerini değiştirir.
• Paylaşılan bir dalı rebase etmek ekip arkadaşlarınızın geçmişini bozar.
• Kendi yerel dalınızı güncellemek için rebase oldukça kullanışlıdır.

Benim uyguladığım kural basit: yalnızca bana ait ve henüz kimsenin çekmediği dalda rebase yaparım. Ortak dallarda her zaman merge kullanırım. Pro Git kitabı da aynı altın kuralı söyler: başkalarının üzerine iş kurduğu commitleri yeniden yazmayın.

GitHub'da uzak depo ile nasıl çalışırsınız?

Uzak depo, projenizin sunucudaki kopyasıdır ve ekip bu kopya üzerinden eşitleme yapar. Klonladığınız depoda uzak bağlantı origin adıyla otomatik gelir. Sıfırdan başladıysanız GitHub'da boş bir depo açar, ardından git remote add origin komutuyla adresini tanıtırsınız.

Uzak depoyla ilgili üç komutu karıştırmamak gerekir. Fetch, uzak değişiklikleri indirir ama çalışma dosyalarınıza dokunmaz. Pull, fetch ile birlikte birleştirmeyi de yapar. Push ise sizin commitlerinizi sunucuya gönderir. Ben belirsiz durumlarda önce fetch yapıp farka bakmayı tercih ederim.

GitHub'a bağlanırken iki yöntem kullanabilirsiniz: HTTPS ile kişisel erişim belirteci veya SSH anahtarı. GitHub, parola ile Git işlemlerini 2021'de kapattı; bu yüzden artık hesap parolanızla push yapamazsınız. Ben SSH anahtarını tercih ediyorum, çünkü bir kez kurduktan sonra her seferinde kimlik sormaz.

Pull request nedir ve nasıl açarsınız?

Pull request, bir daldaki değişikliklerin ana dala birleştirilmesi için yapılan resmî bir öneridir. GitHub bu öneride değişen satırları gösterir, yorum yapmaya izin verir ve otomatik testleri çalıştırır. Kısacası pull request, kodun ekibin gözünden geçtiği kapıdır.

Tipik bir pull request akışı şu sırayla ilerler:

1. Yeni bir dal açar ve işinizi o dalda commitlersiniz.
2. Dalı git push -u origin dal-adi ile uzak depoya gönderirsiniz.
3. GitHub'da "Compare and pull request" düğmesine tıklarsınız.
4. Başlığa ve açıklamaya neyi neden değiştirdiğinizi yazarsınız.
5. İnceleyici atar, testlerin sonucunu beklersiniz.
6. Onay geldikten sonra birleştirir ve dalı silersiniz.

Açıklama kısmını boş bırakmayın. İnceleyen kişinin neye bakacağını bilmesi, incelemeyi hem hızlandırır hem de derinleştirir. Arayüz değişikliklerinde ekran görüntüsü eklemek de işi kolaylaştırır. Ayrıntılı seçenekler için GitHub pull request belgeleri iyi bir başvuru kaynağı.

Kod incelemesinde nelere dikkat etmelisiniz?

Kod incelemesi, hata avından çok ortak anlayış kurma sürecidir. İnceleyen kişi kodun doğru çalışıp çalışmadığına, okunabilir olup olmadığına ve projenin kurallarına uyup uymadığına bakar. İyi bir incelemede yorumlar kişiye değil, koda yönelir.

İnceleme yaparken kendime sorduğum sorular şunlar: Bu değişiklik açıklamada yazan sorunu gerçekten çözüyor mu? Geliştirici uç durumları düşünmüş mü? Test var mı? Altı ay sonra bu kodu okuyan biri ne yaptığını anlar mı? Ayrıca performansı etkileyen değişikliklere özellikle dikkat ederim; web projelerinde küçük bir değişiklik bile sayfa hızını düşürebilir. Sayfa hızını ölçmek için Google Lighthouse ile performans testi yazısına bakabilirsiniz.

Pull request boyutu da incelemenin kalitesini belirler. Yüzlerce dosyaya dokunan bir öneriyi kimse dikkatle okuyamaz. Bu yüzden işi küçük parçalara bölüp her birini ayrı pull request olarak açmanızı öneririm.

Birleştirme çakışması neden oluşur?

Çakışma, iki farklı dalda aynı dosyanın aynı satırları farklı biçimde değiştirildiğinde ortaya çıkar. Git hangi değişikliği tutacağını bilemez ve kararı size bırakır. Ayrıca bir dalda dosya silinip diğerinde düzenlendiğinde de çakışma görürsünüz.

Çakışma bir hata değildir; paralel çalışmanın doğal sonucudur. Yine de sıklığını azaltabilirsiniz. En etkili yöntemler şunlar:

• Dalları kısa ömürlü tutmak ve birkaç gün içinde birleştirmek.
• Güne başlarken ana daldaki değişiklikleri kendi dalınıza almak.
• Aynı dosya üzerinde çalışan kişilerle önceden konuşmak.
• Kod biçimlendirme aracını ekipçe aynı ayarlarla kullanmak.

Son madde küçük görünür, ama sık karşılaştığım bir sorunu çözüyor. Bir geliştiricinin editörü dosyanın tamamını yeniden biçimlendirince her satır değişmiş sayılıyor ve anlamsız çakışmalar çıkıyor.

Çakışmayı adım adım nasıl çözersiniz?

Git çakışma bildirdiğinde paniğe gerek yok. İlk olarak git status ile hangi dosyaların çakıştığını görürsünüz. Bu dosyaları açtığınızda Git'in eklediği işaretleri fark edersiniz: küçüktür işaretleriyle başlayan satır sizin sürümünüzü, eşittir çizgisi ayrımı ve büyüktür işaretleri gelen sürümü gösterir.

1. Çakışan dosyayı açar ve iki sürümü dikkatle okursunuz.
2. Doğru sonucu elle yazarsınız; bazen biri, bazen ikisinin birleşimi doğrudur.
3. Git'in eklediği işaret satırlarını tamamen silersiniz.
4. Dosyayı git add ile çözüldü olarak işaretlersiniz.
5. Merge sürüyorsa git commit, rebase sürüyorsa git rebase --continue ile devam edersiniz.

İşler karışırsa geri çekilebilirsiniz: git merge --abort birleştirmeyi başlamadan önceki hâline döndürür. Çözdükten sonra uygulamayı mutlaka çalıştırıp test edin, çünkü sözdizimi doğru olsa bile mantık bozulmuş olabilir. GitHub da basit çakışmalar için tarayıcıda bir düzenleyici sunuyor; karmaşık olanları ise yerelde çözmek daha güvenli.

Hatalı bir değişikliği geri almak için hangi git komutları var?

Geri alma ihtiyacı, değişikliğin nerede olduğuna göre değişir. Henüz kaydetmediğiniz bir dosyayı eski hâline döndürmek başka, paylaşılmış bir commiti geri almak başka iştir. Doğru komutu seçmek, ekip arkadaşlarınızın geçmişini bozmamak için kritiktir.

Ekip çalışmasında kuralım net: push edilmiş commit için revert, yerel işler için reset. Revert geçmişi silmez, üzerine düzeltici bir kayıt ekler; böylece herkesin deposu uyumlu kalır. Yanlışlıkla bir şey kaybettiğinizde ise git reflog hayat kurtarır, çünkü dalın gezdiği bütün noktaları bir süre saklar.

Yarım kalan işi git stash ile nasıl saklarsınız?

Bir özellik üzerinde çalışırken acil bir hata bildirimi geldiğini düşünün. Kodunuz yarım, commit etmeye hazır değil, ama başka dala geçmeniz gerekiyor. İşte stash bu durum için var: değişikliklerinizi geçici bir rafa kaldırır ve çalışma dizinini temizler.

Kullanımı oldukça basit. git stash push -m "form doğrulama yarım" ile işi saklarsınız, acil düzeltmeyi yaparsınız, sonra kendi dalınıza dönüp git stash pop ile kaldığınız yerden devam edersiniz. Rafta birden fazla kayıt varsa git stash list hepsini gösterir.

Ancak stash'i uzun süreli depo gibi kullanmayın. Haftalarca rafta kalan değişiklikleri insan unutur ve sonra bunlar ana dalla çakışır. Bir işin ömrü bir günü geçecekse ayrı bir dal açıp geçici bir commit atmak daha sağlıklıdır.

Git geçmişinde hata kaynağını nasıl bulursunuz?

Bir hata ortaya çıktığında ilk soru genellikle şudur: bu ne zaman bozuldu? Git geçmişi bu soruya cevap vermek için birkaç güçlü araç sunar. Log komutu size kimin ne zaman neyi değiştirdiğini, blame komutu ise bir dosyanın her satırını en son kimin değiştirdiğini gösterir.

Daha zor durumlar için bisect komutunu kullanırsınız. Bisect, çalışan ve bozuk iki commit arasında ikili arama yapar. Siz her adımda "bu sürüm iyi" veya "bu sürüm kötü" dersiniz, Git de aralığı yarıya indirir. Böylece yüzlerce commit arasından sorunu getiren değişikliği birkaç adımda bulursunuz.

Bu araçların verimi, commit kalitesine bağlıdır. Küçük ve açıklayıcı commitlerde bisect sorunu hızlıca teşhis eder. Öte yandan "haftanın işleri" gibi dev bir commit bulduğunuzda arama orada durur ve yine satır satır okumaya dönersiniz.

GitHub'da dal koruma ve otomatik kontroller neden önemlidir?

Dal koruma kuralları, main dalına doğrudan push yapılmasını engeller ve birleştirme için koşul koyar. Örneğin en az bir onay, başarılı testler ve güncel dal şartı ekleyebilirsiniz. Böylece en deneyimli geliştirici bile yorgun bir akşam kontrol edilmemiş kodu yayına sokamaz.

GitHub Actions ile pull request açıldığında testleri, kod biçimi kontrolünü ve derlemeyi otomatik çalıştırırsınız. Web projelerinde ben buna bağlantı ve SEO kontrollerini de eklerim; örneğin robots.txt dosyasının yanlışlıkla bütün siteyi engellemediğini doğrulamak. Bu dosyayı hazırlamak için robots.txt oluşturucu aracından yararlanabilirsiniz.

Otomatik kontroller insan incelemesinin yerini tutmaz, ama onu tekrar eden işlerden kurtarır. İnceleyici virgül hatalarıyla uğraşmak yerine mimariye ve mantığa odaklanır. Kısacası makine sıkıcı olanı, insan anlamlı olanı kontrol eder.

Web projelerinde Git'i yayın süreciyle nasıl bağlarsınız?

Git'in en büyük kazancı, yayını tekrar edilebilir hâle getirmesidir. FTP ile tek tek dosya yüklemek yerine main dalına birleşen her değişiklik otomatik olarak sunucuya gider. Bu yaklaşım hem hızlıdır hem de hangi sürümün canlıda olduğunu her an bilmenizi sağlar.

Benim kurduğum düzende genellikle üç ortam bulunur: yerel geliştirme, test sunucusu ve canlı site. Pull request birleştiğinde test sunucusu kendini günceller, kontrol sonrasında da sürüm etiketiyle canlıya çıkarım. Sürüm etiketlerini git tag ile atarsınız; bir sorun çıktığında önceki etikete dönmek dakikalar alır.

Site yenileme gibi büyük değişikliklerde bu disiplin daha da önemli. URL yapısı değişiyorsa yönlendirmeleri de aynı pull request içinde incelemek gerekir. Bu konuda site taşıma kontrol listesi yazısı faydalı olur. Kurumsal projelerde bu altyapıyı web tasarım hizmeti kapsamında baştan kuruyorum.

Git komutlarını kısaltmak için takma ad nasıl tanımlarsınız?

Her gün onlarca kez yazdığınız komutları kısaltmak zaman kazandırır. Git bunun için alias adında bir özellik sunar. Örneğin git config --global alias.st status yazdığınızda artık git st komutu status ile aynı işi görür.

Benim en çok işime yarayan takma adlar şunlar:

• Durum için st, commit için ci ve dal değiştirmek için sw.
• Geçmişi grafik hâlinde görmek için log --oneline --graph --all komutunu lg olarak kaydetmek.
• Son commiti hazırlık alanına geri almak için reset HEAD~1 --soft komutunu undo olarak tanımlamak.

Yine de ölçülü olun. Takma adları öğrenmeden önce asıl git komutlarını bilmeniz gerekir, çünkü başka bir makinede veya bir ekip arkadaşınızın bilgisayarında bu kısayollar olmaz. Ayrıca belgelerde ve hata mesajlarında her zaman tam komut adlarını görürsünüz. Kısacası alias bir konfor aracıdır, temel bilginin yerine geçmez.

Yeni başlayanların en sık yaptığı Git hataları nelerdir?

Yıllar içinde ekiplerde gördüğüm hatalar birbirine çok benziyor. Neyse ki hepsinin basit bir önlemi var. En sık karşılaştıklarım şunlar:

• Doğrudan main dalında çalışmak ve her şeyi oraya göndermek.
• Günlerce commit atmadan çalışıp sonunda dev bir değişiklik göndermek.
• Şifre, API anahtarı veya .env dosyasını depoya eklemek.
• Ortak dalda zorla push kullanıp başkasının işini silmek.
• Pull yapmadan push denemek ve çıkan uyarıyı görmezden gelmek.
• Anlamsız commit mesajlarıyla geçmişi okunamaz kılmak.

Zorla push konusunda özellikle dikkatli olun. Kendi dalınızı rebase ettikten sonra gerekiyorsa git push --force-with-lease kullanın. Bu seçenek, uzak dalda sizin görmediğiniz bir değişiklik varsa işlemi durdurur ve başkasının işini ezmenizi engeller.

Git komutlarını öğrenmek için nasıl bir yol izlemelisiniz?

Git'i ezberleyerek değil, kullanarak öğrenirsiniz. Önerim, günlük döngüdeki yedi komutla başlamanız: status, add, commit, log, diff, pull ve push. Bunlar oturduktan sonra dallara, ardından merge ve çakışma çözmeye geçin. Rebase, bisect ve reflog gibi git komutları ihtiyaç duydukça gelir.

Deneme yapmak için önemsiz bir depo açın ve bilerek çakışma üretin. İki dalda aynı satırı değiştirip birleştirmeye çalışın; çözümü sakin bir ortamda bir kez yaşamak, gerçek projede panik yapmanızı engeller. Ayrıca grafik arayüzler faydalıdır, ama arka planda hangi komutun çalıştığını bilmek sorun çıktığında sizi kurtarır.

Son olarak ekip içinde kısa bir kural belgesi yazın: dal adlandırma, commit biçimi, pull request şablonu ve birleştirme yöntemi. Bu belge bir sayfayı geçmez, ama yeni gelen herkesin ilk haftasını kolaylaştırır. Git'i iyi kullanan bir ekip, daha az kriz ve daha öngörülebilir yayınlar demektir.