8.4 Customizing Git (سفارشی‌سازی Git) - An Example Git-Enforced Policy (یک مثال از سیاست‌های تحمیلی گیت)

$ git rev-list 538c33..d14fc7
d14fc7c847ab946ec39590d87783c69b031bdfb7
9f585da4401b0a3999e84113824d15245c13f0be
234071a1be950e2a8d078e6141f5cd20c1e61ad3
dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a
17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475

$ git cat-file commit ca82a6
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
author Scott Chacon <schacon@gmail.com> 1205815931 -0700
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700

تغییر شماره نسخه

$ git cat-file commit ca82a6 | sed '1,/^$/d'
تغییر شماره نسخه

$regex = /\[ref: (\d+)\]/

# enforced custom commit message format (تحمیل فرمت پیام کامیت سفارشی)
def check_message_format
  missed_revs = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
  missed_revs.each do |rev|
    message = `git cat-file commit #{rev} | sed '1,/^$/d'`
    if !$regex.match(message)
      puts "[POLICY] Your message is not formatted correctly"
      exit 1
    end
  end
end
check_message_format

avail|nickh,pjhyett,defunkt,tpw
avail|usinclair,cdickens,ebronte|doc
avail|schacon|lib
avail|schacon|tests

def get_acl_access_data(acl_file)
  # read in ACL data
  acl_file = File.read(acl_file).split("\n").reject { |line| line == '' }
  access = {}
  acl_file.each do |line|
    avail, users, path = line.split('|')
    next unless avail == 'avail'
    users.split(',').each do |user|
      access[user] ||= []
      access[user] << path
    end
  end
  access
end

{"defunkt"=>[nil],
 "tpw"=>[nil],
 "nickh"=>[nil],
 "pjhyett"=>[nil],
 "schacon"=>["lib", "tests"],
 "cdickens"=>["doc"],
 "usinclair"=>["doc"],
 "ebronte"=>["doc"]}

$ git log -1 --name-only --pretty=format:'' 9f585d

README
lib/test.rb

# فقط اجازه می‌دهد کاربران خاصی زیرپوشه‌های خاصی را در یک پروژه تغییر دهند
def check_directory_perms
  access = get_acl_access_data('acl')

  # see if anyone is trying to push something they can't
  new_commits = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
  new_commits.each do |rev|
    files_modified = `git log -1 --name-only --pretty=format:'' #{rev}`.split("\n")
    files_modified.each do |path|
      next if path.size == 0
      has_file_access = false
      access[$user].each do |access_path|
        if !access_path  # user has access to everything
           || (path.start_with? access_path) # access to this path
          has_file_access = true
        end
      end
      if !has_file_access
        puts "[POLICY] You do not have access to push to #{path}"
        exit 1
      end
    end
  end
end

check_directory_perms

$ git push -f origin master
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 323 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
Enforcing Policies...
(refs/heads/master) (8338c5) (c5b616)
[POLICY] Your message is not formatted correctly
error: hooks/update exited with error code 1
error: hook declined to update refs/heads/master
To git@gitserver:project.git
 ! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'git@gitserver:project.git'

[source,console]

یادآوری کنید که شما این را در ابتدای اسکریپت `update` خود چاپ کردید.
هر چیزی که اسکریپت شما به `stdout` ارسال کند، به کلاینت منتقل خواهد شد.

چیز بعدی که متوجه خواهید شد، پیام خطاست.

[source,console]

خط اول توسط شما چاپ شده است، دو خط دیگر از طرف Git است که به شما می‌گوید اسکریپت update با کد غیر صفر خارج شده و این باعث رد شدن ارسال شما شده است.
در نهایت، شما این را مشاهده می‌کنید:

[source,console]

برای هر مرجعی که هوک شما آن را رد کرده است، پیامی مبنی بر رد از طرف ریموت خواهید دید و به شما گفته می‌شود که دقیقاً به دلیل شکست هوک این ارسال رد شده است.

