Git
Chapters ▾ 2nd Edition

8.1 Git’i Özelleştirmek - Git Yapılandırması

Şimdiye kadar, Git’in nasıl çalıştığını ve nasıl kullanılacağını, ve kullanımınızı kolay ve verimli hale getirmek için Git’in sunduğu birçok aracı tanıttık. Bu bölümde, çeşitli önemli yapılandırma ayarlarını ve kancalar sistemini tanıtarak, Git’i daha özelleştirilmiş bir şekilde çalıştırmanın yollarını göreceğiz. Bu araçlarla, Git’i tam olarak sizin, şirketiniz veya grubunuzun ihtiyaç duyduğu şekilde çalıştırmak çok daha kolay olacaktır.

Git Yapılandırması

Başlangıç bölümünde kısaca okuduğunuz gibi, git config komutu ile Git yapılandırma ayarlarını belirleyebilirsiniz. İlk yapmanız gereken şeylerden biri adınızı ve e-posta adresinizi ayarlamaktı.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Şimdi, Git kullanımınızı özelleştirmek için bu şekilde belirleyebileceğiniz daha ilginç seçeneklerden birkaçını öğreneceksiniz.

İlk olarak, hızlı bir gözden geçirme: Git, istediğiniz varsayılan olmayan davranışı belirlemek için bir dizi yapılandırma dosyası kullanır. Git, bu değerleri aramak için ilk olarak sistem genelinde /etc/gitconfig dosyasına bakar; bu dosya, sistemdeki her kullanıcıya ve onların tüm repolarına uygulanan ayarları içerir. git config komutuna --system seçeneğini eklerseniz, Git özellikle bu dosyadan okur ve buraya yazar.

Git’in bir sonraki baktığı yer, kullanıcıya özgü olan ~/.gitconfig (ya da ~/.config/git/config) dosyasıdır. --global seçeneğini ekleyerek Git’in bu dosyayı okuyup yazdırmasını sağlayabilirsiniz.

Son olarak, Git, şu anda kullandığınız repoya ait olan Git dizinindeki yapılandırma değerlerini arar (.git/config). Bu değerler yalnızca o repoya özgüdür ve git config komutuna --local seçeneğini eklemeyi temsil eder. (Hangi düzeyde çalışmak istediğinizi belirtmezseniz, varsayılan olarak bu ayar kullanılır.)

Bu "düzeylerin" (sistem, global, yerel) her biri, önceki düzeydeki değerleri geçersiz kılar; bu nedenle .git/config dosyasındaki değerler, örneğin, /etc/gitconfig dosyasındakilerin önüne geçer.

Not

Git’in yapılandırma dosyaları düz metindir. Bu nedenle bu değerleri doğru sözdizimini eklemek şartıyla, manuel olarak da belirleyebilirsiniz. Ancak genellikle git config komutunu çalıştırmak daha kolaydır.

Temel İstemci Yapılandırması

Git tarafından tanınan yapılandırma seçenekleri iki kategoriye ayrılır: istemci tarafı ve sunucu tarafı. Seçeneklerin çoğu istemci tarafındadır (kişisel çalışma tercihlerinizi yapılandırır). Çok fazla yapılandırma seçeneği desteklenir, ancak bunların büyük bir kısmı yalnızca belirli uç durumlarda kullanışlıdır (burada sadece en yaygın ve kullanışlı seçenekleri ele alacağız). Git’in kullandığınız sürümünün tanıdığı tüm seçeneklerin bir listesini görmek istiyorsanız, şunu çalıştırabilirsiniz:

$ man git-config

Bu komut, detaylı bir şekilde mevcut tüm seçenekleri listeler. Bu başvuru materyalini ayrıca şu adreste bulabilirsiniz: https://git-scm.com/docs/git-config.

core.editor

Git varsayılan olarak, bir kabuk (shell) ortam değişkeni olan VISUAL veya EDITOR 'da sizin belirttiğiniz varsayılan metin düzenleyicisini kullanır, aksi durumdaysa katkı ve etiket mesajlarını oluşturmak ve düzenlemek için vi düzenleyicisine geri döner. Bu varsayılanı başka bir şeye değiştirmek için, core.editor ayarını kullanabilirsiniz:

