Dil seçin

Git ile Sürüm Kontrolü Altında Sözleşme Şablonları - Hukuk Takımları için

SaaS, startup ve uzaktan çalışma dünyasının hızla değişen temposunda sözleşme şablonları, günlük iş operasyonlarının temelini oluşturur. Gizlilik Sözleşmeleri (NDA) ve Veri İşleme Anlaşmaları (DPA) gibi şablonlar, düzenleyici güncellemeler, şirket politikası değişiklikleri veya ürün değişiklikleri nedeniyle periyodik revizyonlar geçirir. Ancak birçok kuruluş hâlâ bu belgeleri dağınık klasörlerde, paylaşılan sürücülerde veya izole belge yönetim sistemlerinde saklar.

Sonuç?

  • Sürüm belirsizliği – Ekipler istemeden eski maddeleri kullanır.
  • Uyumluluk riski – Eksik veya hatalı hukuki dil, şirketi para cezalarına maruz bırakabilir.
  • İş birliği sıkıntısı – Hukuk inceleyicileri, ürün yöneticileri ve satış temsilcileri “doğru” sürümü bulmak için zaman kaybeder.

İşte Git devreye girer; dünyanın en büyük yazılım projelerini yöneten dağıtık sürüm kontrol sistemidir. Geleneksel olarak geliştiricilerle ilişkilendirilse de, Git’in dallanma, tarih takibi, birleştirme çakışması çözümü ve erişim kontrolü özellikleri, doğru iş akışı ve UI katmanı ile birleştirildiğinde hukuki belge yönetimine mükemmel uyum sağlar.

Bu rehberde şunları ele alacağız:

  1. Git’in sözleşme şablonları için neden bir oyun değiştirici olduğunu.
  2. Güvenli, rol tabanlı bir Git deposu kurmak.
  3. Mantıklı bir klasör yapısıyla şablonları düzenlemek.
  4. Markdown ve PDF boru hatlarıyla insan‑okunabilir sözleşmeler üretmek.
  5. Depoyu AI‑destekli taslak araçları ve e‑imza platformlarıyla bütünleştirmek.
  6. Otomatik kontroller ve denetim izleriyle uyumluluğu zorlamak.

Bu adımları tamamladığınızda, ölçeklenebilir, denetlenebilir ve iş birliğine açık bir sözleşme şablonu kütüphaneniz olacak.


1. Git’in Hukuki Avantajı

Git ÖzelliğiHukuki Fayda
Branching (Dallanma)“AB‑uyumlu” vs “US‑uyumlu” gibi birden fazla “ne‑olur‑eğer” sürümünü ana kopyayı bozmadan taslaklayabilirsiniz.
Commit history (Değişiklik geçmişi)Her değişiklik zaman damgası ve sorumlu kişi ile kaydedilir; bu, birçok düzenleyici çerçeve için gerekli olan değiştirilemez bir denetim izini oluşturur.
Pull requests (PR’ler)Avukatlar, uyumluluk görevlileri ve ürün yöneticileri yorum yapabilir, onaylayabilir veya değişiklikleri reddedebilir; yapılandırılmış bir inceleme süreci sağlanır.
Access control (Erişim kontrolü)Depo ya da klasör düzeyinde ince ayarlı izinler (okuma, yazma, admin) uygulanır; sadece yetkili personel hassas maddeleri düzenleyebilir.
Merge conflict resolution (Birleştirme çakışması çözümü)Aynı anda yapılan düzenlemeler güvenli bir şekilde birleştirilir, istem dışı madde kaybı önlenir.

Bu yetenekler, “verimli‑bir‑merkezi‑sözleşme‑şablonu‑kütüphanesi‑inşa‑etmek” ve “uzak‑takımlar‑için‑sözleşme‑şablonlarını‑yönetmek” gibi blog serilerinde ortaya konan ağrı noktalarını çözer, ancak aynı zamanda yazılım mühendisliğiyle geliştirilmiş sürüm kontrolünün titizliğini getirir.


2. Güvenli Bir Git Deposu Kurmak

2.1 Barındırma Sağlayıcısı Seçimi