علاوه بر این، اگر کسی سعی کند فایلی را که به آن دسترسی ندارد ویرایش کرده و یک کامیت شامل آن ارسال کند، پیامی مشابه مشاهده خواهد کرد.
برای مثال، اگر یک نویسنده مستندات سعی کند یک کامیت ارسال کند که در آن فایلی در دایرکتوری lib تغییر کرده باشد، او این را مشاهده می‌کند:

[source,console]

از این به بعد، تا زمانی که اسکریپت `update` در آن‌جا باشد و قابل اجرا باقی بماند، مخزن شما هرگز کامیتی نخواهد داشت که پیام آن الگوی مورد نظر شما را نداشته باشد، و کاربران شما در محدوده دسترسی مشخص‌شده خود (sandboxed) باقی خواهند ماند.

==== Client-Side Hooks (هوک‌های سمت کلاینت)

یکی از معایب این روش، نارضایتی و غرولندی است که اجتناب‌ناپذیر خواهد بود، زمانی که پوش‌های کاربران به دلیل رد شدن کامیت‌ها پذیرفته نمی‌شوند.
رد شدن کارِ با دقت و زحمت انجام‌شده‌ی آن‌ها در لحظه‌ی آخر می‌تواند بسیار ناامیدکننده و گیج‌کننده باشد؛ و علاوه بر این، آن‌ها مجبور خواهند شد تاریخچه‌ی خود را برای اصلاح تغییر دهند، که این کار همیشه برای همه آسان نیست.

راه‌حل این مشکل، فراهم کردن چند هوک سمت کلاینت (Client-side hooks) است که کاربران بتوانند با اجرای آن‌ها، از احتمال رد شدن تغییرات‌شان توسط سرور مطلع شوند.
به این ترتیب، آن‌ها می‌توانند مشکلات را قبل از کامیت کردن اصلاح کنند و این‌طوری حل آن‌ها ساده‌تر خواهد بود.

از آن‌جا که هوک‌ها به‌طور خودکار همراه با کلون یک پروژه منتقل نمی‌شوند، باید این اسکریپت‌ها را از طریقی دیگر منتشر کرده و از کاربران بخواهید آن‌ها را در مسیر `.git/hooks/` کپی کرده و اجرایی (executable) کنند.
می‌توانید این هوک‌ها را درون خود پروژه یا در پروژه‌ای مجزا منتشر کنید، اما گیت به‌صورت خودکار آن‌ها را تنظیم نمی‌کند.

برای شروع، باید پیام کامیت را درست قبل از ثبت هر کامیت بررسی کنید، تا مطمئن شوید که سرور به‌خاطر فرمت نادرست پیام آن را رد نخواهد کرد.
برای این کار می‌توانید از هوک `commit-msg` استفاده کنید.
اگر این هوک، پیام کامیت را از فایلی که به‌عنوان آرگومان اول دریافت می‌کند بخواند و آن را با الگوی موردنظر مطابقت دهد، می‌توانید با عدم تطابق، گیت را مجبور به توقف فرآیند کامیت کنید:

[source,ruby]

اگر این اسکریپت در مسیر `.git/hooks/commit-msg` قرار گرفته باشد و قابل اجرا (executable) باشد، و شما سعی کنید با پیامی که فرمت درستی ندارد کامیت بزنید، با چنین چیزی مواجه خواهید شد:

[source,console]

در آن حالت هیچ کامیتی انجام نشد.
        با این حال، اگر پیام شما شامل الگوی مناسب باشد، گیت به شما اجازه می‌دهد که کامیت کنید:

[source,console]

در مرحله‌ی بعد، باید مطمئن شوید که فایل‌هایی خارج از محدوده‌ی دسترسی ACL خود را تغییر نمی‌دهید.
اگر دایرکتوری `.git` پروژه‌تان شامل یک نسخه از فایل ACL باشد که قبلاً از آن استفاده کرده‌اید، اسکریپت `pre-commit` زیر این محدودیت‌ها را برایتان اعمال خواهد کرد:


[source,ruby]