$ git config --global core.editor emacs

Artık, varsayılan kabuk düzenleyiciniz ne olursa olsun, Git mesajları düzenlemek için Emacs’i başlatacaktır.

commit.template

Bu değeri sisteminizde bir dosyanın yoluna ayarlarsanız, Git bu dosyayı bir katkı oluştururken varsayılan başlangıç mesajı olarak kullanacaktır. Özel bir katkı şablonu oluşturmanın önemi: bir katkı mesajı oluştururken, (kendinize veya başkalarına) doğru biçim ve stili hatırlatmak için kullanılabilmesidir.

Örneğin, ~/.gitmessage.txt adresinde şöyle bir şablon dosyası düşünün:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]

Bu katkı şablonunun, katkı işleyen kişiyi; ( git log --oneline çıktısı için) başlık satırını kısa tutmaya, altına daha fazla ayrıntı eklemeye ve varsa bir soruna veya iş paketi takip numarasına atıfta bulunmaya yönelttiğini görebilirsiniz.

git commit komutunu çalıştırdığınızda düzenleyicinizde görünen varsayılan mesajı bu şablon olarak kullanılması için, commit.template yapılandırma değerini ayarlayın:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Daha sonra, bir katkı işlerken, düzenleyiciniz şöyle bir şey gösterecek:

Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

Eğer ekibinizin bir katkı mesajı politikası varsa, o politikanın bir şablonunu sisteminize yerleştirmek ve Git’i varsayılan olarak kullanması için yapılandırmak, bu politikanın düzenli olarak uygulanma şansını arttıracaktır.

core.pager

Bu ayar, Git’in log ve diff gibi çıktıları yazdırdığında hangi sayfa düzeninin kullanılacağını belirler. Bunu varsayılan olarak less şeklinde bırakabilir, more olarak ayarlanabilir veya boş bir dize olarak ayarlayarak devre dışı bırakabilirsiniz.

$ git config --global core.pager ''

Bunu çalıştırırsanız, ne kadar uzun olursa olsun, Git tüm komutların çıktısını ekrana yazdırır.

user.signingkey

Eğer (Çalışmanızı İmzalama bölümünde anlatıldığı gibi) imzalı açıklama etiketleri oluşturuyorsanız, GPG imzalama anahtarınızı bir yapılandırma ayarı olarak belirlemeniz işlerinizi kolaylaştırır. Anahtar kimliğinizi şu şekilde ayarlayın:

$ git config --global user.signingkey <gpg-key-id>

Artık git tag komutu ile anahtarınızı belirtmeden etiketleri her seferinde imzalayabilirsiniz.

$ git tag -s <tag-name>

core.excludesfile

(Dosyaları Yoksayma (Ignore) bölümünde anlatıldığı gibi) projenizin .gitignore dosyasına belli dosya yolu desenleri koyarak, Git’in o dosyaları takip edilmeyen dosyalar olarak görmemesini veya git add komutunu çalıştırdığınızda onları izleme almaya çalışmamasını sağlayabilirsiniz.

Ancak bazen, çalıştığınız tüm repolarda belirli dosyaları yok saymak istersiniz. Bilgisayarınızda macOS çalışıyorsa, muhtemelen .DS_Store dosyalarını biliyorsunuzdur. Tercih ettiğiniz metin düzenleyici Emacs veya Vim ise, ~ ile biten veya .swp ile biten dosya adlarını biliyorsunuzdur.

Bu ayar, bir tür global .gitignore dosyası yazmanızı sağlar. Bu içeriklere sahip bir ~/.gitignore_global dosyası oluşturur:

*~
.*.swp
.DS_Store

  1. ve git config --global core.excludesfile ~/.gitignore_global komutunu çalıştırırsanız, Git artık bu dosyalarla ilgili sizi bir daha rahatsız etmeyecek.

help.autocorrect

Eğer bir komutu yanlış yazarsanız, size şuna benzer bir şey gösterir:

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

Did you mean this?
    checkout

Git yardımcı olmak için ne anlatmaya çalıştığınızı anlamaya çalışır, ama sizin yerinize kendisi yapmaz. help.autocorrect 'i 1 olarak ayarlarsanız, Git bu komutu sizin için düzeltip otomatik olarak çalıştıracaktır:

