commonmarker 0.0.1 → 0.1.0

data/test/progit/tr/04-git-server/01-chapter4.markdown

@@ -0,0 +1,73 @@
+# Uzak Serverda Git #
+
+Şu anda, Git kullanırken günlük ihtiyacınız olacak işleri yapabiliyor olmalısınız. Ancak, Git üzerinde takım arkadaşlarınızla işbirliğinde bulunmak için bir uzak Git reposuna ihtiyacınız var. Diğer insanların yerel repoları üzerinde pull ya da push işlemleri yapmanız teknik olarak mümkün olsa da, bunu yapmak cesurcadır çünkü dikkatli olmazsanız insanların çalışmalarını karman çorman etmek oldukça kolaydır. Bunun dışında, ulaşmak istediğiniz Git reposunun sahibi offline olsa da ulaşabileceğiniz ve doğruluğu daha güvenilir ortak bir repo genellikle kullanışlı bir seçenektir. Bunun için, takım arkadaşlarıyla işbirliğinde tercih edilen en yaygın yöntem, takımdaki insanların yazma ve okuma izinlerinin olduğu ortak bir repo kullanmaktır. Bu ortak repoya bundan sonra "Git Sunucusu" diyeceğiz. Fakat yakında farkedeceğiniz üzere Git çok az sistem kaynağı kullanır ve bunun için bütün bir sunucu kullanmaya genelde gerek olmaz.
+
+Bir Git Suncusu çalıştırmak kolaydır. Öncelikle, sunucunuzla hangi protokollerden iletişim kuracağınızı belirlemelisiniz. Bu bölümün ilk kısmında mevcut protokoller ve bunları artıları/eksilerinden bahsedeceğiz. Gelecek bölümlerde ise bu protokollerı kullanarak bazı tipik kurulumlarla sunucunuzu nasıl ayağa kaldıracağınızı anlatacağız. Son olarak, bazı hosted(3. kişiler tarafından barındırılan) servislerden bahsedeceğiz. Eger kodunuzun başka insanların sunucularında barınması sizin için problem değilse ve bakım-kurulum işleri ile uğraşmak istemiyorsanız bu seçenekleri de değerlendirebilirsiniz.
+
+Eğer kendi sunucunuzu kurmak ile ilgilenmiyorsanız, doğrudan bu bölümün son kısmına geçebilir ve kullanabileceğiniz bazı servisleri görebilirsiniz. Sonrasında dağıtık kaynak kontrol ortamlarında çalışmanın getiri ve götürülerinden bahsedeceğimiz bir sonraki bölüme geçebilirsiniz.
+
+Bir uzak repo _çıplak(bare) repo_ genellikle hiç bir şey eklenmemiş, boş bir haldedir. Repo yalnızca işbirliği noktası olarak kullanılacağından, projenin disk üzerinde bir kopyasını tutmak anlamsızdır. Yalnızca Git bilgisi yeterlidir. En basit anlatımıyla, çıplak repo projeinizin yalnızca `.git` klasörünü içerir.
+
+## Protokoller ##
+
+Git data transferi için başlıca dört adet ağ protokolü kullanır: Local, Secure Shell (SSH), Git and HTTP. Burada bu protokoller nedir ve temel koşullarda hangisini kullanmalıyız ya da kullanmamalıyoz tartışacağız.
+
+Burada önemli olarak HTTP protokolünü ayrı tutacağız, çünkü Git kurulan bütün serverlerda HTTP protokolü bulunması gerekir.
+
+### Lokal Protokoller ###
+
+En temel olanı, uzak reponun diskimizdeki başka bir klasör olduğu lokal protokoldür. Bu genellikle ekibinizdeki herkes NFS mount vb. şeklinde paylaşılan dosyalara erişiyorsa veya az kullanılan bir yöntem olarak; işler herkesin kullanıcı girişi yaptığı bir bilgisayar üzerinde yürütülüyorsa kullanılır. İkincisi ideal olmaz, çünkü tüm repoların aynı bilgisayarda bulunması bir kayıpta felaket olurdu.
+
+Eğer paylaşılan bir dosya sisteminiz varsa, local file-based reponuzdan clone,push ve pull işlemlerini yapabilirsiniz. Bunları yapmak için URL olarak reponuzun klasör yolunu kullanmalısınız. Örneğin, lokal repo kolanlayım, böyle bir komut çalıştırabilirsiniz.
+
+	$ git clone /opt/git/project.git
+
+Ya da:
+
+	$ git clone file:///opt/git/project.git
+
+Eğer URL'inizin başında açıkça `file://` belirtirseniz, Git biraz farklı çalışır. Sadece yolu belirtirseniz; ve kaynak ile hedef aynı dosya sisteminde ise, Git ihtiyacı olan objeleri hardlink ile bağlamaya çalışır. Eğer aynı dosya sisteminde değillerse; gerekli ihtiyacı olan dosyaları üzerinde bulunduğu sistemin standart kopyalama fonksiyonalitesini kullanarak kopyalayacaktır. Eğer `file://`ı belirtirseniz; Git normalde dosyaları transfer etmek için kullandığı ve daha verimsiz olan ağ üzerinden transfer yöntemini kullanmaz. `file://`ı belirtmenin ana sebebi genellikle başka bir versiyon kontrol sisteminden içe aktarma gibi işlemler yapıldıktan sonra (bakım işlemleri ile ilgili 9. bölümü inceleyin) yabancı referanslar ve kalıntı objeler içeren reponuzun temiz bir kopyasını almaktır. Biz daha hızlı olduğu için burada normal yolu kullanacağız.
+
+Varolan bir Git projesine lokal repo eklemek için aşağıdaki gibi bir kod çalıştırmalısınız;
+
+	$ git remote add local_proj /opt/git/project.git
+
+Sonra, bir network üzerinden yapıyormuşsunuz gibi o remote üzerinde pull ve push yapabilirsiz.
+
+#### Artıları ####
+
+File-based depoların artıları basit olmaları ile mevcut dosya izinlerini ve ağ erişimini kullanabilir olmasıdır. Eğer paylaşılan bir dosya sisteminiz varsa, ekibiniz için bir repo kurmak çok kolay bir işlemdir. Herhangi diğer bir paylaşılan klasörde yaptığınız gibi, herkesin paylaşılan izinlerinin olduğu bare repo kopyasında kalırsınız ve yazma/okuma izinlerini ayarlayabilirsiniz. Bir sonraki bölümde “Serverda Git.” bare reponun kopyasını nasıl export alırız ele alacağız.
+
+Bu aynı zamanda başkasının reposundan çalışmasını hızlıca almak için güzel bir seçenek. Eğer siz ve arkadaşınız aynı projede çalışıyorsanız onlar sizin yaptıklarınızı kontrol etmek isteyeceklerdir, bunun için `git pull /home/john/project` gibi bir komut çalıştırmak genellikle servera push etmek ve pull etmekten daha kolaydır.
+
+#### Eksileri ####
+
+Bu yöntemin eksileri genellikle paylaşılan erişimi kurmak ve bir çok yerden erişmek temel ağ erişiminden daha zordur. Eğer evinizdeki bilgisiyarınızdan uzak diskinize push etmek istiyorsanız ağ tabanlı erişim zor ve yavaş olabilir.
+
+Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır.
+
+### SSH Protokolü ###
+
+Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır.
+
+Git reposunu SSH üzerinden clonelarken, URL'i ssh:// şeklinde belirtmelisiniz. Örnek:
+
+	$ git clone ssh://user@server/project.git
+
+Ya da SSH için kısaca scp-like yazımını kullanabilirsiniz:
+
+	$ git clone user@server:project.git
+
+Siz bir kullanıcı belirlemezseniz, Git geçerli oturum açmış olan kullanıcıyı varsayar.
+
+#### Artıları ####
+
+SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğeri SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Son olarak SSH'ın bir artısı da verileri akatarmadan önce mümkün olduğunca kompakt hale getiriyor.
+
+#### Eksileri ####
+
+Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir.Yalnızca kurumsal ağ içerisinde bunu kullanıyorsanız SSH kullanmanız gereken protokollerden belki de tekidir. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir.
+
+### Git Protokolü ###
+
+Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. Bir reponun Git protokolü üzerinden sunulması için, 'git-daemon-export-ok' dosyasını oluşturmalısınız - Daemon, içinde bu dosya olmayan bir git reposunu sunmaz. - fakat bunun dışında, güvenlik yoktur. Ya clonelanabilir bir Git reposu mevcuttur ya da herkes clonelayamaz. Bu, genel olarak bu protokol üzerinden psuh yapıldığı anlamına gelir. Push erişimi sağlar; fakat eksik bir kimlik doğrulamada internet üzerinde projenizin URL'i bulunur ve push edilebilir. Fakat bu durum çok nadir olur.