Şu özelliklere sahip bir hizmet tercih edin:

  • Kurumsal seviyede güvenlik – dinlenirken şifreleme, SSO entegrasyonu (SAML/OIDC).
  • İnce ayarlı depo izinleri – dal koruma, zorunlu PR incelemeleri.
  • Denetim günlükleri – GDPR, CCPA gibi düzenlemeler için değiştirilemez loglar.

Popüler seçenekler: GitHub Enterprise, GitLab Self‑Managed, Bitbucket Data Center. Örnek olarak GitHub Enterprise kullanılacaktır.

2.2 Depoyu Oluşturma

# Yetkili bir yönetici makinesinden
gh auth login --hostname github.mycompany.com
gh repo create contract-templates --private --description "Merkezi, sürüm kontrolü altındaki sözleşme şablonları"

2.3 Takımlar ve İzinler Tanımlama

TakımKapsamİzinler
Legal‑Authorscontracts/ (tümü)Write
Legal‑Reviewerscontracts/ (tümü)Read & Approve PRs
Productcontracts/product/*Read
Salescontracts/sales/*Read
Compliancecontracts/*Admin (dal politikalarını zorlamak için)

Kuruluş ayarlarından takımları oluşturup, depoya uygun rolleri atayın.


3. Şablonların Bulunabilirliğini Artırmak İçin Düzenleme

Açık bir hiyerarşi arama süresini kısaltır ve izin yönetimini basitleştirir. Önerilen dizin yapısı:

contracts/
│
├─ nda/
│   ├─ template.md
│   └─ clauses/
│       ├─ confidentiality.md
│       └─ term.md
│
├─ tos/
│   ├─ us/
│   │   └─ template.md
│   └─ eu/
│       └─ template.md
│
├─ dpa/
│   ├─ gdpr/
│   │   └─ template.md
│   └─ ccpa/
│       └─ template.md
│
├─ partnership/
│   └─ template.md
│
└─ README.md

Her alt klasör bir Markdown kaynak dosyası (template.md) içerir. Hukuk ekipleri bu dosyaları doğrudan düzenler; ardından oluşturulan dosyalar PDF veya Word formatına dönüştürülür.

İpucu: Her klasöre, yargı bölgesi, yürürlük tarihi ve sürüm etiketi gibi meta verileri tutan bir metadata.yaml ekleyin. Bu, daha sonra AI‑destekli aramalarda çok faydalı olur.


4. Markdown’tan Üretim‑Hazır Sözleşmelere

Avukatlar genellikle Word tercih etse de, Markdown hafif, diff‑dostu ve sürüm kontrolüne uygundur. GitHub Actions ya da GitLab CI gibi bir boru hattı, main dalına birleştirildiğinde PDF/DOCX üretir.

4.1 Örnek GitHub Action

name: Build Contracts

on:
  push:
    branches: [ main ]

jobs:
  render:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install pandoc
        run: sudo apt-get install -y pandoc

      - name: Render PDFs
        run: |
          for f in $(find contracts -name '*.md'); do
            pandoc "$f" -o "${f%.md}.pdf"
          done          

      - name: Upload artifacts
        uses: actions/upload-artifact@v3
        with:
          name: compiled-contracts
          path: contracts/**/*.pdf

Bu işlem, PDF’leri bir artefakt deposuna koyar ya da doğrudan e‑imza hizmetine (örn. DocuSign) API üzerinden gönderir.

4.2 Madde Kütüphanelerini Sürdürmek

Birçok sözleşme aynı maddeleri (gizlilik, tazminat vb.) tekrar tekrar kullanır. Yeniden kullanılabilir parçaları contracts/clauses/ içinde tutun ve Markdownblockquote ya da Pandoc include yönergesiyle ekleyin:

> {% include '../clauses/confidentiality.md' %}

Bir madde güncellendiğinde, onu referans alan tüm ana sözleşmeler bir sonraki pipeline çalıştırmasında otomatik olarak yeni sürümü alır; manuel kopyala‑yapıştır hataları ortadan kalkar.


5. AI‑Destekli Taslak ve İnceleme