$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...

"0.1 saniye" kısmına dikkat edin. help.autocorrect aslında onda bir saniyeyi temsil eden bir tamsayıdır. Bu nedenle, onu 50 olarak ayarlarsanız; Git size komutu otomatik düzeltmeden önce fikrinizi değiştirebilmeniz için 5 saniye verecektir.

Git’te Renkler

Git, komut çıktısını hızlı ve kolay bir şekilde görsel olarak ayrıştırmaya büyük ölçüde yardımcı olan renkli terminal çıktısını tam destekler. Birkaç seçenek, renklendirmeyi tercihinize göre ayarlamanıza yardımcı olabilir.

color.ui

Git, çoğu çıktıyı otomatik olarak renklendirir, ancak bu davranışı beğenmezseniz bir ana anahtar da vardır. Git’in tüm renkli terminal çıktısını kapatmak için şunu yapın:

$ git config --global color.ui false

Varsayılan ayar auto 'dur. Bu, çıktı doğrudan bir terminale giderken renklendirme yapar, ancak çıktı bir boru (pipe) veya bir dosyaya yönlendirildiğinde renk kontrol kodlarını atlar.

Ayrıca, terminal ve borular arasındaki farkı yok saymak için onu always olarak da ayarlayabilirsiniz. Bunu nadiren isteyeceksiniz; çoğu zaman, yönlendirilmiş çıktınızda renk kodları istiyorsanız, Git buna zorlamak için komuta bir --color bayrağı geçirerek bunu sağlayabilirsiniz. Varsayılan ayar zaten neredeyse her zaman isteyeceğiniz şekildedir.

color.*

Belirli komutların nasıl renklendirileceği hakkında daha özelleştirici olmak isterseniz, Git, fiile özgü renklendirme ayarları da sunar. Her birini true, false veya always olarak ayarlayabilirsiniz:

color.branch
color.diff
color.interactive
color.status

Ayrıca, her birinin (her rengi geçersiz kılacak şekilde) çıktının belirli bölümleri için belirli renkler ayarlamak için kullanabileceğiniz alt ayarları vardır. Örneğin, diff çıktınızdaki meta bilgilerini mavi ön plan, siyah arka plan ve kalın metin olarak ayarlamak için şunu çalıştırabilirsiniz:

$ git config --global color.diff.meta "blue black bold"

Renk seçeneğini aşağıdaki değerlerden biri olarak ayarlayabilirsiniz: normal, black, red, green, yellow, blue, magenta, cyan, veya white. Önceki örnekteki gibi kalın gibi bir öznitelik istiyorsanız, bold, dim, ul (altını çizmek), blink, ve reverse (ön planı ve arka planı değiştirmek) seçeneklerinden birini seçebilirsiniz.

Harici Birleştirme ve Fark Araçları

Git’in bir diff için dahili bir uygulaması olsa da, bunun yerine harici bir araç kurabilirsiniz. Ayrıca, birleşim çakışmalarını manuel olarak çözmek yerine görsel bir çözüm aracı da kurabilirsiniz. Ücretsiz ve güzel görsel araç olduğu için "Perforce Visual Merge Tool (P4Merge)"'i diff ve birleştirme çözümleriniz için nasıl kuracağınızı göstereceğiz.

P4Merge tüm büyük platformlarda çalışır, bu yüzden kullancak olursanız, sorunsuzca çalıştırabiliyor olmalısınız. Örneklerde macOS ve Linux sistemlerinde çalışan dizin isimlerini kullanacağız; Windows için, /usr/local/bin 'i cihazınızdaki yürütülebilir yolla değiştirmeniz gerekecektir.

Başlamak için, Perforce’tan P4Merge’i indirin: https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools Sonraki adımda, komutlarınızı çalıştırmak için harici sargı betiklerini kuracaksınız. Bu örnekte yürütmek için macOS dizinini kullanacağız; diğer sistemlerde, p4merge ikilik dosyanızın kurulu olduğu dizin olacaktır. İkilik dosyanızı çağıran bir birleştirme sargı betiği olan, extMerge adındaki betiği sağlanan tüm argümanlarla kurun:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