data/test/progit/tr/05-distributed-git/01-chapter5.markdown

@@ -0,0 +1,215 @@
+# Dağıtık Git #
+
+Artık tüm developerların kodunu paylaşacağı bir uzak git reposuna sahipsiniz ve yerel çalışma akışınızda kullanacağınız temel Git komutlarına aşinasınız. Artık Git'in size sağladığı bazı dağıtık çalışma akışlarını nasıl kullanacağımıza bakacacağız.
+
+Bu bölümde, dağıtık bir Git ortamında katılımcı ve koordinatör olarak nasıl çalışacağınızı göreceksiniz. Bir çok geliştiricinin çalıştığı projelere nasıl katkı sağlayacağınızı ve projenin sürdürülebilirliğini nasıl sağlayacağınızı öğreneceksiniz.
+
+## Dağıtık Çalışma Akışları ##
+
+Merkezi Versiyon Kontrol Sistemlerinden (CVCSs) farklı olarak, Git'in dağıtık yapısı geliştiricilerin projelerde nasıl işbirliği yapacağı konusunda daha esnek davranmanıza izin verir. Merkezi sistemlerde, her bir geliştirici merkez çevresinde az veya çok çalışan bir noktacıktır. Git'te ise; her bir geliştirici potansiyel olarak bir noktacık veya bir merkez olabilir. Her bir geliştirici başka repolar üzerindeki kodlara katkı sağlayabilir ve aynı zamanda başkalarının katkı sağladığı bir reponun koordinatörlüğünü üstlenebilir. Bu takımınıza ve projenize sonsuz sayıda çalışma akışı için imkan sağlar. Burada bu esnekliğin avantajlarını kullanan bazı çok kullanılan çalışma tasarım desenlerinden(pattern) bahsedeceğim. Her bir desenin güçlü ve zayıf yanlarının üzerinden geçeceğim. Böylece bunlardan birini seçebilirsiniz ya da ihtiyaçlarınıza göre şekillendirerek/karıştırarak kullanabilirsiniz.
+
+### Merkezi Çalışma Akışı (Centralized Workflow) ###
+
+Merkezi sistemlerde, genellikle tek bir katılım modeli vardır: Merkezi Çalışma Akışı. Kod katılımını kabul edebilen tek bir merkez veya repo bulunur ve herkes çalışmasını bu merkezle senkronize eder. Geliştiriciler bu merkezin çevresindeki noktacıklardır ve bu tek merkeze senkronize olurlar (Resim 5-1).
+
+Insert 18333fig0501.png
+Resim 5-1. Merkezi çalışma akışı.
+
+Bu şu anlama gelir; eğer iki geliştirici bir merkezden repoyu klonlar ve değişiklikler yapar, ardından ilk geliştirici değişikliklerini merkeze gönderirse herhangi bir sıkıntı olmaz. Ancak ikinci geliştirici ilk geliştiricinin değişiklilerinin üzerine yazmadığından emin olmak için değişikliklerini göndermeden önce merkezi reponun son halini kendisine almalı ve kendi değişiklikleriyle birleştirmelidir. Bu konsept Git ya da Subversion (ya da herhangi bir  CVCS)'de mevcuttur, ve Git'de çok iyi çalışır.
+
+Eğer küçük bir takımsanız veya merkezi çalışma akışından hali hazırda memnunsanız bu akışı Git ile kullanmaya devam edebilirsiniz. Tek bir repo oluşturun, ve takımdaki herkese bu repoya push edebilme izni verin; Git geliştiricilerin birbirlerinin değişikliklerini ezmesine izin vermeyecektir. Eğer bir geliştirici repoyu klonlar, değişiklikler yapar ve ardından değişikliklerini push etmeye çalışırsa ve o esnada başka bir geliştirici değişiklikler yapıp push ettiyse git sunucusu değişiklikleri reddedecektir. non-fast-forward(hızlı-ileri-olmayan?) değişiklikler yaptığı şeklinde bir hata alacak ve repodan fetch ve merge yapmadığı sürece değişikliklerini gönderemeyecektir.
+Bu paradigma birçok insanı kendine çeker çünkü birçok kişiye tanıdık gelen ve rahat olabildikleri bir konsepttir.
+
+### Entegrasyon Yöneticili Çalışma Akışı (Integration-Manager Workflow) ###
+
+Git birden çok uzak repoyla çalışmanıza izin verdiğinden, her geliştiricinin kendi reposuna yazma izni ve diğer tüm repolara okuma izni olan bir çalışma akışı mümkündür. Bu senaryoda genellikle projeyi "resmi" olarak temsil eden ve doğruluğndan emin olunan bir repo bulunur. Bu repoya katkıda bulunmak için reponun kendinize ait olan klonun oluşturur ve kendi reponuz üzerinde çalışırsınız. Sonrasında ana proje reposunu yöneten kişiye sizin reponuzdaki değişiklikleri ana repoya alması için bir istekte bulunursunuz. Yönetici sizin reponuzu kendisine uzak sunucu olarak ekler, değişikliklerinizi test eder, ana repodaki branch ile birleştirir ve ana repoya gönderir. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-2):
+
+1. Yönetici projenin genel reposuna push eder.
+2. Geliştirici o repoyu kendisine klonlar ve değişiklilerini yapar.
+3. Geliştirici değişikliklerini kendi reposuna gönderir.
+4. Geliştirici yöneticiye değişiklilerini çekmesi için bir istekte bulunur (email vs.).
+5. Yönetici geliştiricinin reposunu kendisine bir remote olarak ekler ve local olarak değişiklikleri birleştirir.
+6. Yönetici birleştirilmiş değişiklikleri ana repoya gönderir.
+
+Insert 18333fig0502.png
+Figure 5-2. Entegrasyon Yöneticili Çalışma Akışı
+
+Bir projeyi fork etmek ve o fork üzerinde çalışmak gibi işlemlerin kolay olduğu, Github gibi sitelerle birlikte bu çok kullanılan bir çalışma akışıdır. Bu yaklaşımın ana kazanımlarından biri geliştirici çalışmaya devam ederken yönetici geliştiricinin değişikliklerini herhangi bir zamanda ana repoya alabilir. Katılımcılar projenin kendi değişikliklerini dahil etmesini beklemek zorunda değildir. Herkes kendi alanında çalışabilir.
+
+### Diktatör ve Yüzbaşılar Çalışma Akışı (Dictator and Lieutenants Workflow) ###
+
+Bu çoklu repo çalışma akışının bir varyasyonudur. Genellikle yüzlerce katılımcının olduğu devasa projelerde kullanılır; meşhur bir örnek Linux çekirdeğidir. Bir çok entegrasyon yöneticisi projenin çeşitli yerlerinden sorumludur; bu kişiler yüzbaşılardır. Tüm yüzbaşıların üstünde ise 'iyiliksever diktatör' denilen tek bir entegrasyon yöneticisi vardır. İyiliksever diktatörün reposu tüm katılımcıların pull etmesi gereken referans repo konumundadır. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-3):
+
+1. Normal geliştiriciler kendi topic branch(konu dalı)lerinde çalışırlan ve değişikliklerini diktatörün master branchi üzerinde rebase ederler.
+2. Yüzbaşılar geliştiricilerin branchlerini kendi master branchlerine birleştirirler.
+3. Diktatör yüzbaşıların master branchini kendi master branchine birleştirir.
+4. Diktatör kendi master branchini referans repoya gönderir. Böylece diğer developerlar bunun üzerine rebase edebilirler.
+
+Insert 18333fig0503.png
+Resim 5-3. Diktatör ve Yüzbaşılar Çalışma Akışı.
+
+Bu tarz bir çalışma akışı çok yaygın değildir fakat büyük projelerde veya çok hiyerarşik ortamlarda kullanışlı olabilir. Çünkü bu akış proje liderine (diktatör) görevlerin çoğunu dağıtma ve büyük kod setlerini entegre etmeden önce toplama imkanı sunar.
+
+Bunlar Git gibi dağıtık sistemlerde mümkün olan çalışma akışlarından çok yaygın olan birkaçıydı. Sizin takım yapınıza ve çalışma şeklinize uygun olan daha başka yöntemler bulunabilir. Artık (umarım) hangi çalışma akışı kombinasyonunun size uyacağına karar verebilirsiniz. Şimdi daha özele inen bazı örneklerle değişik senaryolarda mümkün olabilecek rollerin çalışma akışlarından bahsedelim.
+
+## Bir Projeye Katılım Sağlamak ##
+
+Artık değişik çalışma akışlarını biliyor ve temel Git kullanımını iyice kavramış olmanız gerekiyor. Bu bölümde, bir projeye katkı sağlarken kullanılabilecek bazı genel pattern(desen)lardan bahsedeceğiz.
+
+Bu işlemi açıklamanın en zor tarafı, nasıl yapılacağı ile ilgili çok fazla sayıda varyasyon olmasıdır. Çünkü Git çok esnektir ve insanlar bir arada çok farklı şekillerde çalışabilirler ve her proje birbirinden farklıdır. Bu da bir projeye nasıl katılım sağlanacağı konusunu anlatmayı problemli bir hale getirmektedir. İlişkili bazı değişkenler; aktif katılımcı sayısı, seçilen çalışma akışı, commit erişiminiz ve belki dışarıdan katılım metodudur.
+
+İlk değişken; aktif katılımcı sayısı. Kaç kişi bu projeye ne sıklıkla kod katılımı sağlıyorlar? Birçok durumda iki-üç geliştiriciniz ve her geliştirici için günde birkaç commit olacaktır; atıl projeler için belki daha az. Fakat gerçekten büyük şirketler ve projeler için, binlerce geliştirici ve her gün düzinelerce hatta yüzlerce yama olabilir. Bu önemlidir çünkü geliştici sayısı arttıkça, kodunuzun temizce uygulanması ve kolayca birleştirilmesi konusunda daha çok sıkıntı yaşayacaksınız. Değişiklikleriniz, siz çalışırken veya değişikliklerinizin birleştirilmesini beklerken başka geliştiricilerin değişikliklerinin birleştirilmiş olmasından dolayı eski kalmış ya da kısmen/tamamen bozulmaya sebep olmuş olabilir. Peki kodunuzu nasıl düzenli olarak güncel ve değişikliklerinizi güncel tutacaksınız?
+
+Diğer değişken; projeniz için kullandığınız çalışma akışı. Her geliştiricinin kod üzerinde eşit yazma hakları olacak şekilde merkezi mi? Projede tüm yamaları kontrol eden bir entegrasyon yöneticisi var mı? Tüm yamalar başka geliştiriciler kontrol edilip mi onaylanıyor? Siz bu süreçte var mısınız? Bir yüzbaşı sistemi var ve öncelikle değişikliklerinizi onlara mı göndermek durumundasınız?
+
+Diğer bir sorun ise commit erişiminiz. Çünkü bir projeye doğrudan yazma izninizin olup olmaması o projede uygulanması gereken çalışma akışını çok etkiler. Eğer yazma izniniz yoksa, prje katılımcıların çalışmalarını ne şekilde kabul etmeyi tercih ediyor? Bir politikasi var mı? Tek seferde ne kadarlık bir katılım sağlıyorsunuz? Ne sıklıkla katılım sağlıyorsunuz?
+
+Tüm bu sorular nasıl verimli bir şekilde katılım sağlayacağınızı, sizin için ne şekilde çalışma akışları mevcut olacağını ve tercih edildiğini etkileyecektir. Bunların her birini ve yönlerini, basitten karmaşığa doğru giderek ve bir seri kullanım durumları halinde inceleyeceğiz. Sonrasında ihtiyaç duyduğunuz çalışma akışını bu örneklerden yola çıkarak oluşturabilirsiniz.
+
+### Commit Prensipleri ###
+
+Özel kullanım durumlarına bakmadan önce, commit mesajları hakkında küçük bir not düşelim. Commit oluşturmak ile ilgili iyi prensiplere sahip olmak ve bunlara uymayı sürdürmek Git ile çalışmayı ve diğer geliştiricilerle yapılan işbirliğini çok kolaylaştırır. Git projesinin kendisine gönderilen yamalar iyi commitler oluşturmak için bize birçok ipucu sunmaktadır. Aynı zamanda Git kaynak kodunda `Documentation/SubmittingPatches` dosyasını okuyabilirsiniz.
+
+Öncelikle, hiç bir beyaz-boşluk hatasını göndermek istemezsiniz. Git bunun kontrolü için kolay bir yol sunmaktadır. Commit etmeden önce `git diff --check` çalıştırırsanız, Git olası beyaz-boşluk hatalarını bulacak ve sizin için listeleyecektir. Bir örnek: (terminaldeki kırmızı renkler `X` ile değiştirilmiştir)
+
+	$ git diff --check
+	lib/simplegit.rb:5: trailing whitespace.
+	+    @git_dir = File.expand_path(git_dir)XX
+	lib/simplegit.rb:7: trailing whitespace.
+	+ XXXXXXXXXXX
+	lib/simplegit.rb:26: trailing whitespace.
+	+    def command(git_cmd)XXXX
+
+Eğer commit etmeden önce bu komutu çalıştırırsanız, neredeyse muhtemelen diğer geliştiricileri rahatsız edecek olan beyaz-boşlukları commit ediyor olduğunuzu görürsünüz.
+
+Her bir commit'i mantıklı bir biçimde ayrılmış olarak yapın. Yapabiliyorsanız, değişikliklerinizi olabildiğince hafif yapın. Yani tüm haftasonu 5 sorun üzerine çalışıp da Pazartesi günü hepsini tek bir devasa commit halinde göndermeyin. Haftasonu boyunca commit yapmadıysanız bile, Pazartesi günü staging alanını kullanarak çözdüğünüz sorunların her birini mantıklı mesajlar içeren ayrı commitler haline getirin. Eğer bazı değişiklikler aynı dosyayı etkiliyorsa `git add --patch` kullanarak dosyaları kısmı olarak staginge almaya çalışın (6. bölümde bahsedeceğiz). 5 commit ya da tek commit yaptığınızda projenin sonuçtaki hali değişmez. Ama sizinle birlikte çalışanların işlerini neden zorlaştıralım ki? Bu yaklaşım aynı zamanda gerekirse değişikliklerden birini ya da birkaçını çıkarmak ya da geri çevirmek gerektiğinde de çok işe yarayacaktır. 6. Bölüm geçmişi baştan yazmak ve dosyaları interaktif olarak stage etmek için gerekli olan birçok kullanışlı Git ipuçlarını içermektedir. Temiz ve anlaşılabilir bir geçmiş oluşturmak için bu araçları kullanın.
+
+Aklımızdan çıkarmamamız gereken son şey ise commit mesajıdır. Kaliteli ve anlaşılabilir commit mesajları yazmayı alışkanlık haline getirmek Git ile çalışmayı ve işbirliği yapmayı çok kolaylaştıracaktır. Genel bir kural olarak, mesajınız 50 karakterden uzun olmayan ve değişiklikleri kısaca anlatan bir satır ardından bir boş satır ve devamında ayrıntılı bir açıklama şeklinde olmalıdır. Git projesinde bu detaylı açıklamanızın sizi bu değişikliğe iten sebepleri ve sizin yaptığınızla önceki arasındaki farkları açıklamanız istenmektedir. Aşağıdaki örnek ilk olarak Tim Pope tarafından tpope.net'te İngilizce olarak yazılmıştır:
+
+	Kısa (50 ya da daha az karakter) bir özet
+
+	Gerekiyorsa, daha detaylı ve açıklayıcı bir metin. Satır uzunluğunu
+	72 karakter civarında tutmaya çalışın. İlk satırı bir e-mailin konusu
+	ve bu metni de mailin kendisi olarak düşünebilirsiniz. Boş satır
+	ise konu ve mailin metnini ayırmaktadır. Eğer detaylı metin yazıyorsanız
+	bu boş satır önemlidir çünkü kullanmadığınız durumlarda rebase gibi
+	araçlar karışık hale gelebilir.
+
+	Yeni paragraf yazmanız gerektiğinde yine boş bir satır bırakın.
+
+	 - Bullet listeler de kullanılabilir
+
+	 - Tipik olarak bir tire ya da yıldızı takip eden bir boşluk ve metin şeklinde
+	  liste elemanları oluşturulabilir.
+
+Eğer tüm commit mesajlarınız böyle görünürse, herşey siz ve birlikte çalıştığınız geliştiriciler için daha kolay olacaktır. Git projesinin kendisi çok iyi formatlanmış commit mesajlarına sahiptir. İyi formatlanmış commit mesajlarına sahip bir proje geçmişinin nasıl göründüğünü görmeniz için sizi, Git projesi üzerinde `git log --no-merges` komutunu çalıştırmaya davet ediyorum.
+
+Bu kitabın tamamı boyunca sadelik uğruna mesajları böyle güzel biçimde yazmayacağım. Bunun yerine `git commit` komutunu `-m` ayarı ile çağırarak mesajlarını yazacağım. İmamın dediğini yap, yaptığını yapma :)
+
+### Özel(dışarıya kapalı) Küçük Takım ###
+
+Muhtemelen karşılacağınız en temel senaryo, özel bir projeye üzerinde çalışan iki veya daha fazla geliştiricidir. Özel derken, kapalı kaynaklı ve proje dışındaki insanlar tarafından kaynağı görülemeyen projelerden bahsediyorum. Siz ve tüm geliştiriciler projeye yazma hakkına sahipler.
+
+Bu ortamda, Subversion ya da başka bir merkezi sistemde takip ettiğiniz çalışma akışını takip edebilirsiniz. Offline commit ve büyük ölçüde daha kolay olan branchler ve birleştirmenin avantajlarını halen kullanabilirsiniz. Ama çalışma akışı halen çok benzer olabilir, en temel fark ise birleştirmelerin sunucuda olması yerine istemci tarafında commit anında olmasıdır.
+İki geliştiricinin ortak bir repoda çalışmaya başlamasıyla ne olacağına bakalım. İlk geliştirici Burak repoyu klonlar, bir değişiklik yapar ve yerel olarak commit eder. (Örnekleri kısaltmak adına protokol mesajları yerine `...` yazıyorum)
+
+	# Burak's Machine
+	$ git clone john@githost:simplegit.git
+	Initialized empty Git repository in /home/burak/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim lib/simplegit.rb
+	$ git commit -am 'geçersiz varsayılan değer kaldırıldı'
+	[master 738ee87] geçersiz varsayılan değer kaldırıldı
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+İkinci geliştirici Nesrin de aynı şeyi yapar. Repoyu klonlar ve bir değişiklik commit eder:
+
+	# Nesrin's Machine
+	$ git clone nesrin@githost:simplegit.git
+	Initialized empty Git repository in /home/nesrin/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim TODO
+	$ git commit -am 'sıfırlama görevi eklendi'
+	[master fbff5bc] sıfırlama görevi eklendi
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Şimdi Nesrin çalışmasını uzak sunucudaki repoya pushlar:
+
+	# Nesrin's Machine
+	$ git push origin master
+	...
+	To nesrin@githost:simplegit.git
+	   1edee6b..fbff5bc  master -> master
+
+Burak da kendi değişikliğini pushlamaya çalışır:
+
+	# Burak's Machine
+	$ git push origin master
+	To burak@githost:simplegit.git
+	 ! [rejected]        master -> master (non-fast forward)
+	error: failed to push some refs to 'burak@githost:simplegit.git'
+
+Burak'a izin verilmez çünkü o esnada Nesrin push yapmıştır. Eğer önceden Subversion kullandıysanız bunu anlamanız önemlidir. 2 geliştirici farklı dosyaları düzenlemiştir. Eğer farklı dosyalarda değişiklik yapıldıysa Subversion otomatik olarak sunucuda bir birleştirme yapacaktır. Git'te ise commitleri kendi yerelinizde birleştirmelisiniz. Burak push yapmadan önce Nesrin'in değişikliklerini kendisine çekmeli, ve kendi değişiklikleriyle birleştirmelidir:
+
+	$ git fetch origin
+	...
+	From burak@githost:simplegit
+	 + 049d078...fbff5bc master     -> origin/master
+
+Bu noktada Burak'ın yerel reposu Resım 5-4'teki gibi gorunecektir.
+
+Insert 18333fig0504.png
+Figure 5-4. Burak'ın baştakı reposu.
+
+Artık Burak Nesrin'in yaptığı değişikliklerin bir referansına sahip. Şimdi kendi değişiklikleri ile Nesrin'in değişikliklerini birleştirip sonrasında repoya push edebilir.
+
+	$ git merge origin/master
+	Merge made by recursive.
+	 TODO |    1 +
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Eğer birleştirme sorunsuz giderse Burak'ın commit geçmişi Resim 5-5deki gibi olacaktır.
+
+Insert 18333fig0505.png
+Figure 5-5. `origin/master` ile birleştirdikten sonra Burak'ın reposu.
+
+Şimdi, Burak herşeyin hala düzgün olduğundan emin olmak için test edip ardından değişikliklerini sunucuya gönderebilir:
+
+	$ git push origin master
+	...
+	To burak@githost:simplegit.git
+	   fbff5bc..72bbc59  master -> master
+
+Sonuç olarak Burak'ın commit geçmişi Resim 5-6daki gibi görünür.
+
+Insert 18333fig0506.png
+Figure 5-6. Origin sunucuya gönderdikten sonra Burak'ın commit geçmişi.
+
+Aynı esnada Nesrin de bir konu branchinde çalışmaktadır. `issue54` isminde bir branch oluşturmuş ve bu branche 3 commit yapmıştır ve henüz Burak'ın yaptığı değişiklileri kendisine çekmemiştir. Commit geçmişi Resim 5-7deki gibidir.
+
+Insert 18333fig0507.png
+Figure 5-7. Nesrin'in baştaki commit geçmişi.
+
+Nesrin Burak ile senkronize olmak ister ve fetch eder:
+
+	# Nesrin's Machine
+	$ git fetch origin
+	...
+	From nesrin@githost:simplegit
+	   fbff5bc..72bbc59  master     -> origin/master
+
+Bu Burak'ın pushladığı çalışmaları çeker. Jessica'nın geçmişi şimdi Resim 5-8deki gibidir.
+
+Insert 18333fig0508.png
+Figure 5-8. Burak'ın değişikliklerini fetch ettikten sonra Nesrin'in geçmişi.
+
+Nesrin kendi branchinin hazır olduğunu düşünür, fakat neleri birleştirmesi gerektiğini görmek istemektedir. `git log` çalıştırarak bunu görebilir:
+
+	$ git log --no-merges origin/master ^issue54
+	commit 738ee872852dfaa9d6634e0dea7a324040193016
+	Author: Burak Can <bcan@example.com>
+	Date:   Fri May 29 16:01:27 2009 -0700
+
+	    geçersiz varsayılan değer kaldırıldı