Üretken dil modelleri (örn. OpenAI‑GPT‑4) taslak sürecini hızlandırabilir:

  1. Prompt Oluşturma – Model, metadata.yaml dosyasından sözleşme tipi, yargı bölgesi ve ihtiyaç duyulan maddeleri alır.
  2. İlk Taslak – AI, yeni bir template.md oluşturarak özellik dalına (feature branch) yerleştirir.
  3. İnsan İncelemesi – Hukuk inceleyicileri PR üzerinden onay verir; AI’nın önerileri şirket standartlarına uygun hale getirilir.

Aşağıdaki basit otomasyon betiği (ai-draft.py) bir GitHub Issue yorumundan bir taslak PR oluşturur:

#!/usr/bin/env python3
import os, json, openai, yaml, subprocess

def load_meta(path):
    with open(path) as f:
        return yaml.safe_load(f)

def generate_prompt(meta):
    return f"""Create a {meta['type']} for {meta['jurisdiction']} 
    that includes clauses: {', '.join(meta['required_clauses'])}."""

def main():
    issue_body = os.getenv('ISSUE_BODY')
    meta = yaml.safe_load(issue_body)
    prompt = generate_prompt(meta)
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role":"user","content":prompt}]
    )
    md = response.choices[0].message.content
    file_path = f"contracts/{meta['type']}/{meta['jurisdiction']}/template.md"
    os.makedirs(os.path.dirname(file_path), exist_ok=True)
    with open(file_path, "w") as f:
        f.write(md)
    subprocess.run(["git", "add", file_path])
    subprocess.run(["git", "commit", "-m", f"AI draft {meta['type']} {meta['jurisdiction']}"])
    subprocess.run(["git", "push"])

Bu betik, yapılandırılmış bir issue’u alır, AI‑destekli bir taslak üretir ve bir PR’a dönüşür; insan denetimi hâlâ kritik bir adımdır – önceki “yazılım lisans sözleşmesini nasıl korursunuz” gönderisinde de vurgulandığı gibi.


6. Otomatik Kontrollerle Uyumluluğu Zorlamak

İnsan gözünden geçen incelemeler yanında, otomatik lint’ler sözleşmelerin temel gereksinimleri karşıladığından emin olur.

6.1 Sözleşme Linter (özel)

REQUIRED_SECTIONS = ["Scope", "Term", "Confidentiality", "Governing Law"]

def lint(file_path):
    with open(file_path) as f:
        content = f.read()
    missing = [s for s in REQUIRED_SECTIONS if f"## {s}" not in content]
    return missing

Bu linter CI boru hattına eklenir; zorunlu bölümler eksikse PR başarısız olur – “service‑level‑agreement‑key‑component‑and‑use‑case” makalesinde önerilen bir yaklaşım.

6.2 Hukuki Madde Doğrulama

OPA (Open Policy Agent) gibi bir kural motoru, aşağıdaki koşulları denetler:

  • Avrupa‑odaklı DPA şablonlarında GDPR maddeleri bulunmalı.
  • Kaliforniya‑odaklı sözleşmelerde CCPA dili yer almalı.

OPA politikaları policies/ klasöründe saklanır ve CI sırasında değerlendirilir.


7. Denetim İzleri ve Raporlama

Git, uyumluluk denetimleri için doğal bir denetim izi sunar:

  • Commit SHA – Değiştirilemez bir kimlik.
  • Yazar / Committer – Şirket SSO’su ile eşleşen kullanıcı kimliği.
  • Zaman damgası – ISO‑8601 formatında tarih‑saat.

Çeyrek bazlı rapor için basit bir komut:

git log --since="90 days ago" --pretty=format:"%h %ad %an %s" > audit-report.txt

Metaveri (etkin tarih) ile birleştirildiğinde, belirli bir dönem içinde hangi sürümün aktif olduğu gösterilebilir – “veri‑işleme‑anlaşması‑nedir” makalesinde vurgulanan bir gereklilik.


8. Uluslararası Ölçeklendirme