Diff sargısı, yedi argümanın sağlandığını kontrol eder ve bunlardan ikisini birleştirme betiğinize aktarır. Git diff programına aşağıdaki argümanları varsayılan olarak iletir:

path old-file old-hex old-mode new-file new-hex new-mode

Sadece old-file ve new-file argümanlarına ihtiyacınız olduğu için, ihtiyacınız olanları iletmek için sargı betiğini kullanırsınız.

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

Bu araçların yürütülebilir olduğundan da emin olmanız gerekir:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

Şimdi yapılandırma dosyanızı özel bir birleştirme çözümü ve diff araçları kullanacak şekilde ayarlayabilirsiniz. Bu bir dizi özel ayarı gerektirir: Git’e hangi stratejiyi kullanacağını söylemek için merge.tool, komutu nasıl çalıştıracağını belirtmek için mergetool.<tool>.cmd, programın çıkış kodunun birleştirme çözümünün başarılı olup olmadığını belirtmek için mergetool.<tool>.trustExitCode, ve diff için çalıştırılacak komutu belirtmek için diff.external. Bu yüzden ya dört yapılandırma komutunu da çalıştırırsınız

$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
  'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff

ya da ~/.gitconfig dosyanızı düzenleyerek bu satırları eklersiniz:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

Tüm bunları ayarlandıktan sonra, şunun gibi diff komutlarını çalıştırırsanız:

$ git diff 32d1776b1^ 32d1776b1

Komut satırında diff çıktısı almak yerine, Git P4Merge’i başlatır, ki bu da aşağı yukarı şöyle görünür:

P4Merge.
Görsel 142. P4Merge.

İki dalı birleştirmeye çalışırsınız ve sonrasında birleştirme çakışmaları oluşursa, git mergetool komutunu çalıştırabilirsiniz; bu size bu GUI (görsel arayüz) aracılığıyla çakışmaları çözme fırsatı sunar.

Bu sargı kurulumunun güzel yanı, diff ve birleştirme araçlarınızı kolayca değiştirebilmenizdir. Örneğin, extDiff ve extMerge araçlarınızı KDiff3 aracını çalıştıracak şekilde değiştirmek için yapmanız gereken tek şey extMerge dosyanızı düzenlemektir:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

Git artık, diff görüntülemek ve çakışmaları çözmek için KDiff3 aracını kullanacaktır.

Git, cmd yapılandırmasını ayarlamadan önce bir dizi başka birleştirme çözüm aracını kullanmak üzere önceden ayarlanmıştır. Desteklediği araçların bir listesini görmek için şunu deneyin:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

The following tools are valid, but not currently available:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.

Eğer KDiff3 aracını, diff için değil de sadece birleştirme çözümü için kullanmak istiyorsanız; ama kdiff3 yürütülebilir dizininizde ise, o zaman şunu çalıştırabilirsiniz:

$ git config --global merge.tool kdiff3

Eğer extMerge ve extDiff dosyalarını kurmak yerine bunu çalıştırırsanız, Git birleştirme çözümü için KDiff3’ü ve diff için normal Git diff aracını kullanacaktır.

Biçimlendirme ve Boşluklar

Biçimlendirme ve boşluk sorunları, özellikle platformlar arası işbirliğinde birçok geliştiricinin karşılaştığı en sinir bozucu ve gözden kaçması kolay sorunlardan bazılarıdır. Editörler tarafından sessizce geliştirilen yamalar veya diğer işbirliği çalışmaları yüzünden sisteminize boşluk değişiklikleri aktarılması çok kolaydır. Özellikle dosyalarınız Windows sistemine bir şekilde dokunmuşsa, satır sonları değiştirilmiş olabilir. Git’in bu sorunlarla ilgili yardımcı olmak için, birkaç yapılandırma seçeneği vardır.

core.autocrlf