data/test/progit/uk/01-introduction/01-chapter1.markdown

@@ -0,0 +1,522 @@
+# Введення #
+
+<!-- # Getting Started # -->
+
+В цьому розділі йдеться про початок роботи з Git.
+
+Знайомство відбувається поступово: пояснення основних принципів роботи систем контролю версій, потім інструкція з запуску Git у вашій системі та врешті-решт опис його налаштування для початку роботи.
+
+Наприкінці розділу ви вже розумітимете передумови виникнення Git, причини та способи його використання саме у ваших проектах та будете готові до практичних дій у цьому напрямі.
+
+<!-- This chapter will be about getting started with Git.  We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with.  At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so. -->
+
+## Про контроль версій ##
+
+<!-- ## About Version Control ## -->
+
+Що таке контроль версій і навіщо він вам?
+
+Контроль версій здійснює система, що записує та «запам’ятовує» усі зміни одного чи сукупності файлів, завдяки чому ви можете відновити будь-яку версію пізніше.
+
+Не варто надавати багато значення тому, що у прикладах цієї книги в якості файлів для контролю версій використовуються початкові коди програм. Насправді, для контролю версій можуть використовуватись будь-які файли
+
+<!--What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.-->
+
+Якщо ви графічний чи вебовий дизайнер та бажаєте зберігати кожну копію зображення чи шару, то використання системи контролю версій (СКВ) стане навпрочуд мудрим рішенням.
+
+СКВ дозволяє: повертати до попереднього стану будь-які файли чи увесь проект цілком; переглядати зміни зроблені протягом усього часу; бачити хто вносив правки у щось, що могло викликати проблему; хто і коли додав  зауваження та багато інших рречей.
+
+Використання СКВ також передбачає можливість легкого відновлення файлів у разі їх втрати чи пошкодження. На додачу, все це ви отримуєте за досить невеликих витрат часу та ресурсів системи
+
+<!-- If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. -->
+
+### Локальні системи контролю версій ###
+
+<!-- ### Local Version Control Systems ### -->
+
+Багато людей здійснюють контроль версій шляхом простого копіювання файлів до іншої директорії (особливо охайні навіть іменують директорії у хронологічному порядку). Завдяки своїй простоті такий підхід дуже розповсюджений, втім він також неймовірно ненадійний. Адже дуже легко переплутати в якій саме директорії ви зараз знаходитесь і випадково перезаписати не ті файли
+
+<!-- Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. -->
+
+Для вирішення цієї проблеми були створені локальні СКВ, що мали просту базу даних для зберігання усіх змін необхідних файлів. (див. Ілюстрацію 1-1).
+
+<!-- To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1). -->
+
+Insert 18333fig0101.png
+Ілюстрація 1-1. Схема локальної системи контролю версій.
+
+<!-- Figure 1-1. Local version control diagram. -->
+
+Однією з найпопулярніших систем цього типу була rcs, що й досі розповсюджується разом з багатьма комп’ютерами. Навіть операційна система Mac OS X отримує команду rcs після встановлення Developer Tools (Інструменти Розробника). Робота цієї програми заснована на зберіганні сукупності патчів (так називаються відмінності між файлами) між версіями у спеціальному форматі на диску. Вона може відновити стан будь якого файлу у будь-який час шляхом застосування усіх патчів.
+
+<!-- One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches. -->
+
+### Централізовані системи контролю версій ###
+
+<!-- ### Centralized Version Control Systems ### -->
+
+Наступною великою проблемою, з якою зіткнулись люди, стала необхідність співпраці з іншими розробниками. В результаті, справу було вирішено завдяки централізованим системам контролю версій (ЦСКВ). Такі системи, як CVS, Subversion та Perforce, складаються з одного сервера, що зберігає усі контрольовані файли, та деякої кількості клієнтів, які отримують файли з цього «центру». Протягом багатьох років це залишалось стандартом у контролі версій (див. Ілюстрацію 1-2).
+
+<!-- The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). -->
+
+Insert 18333fig0102.png
+Ілюстрація 1-2. Схема централізованої системи контролю версій.
+
+<!-- Figure 1-2. Centralized version control diagram. -->
+
+Така конфігурація має багато переваг, особливо у порівнянні з локальними СКВ. Наприклад, кожен може дізнатись чим займається інший учасник проекту на будь-якому етапі. У адміністраторів є чіткий контроль над тим, хто і що може робити. До того ж, значно простіше адмініструвати централізовану систему, аніж мати справу з локальними базами даних кожного клієнта.
+
+<!-- This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. -->
+
+Втім, і цей підхід має деякі серйозні вади. Найбільш очевидною є безумовна залежність від одного елементу мережі, що являє собою централізований сервер. Якщо на годину вимкнути сервер, то протягом цієї години стає неможливою взаємодія між учасниками системи та збереження версійних змін до об’єктів, над якими ведеться робота. При пошкодженні жорсткого диску з центральною базою даних та відсутності її резервних копій ви втрачаєте абсолютно все — всю історію проекту, за виключенням хіба що поодиноких знімків, які клієнтам пощастило мати на локальних машинах.
+
+Локальні СКВ страждають від тієї ж проблеми — ризик повної втрати проекту у результаті зберігання усієї історії в одному місці.
+
+<!-- However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. -->
+
+### Розподілені системи контролю версій ###
+
+<!-- ### Distributed Version Control Systems ### -->
+
+Ось тут в гру вступають розподілені системи контролю версій (РСКВ). У цих системах (наприклад: Git, Mercurial, Bazaar чи Darcs) клієнти мають не лише останній знімок файлів, вони отримують повне дзеркало репозиторію. Тож, за втрати одного з серверів, за допомогою якого відбувається співпраця, будь-який з клієнтських репозиторіїв може бути скопійований назад на сервер для відновлення. Кожне стягування файлів, по суті є повною резервною копією усіх даних (див. Ілюстрацію 1-3).
+
+<!-- This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). -->
+
+Insert 18333fig0103.png
+Ілюстрація 1-3. Розподілена система контролю версій.
+
+<!-- Figure 1-3. Distributed version control diagram. -->
+
+Крім того, багато з цих систем чудово працюють з декількома віддаленими репозиторіями. Таким чином, у межах одного проекту ви можете співпрацювати з різними групами людей і різними шляхами одночасно. Це дозволяє налаштувати декілька типів робочих процесів, на відміну від централізованих систем.
+
+<!-- Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. -->
+
+## Коротенький екскурс в історію ##
+
+<!-- ## A Short History of Git ## -->
+
+Як і багато інших видатних речей, Git почався з творчого непорозуміння та гарячих протиріч. Ядро Linux це проект з відкритим програмним кодом достатньо великих розмірів. Протягом більшої частини існування ядра (1991-2002 рр.) зміни у коді передавались у вигляді патчів та архівів. У 2002 році у проекті почала використовуватись пропрієтарна РСКВ під назвою BitKeeper.
+
+<!-- As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. -->
+
+У 2005 році взаємовідносини між спільнотою розробників ядра та комерційною компанією, що займалась розробкою BitKeeper, погіршились і право безкоштовного користування продуктом було скасовано. Це спонукало спільноту Linux (і особливо Лінуса Торвальдса, засновника Linux) до створення власного інструменту. У пригоді став досвід використання BitKeeper з усіма його перевагами і недоліками. Головні вимоги до нової системи були такі:
+
+<!-- In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: -->
+
+*   швидкість;
+*   простий дизайн;
+*   підтримка нелінійної розробки (тисячі паралельних гілок);
+*   повна розподільність;
+*   можливість ефективного управління великими проектами на зразок ядра Linux (швидкість та розмір даних).
+
+<!-- 
+*	Speed
+*	Simple design
+*	Strong support for non-linear development (thousands of parallel branches)
+*	Fully distributed
+*	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+-->
+
+Від свого створення у 2005 Git розвивався зберігаючи простоту використання, але не втрачаючи цих початкових орієнтирів. Він неймовірно швидкий, ефективний на великих проектах і має вражаючу систему розгалужування для нелінійної розробки (див. Розділ 3).
+
+<!-- Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). -->
+
+## Основи Git ##
+
+<!-- ## Git Basics ## -->
+
+Отже, що таке Git у двох словах?
+
+Це дуже важливо засвоїти, оскільки, зрозумівши основи та принципи функціонування Git, ви зможете використовувати його більш ефективно і з меншими зусиллями.
+
+На час знайомства з Git спробуйте забути все що ви знаєте про інші СКВ. Це дозволить уникнути деяких непорозумінь.
+
+Git зберігає інформацію та оперує нею дещо по-іншому, ніж інші системи, навіть попри схожий користувацький інтерфейс. Розуміння цих відмінностей допоможе уникнути плутанини у подальшому.
+
+<!-- So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. -->
+
+### Знімки ###
+
+<!-- ### Snapshots, Not Differences ### -->
+
+Однією з головних відмінностей від інших систем (таких як Subversion та подібних їй) є те, як Git сприймає дані.
+
+Більшість СКВ зберігають інформацію як список файлових редагувань. Ці системи (CVS, Subversion, Perforce, Bazaar) розглядають інформацію як список файлів та їх змін, що показано на Ілюстрації 1-4.
+
+<!-- The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4. -->
+
+Insert 18333fig0104.png
+Ілюстрація 1-4. Інші системи зберігають дані як список змін до початкової версії кожного файлу.
+<!-- Figure 1-4. Other systems tend to store data as changes to a base version of each file. -->
+
+Git сприймає та зберігає інформацію по-іншому. Git розглядає свої дані ніби сукупність знімків невеликої файлової системи. Щоразу, при збереженні поточного стану проекту, Git робить знімок (копію) того, як виглядають ваші файли саме у цей момент і зберігає посилання на цей знімок. Для ефективності, якщо файл не змінився, Git не збергіє його знову, а просто робить посилання на ідентичний файл з попередньої фіксації змін. Схематичне зображення такого підходу показано нижче.
+
+<!-- Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5. -->
+
+Insert 18333fig0105.png
+Ілюстрація 1-5. Git зберігає дані як знімки проекту за хронологією.
+
+<!-- Figure 1-5. Git stores data as snapshots of the project over time. -->
+
+Це дуже важлива різниця між Git та іншими СКВ. З цієї причини у Git було заново переосмислено майже кожен аспект контролю версій, що зробило його схожим на мініатюрну файлову систему з деякими неймовірно потужними вбудованими інструментами. Ми познайомимось з деякими перевагами, які ви отримаєте при сприйнятті інформації подібним чином, у третьому розділі, де йдеться про гілки.
+
+<!-- This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. -->
+
+### Майже кожна операція — локальна  ###
+
+<!-- ### Nearly Every Operation Is Local ### -->
+
+Більшість операцій в Git потребують лише локальних файлів та ресурсів для здійснення операцій — немає небхідності у інформації з інших комп’ютерів вашої мережі. Якщо ви працюєте з ЦСКВ, де більшість операцій обтяжені такими мережевими запитами, то цей аспект може привести вас до думки, що боги швидкості наділили Git неземною силою. Через те, що повна історія проекту знаходиться на вашому локльному диску, більшість операцій здійснюються майже миттєво.
+
+<!-- Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network.  If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. -->
+
+Наприклад, для перегляду історії, Git не має потреби брати її з серверу, він просто зчитує її прямо з локальної бази даних. Це означає, що ви отримуєте історію проекту не встигнувши кліпнути оком. Якщо ви бажаєте переглянути відмінності між поточною версією файлу та його редакцією місячної давності, Git знайде копію збережену місяць тому і проведе локальний розрахунок замість того, щоб звертатись за цим до віддаленого серверу чи спочатку робити запит на отримання старішої версії файлу.
+
+<!-- For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. -->
+
+Також це значить, що за відсутності мережевого з’єднання ви не будете мати особливих обмежень. Перебуваючи у літаку чи потязі можна цілком комфортно фіксувати зміни поки не відновите з’єднання з мережею для їх завантаження. Дорогою додому, не маючи змоги належним чином використовувати свій VPN-клієнт, все одно можна продовжувати роботу. В багатьох інших системах подібні дії або неможливі, або пов’язані з безліччю труднощів. Наприклад, в Perforce, без з’єднання з мережею вам не вдасться зробити багато; у Subversion та CVS ви можете редагувати файли, але не можете фіксувати внесені зміни (оскільки немає зв’язку з базою даних). На перший погляд такі речі здаються незначним, але ви будете вражені наскільки велике значення вони можуть мати.
+
+<!-- This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. -->
+
+### Git виконує перевірку цілісності даних ###
+
+<!-- ### Git Has Integrity ### -->
+
+Будь-що у Git, перед збереженням, отримує контрольну суму, за якою потім і перевіряється. Таким чином, неможливо змінити файл чи директорію так, щоб Git про це не дізнався. Цей функціонал вбудовано у систему на найнижчих рівнях і є складовою частиною її філософії. Ви не можете втратити інформацію при передачі чи отримати пошкоджений файл без відома Git.
+
+<!-- Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. -->
+
+Механізм, який використовується для цього контролю, називається хеш SHA-1. Він являє собою 40-символьну послідовність цифр та перших літер латинського алфавіту (a-f) і вираховується на основі вмісту файлу чи структури директорії. Виглядає це приблизно так:
+
+    24b9da6552252987aa493b52f8696cd6d3b00373
+
+При роботі з Git ви постійно зустрічатимете такі хеші. Фактично, Git зберігає все не за назвою файлу, а саме за такими адресами.
+
+<!-- The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. -->
+
+### Git, зазвичай, тільки додає дані ###
+
+<!-- ### Git Generally Only Adds Data ### -->
+
+Коли ви виконуєте певні дії в Git, при цьому, майже завжди відбувається додавання інформації до її бази даних. Дуже складно змусити систему зробити щось невиправне чи повністю видалити дані. Як і в будь-якій СКВ, ви можете втратити чи зіпсувати лише незафіксовані зміни. Але це майже неможливо, коли вже зроблено знімок, особливо, якщо ви регулярно надсилаєте свою базу до іншого репозиторію.
+
+<!-- When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. -->
+
+Це робить використання Git приємним, оскільки можна експериментувати без загрози щось зіпсувати.
+
+Про те, як Git зберігає інформацію та як можна відновити втрачені дані, детальніше розповідається у Розділі 9.
+
+<!-- This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9. -->
+
+### Три стани ###
+
+<!-- ### The Three States ### -->
+
+А зараз, будьте уважні. Це найважливіша річ, яку потрібно запам’ятати, якщо ви хочете щоб подальше вивчення Git пройшло гладко.
+
+Git має три основних стани, у яких можуть перебувати ваші файли: зафіксований, змінений та доданий.
+
+Зафіксований — значить, дані безпечно збережено в локальній базі даних.
+
+Змінений означає, що у файл внесено редагування, які ще не зафіксовано у базі даних.
+
+Доданий стан виникає тоді, коли ви позначаєте змінений файл у поточній версії, готуючи його таким чином до фіксації.
+
+<!-- Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. -->
+
+Це приводить нас до трьох головних відділів проекту під управлінням Git: директорія Git, робоча директорія та область додавання.
+
+<!-- This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. -->
+
+Insert 18333fig0106.png
+Ілюстрація 1-6. Робоча директорія, область додавання та директорія Git.
+
+<!-- Figure 1-6. Working directory, staging area, and git directory. -->
+
+У директорії Git система зберігає метадані та базу даних об’єктів вашого проекту. Це найважливіша частина проекту. Саме вона копіюється при клонуванні проекту з іншого комп’ютеру.
+
+<!-- The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. -->
+
+Робоча директорія являє собою файли і директорії проекту у поточному стані. Ці об’єкти видобуваються з бази даних (яка, пригадаємо, зберігається у директорії Git) і розміщуються на диску для подальшого використання та редагування.
+
+<!-- The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. -->
+
+Область додавання це простий файл, що зазвичай знаходиться у директорії Git і містить інформацію про об’єкти, стан яких буде враховано під час наступної фіксації змін.
+
+<!-- The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area. -->
+
+Найпростіший процес взаємодії з Git виглядає приблизно так:
+
+1. Ви редагуєте файли у своїй робочій директорії.
+2. Надсилаєте файли в область додавання, шляхом створення знімків їх поточного стану.
+3. Робите фіксацію, яка бере файли в області додавання і остаточно зберігає цей знімок у директорії Git.
+
+<!-- The basic Git workflow goes something like this:
+
+1. You modify files in your working directory.
+2. You stage the files, adding snapshots of them to your staging area.
+3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. -->
+
+У випадку, якщо окрема версія файлу вже є у директорії Git, цей файл вважається зафіксованим. Якщо він зазнав змін і перебуває в області додавання, то він доданий. Якщо ж його стан відрізняється від того, який було зафіксовано, і файл не знаходиться в області додавання, то він називається зміненим.
+
+У наступному розділі ви дізнаєтесь більше про ці стани, а також про те, як використовувати їхні переваги або взагалі пропускати етап області додавання.
+
+<!-- If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. -->
+
+## Встановлення Git ##
+
+<!-- ## Installing Git ## -->
+
+Перш за все, для використання Git, ви маєте його встановити. Для цього існує декілька способів; два найбільш вживаних це встановлення з сирців та встановлення існуючого пакунку для вашої платформи.
+
+<!-- Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. -->
+
+### Встановлення з джерельного коду ###
+
+<!-- ### Installing from Source ### -->
+
+Встановлення Git з джерельного коду є дуже корисним, оскільки ви отримуєте найсвіжішу версію. У кожній новій версії системи зберігається тенденція до покращення елементів користувацького інтерфейсу, тож встановлення останньої версії це найкращий шлях, якщо ви володієте навиками компіляції програм з сирців. Крім того, багато дистрибутивів Лінукс містять досить застарілі пакунки, що може слугувати одним з приводів до цього способу встановлення.
+
+<!-- If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet. -->
+
+Для встановлення Git вам знадобляться бібліотеки, від яких залежить система: curl, zlib, openssl, expat та libiconv. Якщо ви користуєтесь системою, в якій є утиліта yum (наприклад, Fedora) чи apt-get (будь-яка система на основі Debian — Ubuntu, Mint тощо), для встановлення цих залежностей в нагоді вам може стати одна з таких команд:
+
+<!-- To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: -->
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev libssl-dev
+
+Після отримання необхідних компонентів, можна рухатись далі і стягнути останній знімок системи Git з офіційного сайту:
+
+<!-- When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: -->
+
+	http://git-scm.com/download
+
+Потім компіляція і встановлення:
+
+<!-- Then, compile and install: -->
+
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+Коли все вишевказане виконано, ви можете завершити процес оновленням Git його власними засобами:
+
+<!-- After this is done, you can also get Git via Git itself for updates: -->
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Встановлення на Linux ###
+
+<!-- ### Installing on Linux ### -->
+
+Якщо бажаєте встановити Git у системі Linux, можете скористатись вбудованим менеджером пакунків. Наприклад, у Fedora це робиться так:
+
+<!-- If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: -->
+
+	$ yum install git-core
+
+Якщо ж ви користувач дистрибутиву базованого на Debian чи його нащадках (як Ubuntu, Mint чи elementary), спробуйте apt-get:
+
+<!-- Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: -->
+
+	$ apt-get install git
+
+Крім того, багато сучасних дистрибутивів мають графічний інтерфейс управління програмним оточенням — це найпростіший шлях встановлення, а всі залежності підтягнуться автоматично.
+
+### Встановлення на Mac ###
+
+<!-- ### Installing on Mac ### -->
+
+Існує два простих шляхи встановлення Git на Mac.
+
+Найпростішим є використання графічного інсталятору, який можна звантажити з його сторінки на сервісі Google Code:
+
+<!-- There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7): -->
+
+	http://code.google.com/p/git-osx-installer
+
+Insert 18333fig0107.png
+Ілюстрація 1-7. Програма встановлення Git в OS X. 
+
+<!-- Figure 1-7. Git OS X installer. -->
+
+Іншим розповсюдженим способом є встановлення за допомогою MacPorts (`http://www.macports.org`). Якщо маєте цей пакет, встановіть Git командою:
+
+<!-- The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via -->
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+Вам не обов’язково мати всі розширення. Але якщо коли-небудь ви будете використовувати Git з репозиторіями Subversion, вам знадобиться +svn (детальніше у Розділі 8).
+
+<!-- You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). -->
+
+### Встановлення на Windows ###
+
+<!-- ### Installing on Windows ### -->
+
+Встановлення Git на комп’ютері під управлінням операційної системи Windows не повинно викликати проблем.
+
+Одну з найпростіших процедур встановлення пропонує проект msysGit. Просто звантажте встановлювач зі сторінки на GitHub і запустіть процес встановлення:
+
+<!-- Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: -->
+
+	http://msysgit.github.com/
+
+Після встановлення, ви отримаєте і командний рядок (що включає також SSH клієнт), і стандартний графічний інтерфейс.
+
+<!-- After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. -->
+
+Примітка: ви можете використовувати Git з командним рядком msysGit, він допускає набори команд, що наводяться в цій книзі. Якщо ж, з якихось причин, вам потрібно використовувати вбудований у Windows командний рядок, то замість простих одинарних лапок потрібно використовувати подвійні (наприклад, для параметрів, що містять пробіли чи закінчуються символом "^", оскільки це символ продовження).
+
+<!-- Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. -->
+
+## Початкове налаштування ##
+
+<!-- ## First-Time Git Setup ## -->
+
+Тепер, маючи у своїй системі Git, варто зробити деякі налаштування його середовища. Це потрібно зробити лише один раз, оновлення не перезаписуватимуть їх. Втім, ви завжди можете внести зміни, повторно виконавши потрібні команди.
+
+<!-- Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. -->
+
+Git містить інструмент під назвою "git config", що дозволяє переглядати та встановлювати налаштування, від яких залежить вигляд та функціонал Git. Ці налаштування можуть зберігатись у трьох різних місцях:
+
+<!-- Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: -->
+
+*   файл `/etc/gitconfig`: містить значення змінних усіх користувачів системи та їхніх репозиторіїв. Для звернення до цього файлу потрібно в команду `git config` передати параметр `--system`.
+
+<!-- *	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. -->
+
+*   файл `~/.gitconfig` містить налаштування лише для вашого користувача. Працювати з цим файлом можна за допомогою опції `--global`.
+
+<!-- *	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -->
+
+*   конфігураційний файл у директорії Git (`.git/config`) стосується лише цього окремого репозиторію. Значення кожного наступного равня мають пріоритет перед попереднім, тож значення з `.git/config` більш важливі, ніж з `/etc/gitconfig`. 
+
+<!-- *	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`. -->
+
+У системі Windows Git шукатиме файл `.gitconfig` у директорії `$HOME` (`%USERPROFILE%` у системному середовищі), що зазвичай вказує на `C:\Documents and Settings\$USER` або `C:\Users\$USER`, в залежності від версії операційної системи. Крім того, шукатиметься також файл /etc/gitconfig, що пов’язаний з кореневою директорією MSys, яка знаходиться там, де ви вирішили встановити Git.
+
+<!-- On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. -->
+
+### Особисті налаштування ###
+
+<!-- ### Your Identity ### -->
+
+Перша річ, про яку варто подбати після встановлення Git, вказати ваше ім’я та адресу електронної пошти. Це важливо, оскільки кожна фіксація змін використовує цю інформацію і записує її у дані про знімки:
+
+<!-- The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: -->
+
+	$ git config --global user.name "Ivan Franko"
+	$ git config --global user.email ivanfranko@example.com
+
+Знову ж таки, за умови використання параметру `--global`, вам знадобиться виконати цю дію лише одного разу. Git постійно використовуватиме вказану інформацію для кожної з ваших дій у цій системі. Змінити введені ім’я чи адресу пошти для окремих проектів можна, знаходячись у директорії проекту, тими ж командами, але вже без використання параметру `--global`.
+
+<!-- Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project. -->
+
+### Редактор ###
+
+<!-- ### Your Editor ### -->
+
+Тепер, коли особисті налаштування у порядку, ви можете вказати який текстовий редактор бажаєте використовувати у випадках, коли знадобиться вводити текстову інформацію. Типово Git використовує редактор, що є стандартним у системі (зазвичай це Vi чи Vim). Для того щоб змінити його на інший (наприклад, Emacs), потрібно виконати таку команду: 
+
+<!-- Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: -->
+
+	$ git config --global core.editor emacs
+
+### Утиліта порівняння ###
+
+<!-- ### Your Diff Tool ### -->
+
+Іншою корисною опцією може бути використання певної утиліти порівняння, що буде використовуватись для розв’язання конфліктів при об’єднанні знімків. Припустімо, це має бути vimdiff:
+
+<!-- Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: -->
+
+	$ git config --global merge.tool vimdiff
+
+Git сприймає kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, та opendiff у якості коректних значень. Також ви можете вказати інший інструмент, про що більш детальніше розповідається у Розділі 7.
+
+<!-- Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. -->
+
+### Перевірка налаштувань ###
+
+<!-- ### Checking Your Settings ### -->
+
+Для перегляду своїх налаштувань використовуйте команду `git config --list`:
+
+<!-- If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: -->
+
+	$ git config --list
+	user.name=Taras Shevchenko
+	user.email=taras@example.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+	
+<!--$ git config --list
+    user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	... -->
+
+Деякі ключі можуть зустрічатись декілька разів. Це може статись через те, що Git шукає значення у різних місцях (наприклад, `/etc/gitconfig` та `~/.gitconfg`). В такому випадку, Git використовує останнє знайдене значення для кожного з ключів.
+
+<!-- You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees. -->
+
+Також, за допомогою конструкції `git config {key}` можна перевірити значення певного ключа:
+
+<!-- You can also check what Git thinks a specific key’s value is by typing `git config {key}`: -->
+
+    $ git config user.name
+	Taras Shevchenko
+	
+<!-- $ git config user.name
+    Scott Chacon -->
+
+## Отримання допомоги ##
+
+<!-- ## Getting Help ## -->
+
+У випадку, якщо вам знадобиться допомога, існує три шляхи доступу до керівництва з використання для будь-якої команди Git:
+
+<!-- If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: -->
+
+	$ git help <verb>
+	$ git <verb> --help
+	$ man git-<verb>
+
+Наприклад, так ви можете переглянути допоміжну інформацію щодо використання команди config:
+
+<!-- For example, you can get the manpage help for the config command by running -->
+
+	$ git help config
+
+Особлива зручність цих команд у том, що вони доступні навіть без підключення до мережі.
+
+Якщо ж офіційного керівництва  і цієї книжки буде недостатньо, і вам знадобиться персональна допомога, спробуйте під’єднатись до каналу `#git` або `#github` на IRC сервері Freenode. Там постійно перебувають сотні людей, що добре розуміються на роботі з Git і готові допомогти. 
+
+<!-- These commands are nice because you can access them anywhere, even offline.
+If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. -->
+
+## Підсумок ##
+
+<!-- ## Summary ## -->
+
+Тепер ви знаєте що таке Git і в чому його відмінність від централізованих систем контролю версій, з якими ви, можливо, вже знайомі. Також ви отримали у своїй системі робочу версію Git з персональними налаштуваннями.
+
+Настав час дізнатись про Git більше.
+
+<!-- You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics. -->