Küresel genişleme gerektiğinde, birden çok yargı‑özel dalı (örn. eu, apac) gerekir. Git sub‑modules ya da monorepo desenleri tercih edilebilir:

  • Sub‑module – Her bölge kendi reposunu tutar; ana contracts/ deposu bir referans olarak eklenir.
  • Monorepo + yol filtreleri – Dal koruma kuralları, kimin contracts/eu/* ya da contracts/apac/* klasörlerine push yapabileceğini sınırlar.

Her iki yöntem de tek bir gerçek kaynağı korurken yerel hukuk ekiplerine özerklik tanır.


9. Örnek Çalışma Akışı

  1. Fikir – Ürün yöneticisi “APAC ortakları için NDA oluştur” başlıklı bir GitHub Issue açar.
  2. AI Taslak – Issue, ai-draft.py betiğini tetikler; bir taslak dalı ve template.md dosyası oluşturulur.
  3. PR Açma – Dal, otomatik olarak Legal‑Reviewers grubuna atanan bir PR oluşturur.
  4. Lint & Policy – CI, sözleşme linter ve OPA politikalarını çalıştırır; eksik bölümler varsa PR reddedilir.
  5. İnsan İncelemesi – İnceleyiciler yorum yapar, düzeltmeler ister ve onay verir.
  6. Birleştirme – Gereken onaylar alındıktan sonra main dalına merge yapılır.
  7. Derleme – GitHub Action, PDF’leri üretir, sözleşme yönetim sistemine yükler ve satış ekibine bildirim gönderir.
  8. İmza – DocuSign API, PDF’yi alır, elektronik imzayı başlatır ve imzalanan belgenin hash’ini depoya geri yazar.

Bu döngü, her sözleşmenin güncel, izlenebilir ve uyumlu olmasını sağlar.


10. Sık Sorulan Sorular

SoruCevap
Teknik olmayan kullanıcılar Git komutları öğrenmek zorunda mı?Hayır. Çoğu etkileşim web arayüzü (GitHub/GitLab) üzerinden Create new file ya da Edit butonlarıyla yapılır. Toplu işlemler için GitHub Desktop gibi masaüstü istemciler komut satırını soyutlar.
Büyük ikili ekler (örn. imzalanmış PDF’ler) nasıl tutulur?Büyük dosyalar Git LFS ya da ayrı bir belge yönetim sisteminde saklanır; repo içinde bir meta dosyasıyla linklenir.
Bu yaklaşım GDPR’ye uygun mu?Evet. Çünkü her değişiklik kaydedilir, erişim rol tabanlıdır ve depo, AB‑uyumlu bir veri merkezinde barındırılabilir.
Mevcut CLM platformlarıyla entegrasyon mümkün mü?Çoğu CLM, REST API sunar. CI boru hattından üretilen PDF’ler doğrudan belge yönetim sistemi içine itilebilir.
Harici taraflar için sürüm numaralandırması nasıl yapılır?Depoya semantik versiyon etiketi (örn. v2.3.0) uygulanır; bu etiket, oluşturulan PDF’nin üstbilgisinde gösterilir; böylece dış paydaşlar tam olarak hangi şablon sürümünü imzaladıklarını bilir.

Sonuç

Sözleşme şablonlarını kaynak kod gibi yönetmek, değiştirilemez denetim izleri, iş birliği odaklı inceleme, otomatik uyumluluk kontrolleri ve AI taslak araçları ile e‑imza platformları entegrasyonu gibi bir dizi fayda sağlar. Git‑tabanlı, merkezi yönetilen bir depo kurarak, hukuk ekipleri yazılım mühendisliği ekiplerinin yıllardır yararlandığı aynı titizliği sözleşmelerine uygulayabilir.

Kütüphanenizi geleceğe hazırlamaya hazırsanız, öncelikle yüksek hacimli bir şablon (ör. NDA) ile başlayın, iş akışını deneyimleyin ve adım adım tüm şablonları bu yaklaşıma taşıyın. Kütüphane büyüdükçe aynı desenler, yargı bölgesi, iş birimi ve hatta tüm kuruluşlar arasında sorunsuz bir şekilde ölçeklenir.

Kodunuza gösterdiğiniz özeni sözleşmelerinize de gösterin.


Ayrıca Bakın

yukarı
© Scoutize Pty Ltd 2025. All Rights Reserved.