Windows üzerinde program geliştiriyor ama Windows kullanmayan insanlarla çalışıyorsanız (veya tam tersi), muhtemelen bir noktada satır sonu sorunlarıyla karşılaşacaksınız. Bunun nedeni, Windows’un dosyalarda yeni satırlar için hem bir taşıma-baş (CR: carriage-return) karakteri hem de bir satır besleme (LF: linefeed) karakteri kullanılırken, macOS ve Linux sistemlerinin ise yalnızca satır besleme karakterini kullanmasıdır. Bu, platformlar arası çalışmanın incelikli ama son derece sinir bozucu bir gerçeğidir. Windows’ta birçok editör mevcut LF tarzı satır sonu karakterlerini sessizce CRLF ile değiştirir veya kullanıcı enter tuşuna bastığında her iki satır sonu karakterini de ekler.

Git, bir dosyayı dizine eklerken CRLF satır sonlarını otomatik olarak LF’ye dönüştürerek ve kodu dosya sisteminize çıkardığınızda tersini yaparak bunu yönetebilir. Bu işlevselliği core.autocrlf ayarı ile etkinleştirebilirsiniz. Eğer Windows kullanıyorsanız, bunu true olarak ayarlayın: bunu yapmak, kodu çıkarırken LF sonlarını CRLF’ye dönüştürür:

$ git config --global core.autocrlf true

Eğer LF satır sonları kullanan bir Linux veya macOS sistemindesiniz, o zaman dosyaları çıkarırken Git’in bunları otomatik olarak dönüştürmesini istemezsiniz; ancak, yanlışlıkla CRLF sonlarına sahip bir dosya tanıtılırsa, o zaman Git’in bunu düzeltmesini isteyebilirsiniz. core.autocrlf ayarını input olarak ayarlayarak Git’e CRLF’yi LF’ye dönüştürmesini ancak tersini yapmamasını söyleyebilirsiniz:

$ git config --global core.autocrlf input

Bu yapılandırma size, Windows çıkarımlarında CRLF sonları bırakırken, macOS ve Linux sistemlerinde ve repoda LF sonları sağlamalıdır.

Eğer Windows programcısıysanız ve yalnızca Windows’a özgü bir proje yapıyorsanız; bu yapılandırma değerini false olarak ayarlayarak, bu işlevselliği kapatabilir ve taşıma karakterlerini repoya kaydedebilirsiniz:

$ git config --global core.autocrlf false

core.whitespace

Git, bazı boşluk sorunlarını algılamak ve düzeltmek için önceden ayarlanmıştır. Altı temel boşluk sorununu arayabilir: Bunların üçü varsayılan olarak etkinleştirilmiştir ve kapatılabilir, üçü ise varsayılan olarak devre dışı bırakılmıştır ancak etkinleştirilebilir.

Varsayılan olarak açılan üç özellik: satırın sonundaki boşlukları arayan blank-at-eol, dosyanın sonundaki boş satırları fark eden blank-at-eof, ve bir satırın başında sekme öncesinde boşluk arayan space-before-tab 'dir.

Varsayılan olarak devre dışı bırakılan ancak etkinleştirilebilecek üç özellik ise: bir satırın başında boşluklar yerine sekme ile başlayan satırları arayan indent-with-non-tab (ve tabwidth seçeneği tarafından kontrol edilir), bir satırın girinti kısmındaki sekmeleri izleyen tab-in-indent, ve satırların sonunda taşıma karakterlerinin kabul edilebilir olduğunu belirten cr-at-eol 'dür.

Git’e bunlardan hangisinin etkinleştirilmesini istediğinizi, core.whitespace 'i açık veya kapalı olmasını istediğiniz değerlere virgülle ayırarak ayarlayarak, söyleyebilirsiniz. Bir seçeneği devre dışı bırakmak için adının önüne - ekleyebilirsiniz, veya tamamen ayar dizgisinden çıkararak varsayılan değeri kullanabilirsiniz. Örneğin, space-before-tab dışındaki tüm özelliklerin ayarlanmasını istiyorsanız, şunu yapabilirsiniz (hem blank-at-eol hem de blank-at-eof 'yi kapsayan trailing-space kısaltmasıyla):

$ git config --global core.whitespace \
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Veya yalnızca özelleştirme kısmını belirtebilirsiniz:

$ git config --global core.whitespace \
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

git diff komutunu çalıştırdığınızda, Git bu sorunları algılayacak ve bunları katkılamadan önce düzeltebilmeniz için de renklendirecektir. Ayrıca, git apply ile yamaları uygularken size yardımcı olmak için bu değerleri kullanacaktır. Yamaları uygularken, Git’ten belirtilen boşluk sorunlarıyla ilgili sizi uyarmanızı isteyebilirsiniz:

$ git apply --whitespace=warn <patch>

Ya da Git’ten yamanın uygulanmasından önce sorunu otomatik olarak düzeltmeye çalışmasını isteyebilirsiniz:

$ git apply --whitespace=fix <patch>

Bu seçenekler git rebase komutuna da uygulanır. Eğer kodunuzu boşluk sorunlarını çözmeden katkılamış, ancak henüz üstakıma itmemişseniz; Git’in yamaları yeniden yazarken boşluk sorunlarını otomatik olarak düzeltmesi için git rebase --whitespace=fix komutunu çalıştırabilirsiniz.

Sunucu Yapılandırması

Git’in sunucu tarafında bu kadar çok yapılandırma seçeneği mevcut değildir, ancak not almak isteyebileceğiniz birkaç ilginç seçenek vardır.

receive.fsckObjects

Git, bir itme işlemi sırasında alınan her nesnenin hala SHA-1 toplamına uymasını ve geçerli nesnelere işaret etmesini sağlayabilir. Ancak, bunu varsayılan olarak yapmaz. Bu oldukça maliyetli bir işlemdir ve özellikle büyük drpolar veya itme işlemlerinde süreci yavaşlatabilir. Her itme işleminde Git’in nesne tutarlılığını kontrol etmesini istiyorsanız, receive.fsckObjects ayarını true olarak ayarlayarak Git’i buna zorlayabilirsiniz:

$ git config --system receive.fsckObjects true

Artık, Git bir itme talebini kabul etmeden önce, reponun bütünlüğünü kontrol edecek ve hatalı (veya kötü niyetli) istemcilerin bozuk veri eklemesini engellemek için çaba gösterecektir.

receive.denyNonFastForwards

Zaten ittiğiniz katkıları yeniden temeller (rebase) ve sonra tekrar itmeye çalışırsanız veya uzak dalın şu anda işaret ettiği katkıyı içermeyen dalına bir katkı göndermeye çalışırsanız reddedilirsiniz. Bu genellikle iyi bir politikadır; ancak yeniden temelleme durumunda, ne yaptığınızı bildiğinizden eminseniz ve uzak şubeyi Push komutunuza bir -f bayrağıyla güncellemeye zorlayabilirsiniz.

, uzak bir dala bir katkı itmek için, uzak dalın şu anda işaretlediği katkıyı içermeyen bir katkı iterseniz, reddedileceksiniz. Bu genellikle iyi bir politikadır; ancak yeniden temelleme durumunda, ne yaptığınızı bildiğinizden eminseniz, itme komutunuza -f bayrağı ekleyerek uzak dalı zorla güncelleyebilirsiniz.

Git’e zorla itme işlemlerini reddetmesini söylemek için receive.denyNonFastForwards ayarını belirleyin:

$ git config --system receive.denyNonFastForwards true

Bunu yapmanın diğer yolu, birazdan ele alacağımız sunucu tarafı kabul kancaları aracılığıyladır. Bu yaklaşım, belirli bir kullanıcı alt kümesine zorlamasız itmelere izin vermek gibi daha karmaşık işler yapmanıza olanak tanır.

receive.denyDeletes

denyNonFastForwards politikasına yönelik çalışmaların biri, kullanıcının dalı silip ardından yeni referansla tekrar yüklemesidir. Bunu önlemek için, receive.denyDeletes ayarını true olarak ayarlayın:

$ git config --system receive.denyDeletes true

Bu ayar, dalların veya etiketlerin herhangi birinin silinmesini reddeder (hiçbir kullanıcı bunu yapamaz). Uzak dalları kaldırmak için, ref dosyalarını sunucudan manuel olarak kaldırmanız gerekir. Ayrıca, Bir Örnek: Mecburi Git Politikası bölümünde öğreneceğiniz gibi, ACL’ler aracılığıyla kullanıcı bazında bunu yapmanın daha ilginç yolları da vardır.

scroll-to-top