10 Dakika 7 Saniyede Kendi Github Sunucumuzu Kurmak

"21 Günde Python Öğrenin" veya "24 Saatte Java" gibi kitapları görmüşsünüzdür ve sonuç, hiç de kitabın adında yazdığı gibi olmaz. Bu başlıkta yazan da aslında doğru değil ama bir farkla: zaman kısmı doğru, GitHub kısmı yalan... Aslında GitHub değil, web arayüzü GitHub'a çok benzeyen, kendi Git sunucumuzu kuruyoruz.

Saat tutup denedim ve gerçekten de 10 dakika 7 saniye sürdü. Ve daha da güzeli, bütün yapacağımız, sadece 2 komut yazıp basit bir web formunu doldurmak...

Bu bilişime fazla kafa yorarsan, sıyırırsın
Aslında yapılacak işlem hiç de basit değil. Birazdan yazacağım birkaç basit komutu çalıştırdığınızda, arkaplanda şunlar gerçekleşecek:
  • host makinede, dışarıya kapalı sanal bir network oluşturulacak
  • bir Linux container (LXC) oluşturulacak ve ayarlanacak
  • veritabanı sunucusu kurulacak
  • Reverse proxy olarak çalışacak bir Nginx sunucu kurulacak ve ayarlanacak
  • Git sunucu kurulacak
  • iptables ile NAT ayarları yapılacak
  • Self signed SSL sertifikası oluşturulacak
  • vs vs vs
Şimdi bütün bu adımları detaylı detaylı yazarsam ne olur? Değerli bir büyüğümüzün dediği gibi kafayı sıyırılsınız. Büyüğümüz ne demiş bakalım: "Bu bilişime fazla kafa  yorarsan sıyırırsın, nimetlerinden kullanıp yararlanıp işini göreceksin. Kafayı taktın mı o zaman işin kötü."                        
                                                  
"Yok, ben illa kafayı sıyırmak istiyorum. Olayın detaylarını da öğrenmek istiyorum" dersen, kaynak kodlar açık. Dilediğin gibi inceleyebilirsin. Takıldığın yer olursa bana email at.              
                                                  
Bulut sistemi dedikleri bir şey var, herkes oraya bir şey atıyor              
Yalnız bu işi yapabilmek için tek bir şey gerekiyor: Debian Jessie kurulu bir makine...                                         
                                                  
"Ya şimdi kim uğraşacak Debian kurmakla" dersen, cevap yine sayın büyüğümüzden geliyor: "Bulut sistemi dedikleri bir şey var, herkes oraya bir şey atıyor gelen oradan işine yarayanı alıyor kullanıyor ben böyle anlıyorum. Sistematik bir şey yok. Abur cubur dolduruyorsun, herkes ihtiyacını oradan alıyor ama hiç de karışmıyor. İstediğini buluyorsun"             
                                                  
Siz de öyle yapın. Ben öyle yaptım. Gittim Digital Ocean'a, açtım Debian Jessie bir makina... Beyin bedava...

"Yok ben yine arıza çıkaracağım. Bulutsuz olmaz mı" dersen, sanal makineye, Debian Jessie kurup deneyebilirsin. Yalnız (swap dahil) minimum 1 GB RAM ayırmanız gerekiyor ve (i386 değil) AMD64 mimarisini kullanın.

Bildiğiniz gibi bilgisayarlar Binali sistemiyle çalışır
Şimdi sıra geldi mucizevi komutlarımıza... Debian Jessie makineye root olarak bağlandıktan sonra şu 2 komutu veriyoruz:

wget https://raw.githubusercontent.com/emrahcom/emrah-jessie/master/installer/ej
bash ej ej-gogs

Birinci komut, kurulumu yapacak olan Bash scriptini indiriyor. İkinci komut ise kurulumu yapıyor. Script işini bitirdikten sonra web tarayıcımızı açıp IP adresini kullanarak sunucuya bağlanıyoruz. Açılan formda sadece 2 yeri değiştirmeniz gerekiyor: Domain ve Application URL

Eğer bu sunucu için bir alan adı kullanmayacaksanız, "your.domain.name" yazan yerlere, sunucunun IP adresini yazabilirsiniz. Bu kadar...

Başka numaraların var mı
Evet, var. Aynı yöntemle kendi Gmail sunucunuzu, canlı video yayını yapabileceğiniz stream sunucunuzu, web panelden yönetebileceğiniz PowerDNS sunucunuzu veya web sitenizin önüne koyabileceğiniz WAF (web application firewall) sunucunuzu da kurabiliyorsunuz. Her biri yaklaşık 10 dakikada ve 2 komutla oluyor. Detaylar, benim GitHub hesabında var ama siz yine de detaya girmeyin, kafayı sıyırmayın.

selamlar

21 Ocak 2017

Posted In: Debian, git, github, linux, lkd

Go Git Services (Gogs) Kurulumu

Herkese merhaba,
Bu yazımda Gogs'un ne olduğundan ve nasıl yapılandırılıp kullanılabileceğinden bahsedeceğim.


Gogs'u Halil'in Github'da yıldızlaması ile gördüm. Ne iş yapıyormuş diye bakınca "vay be gavur da güzel proje yapmış" dedim ve projenin Go ile yazıldığını görünce aşırı sevindim. "Bu projeyi bir kurup deneyeyim, katkı versem çokii olur" diye düşündüm. Çünkü yaklaşık bir aydır boş kaldıkça Go'yu öğrenmeye vakit ayırıyorum ve bu da baya güzel denk geldi :)


Gogs özetle kendi git servisinizi kurmanızı, kullanmanızı, yönetmenizi sağlıyor. Belgelendirmesi de oldukça güzel yapılmış. Ben kaynak koddan hangi adımları uygulayarak kurduğumu anlatacağım.


İlk olarak servis vereceğimiz sunucunuza Go kurmalıyız. Ssh'a açık olacağı için bir kullanıcıyı yetkilendirmek gerekiyor. Bu yüzden yeni bir kullanıcı oluşturmalıyız.

#Kullanıcı oluşturup home dizinine geçelim.
$ sudo adduser --disabled-login --gecos 'Gogs' git
$ sudo su - git
$ cd ~

#Go'yu local diye bir dizin oluşturup yükleyelim.
$ mkdir local
$ wget https://storage.googleapis.com/golang/go$VERSION.$OS-$ARCH.tar.gz

# tar.gz uzantısını açalım.
$ tar -C /home/git/local -xzf go$VERSION.$OS-$ARCH.tar.gz

# Çevresel değişkenleri de ~/.bashrc altına ekleyelim.
$ sudo su - git
$ cd ~
$ echo 'export GOROOT=$HOME/local/go' >> $HOME/.bashrc
$ echo 'export GOPATH=$HOME/go' >> $HOME/.bashrc
$ echo 'export PATH=$PATH:$GOROOT/bin' >> $HOME/.bashrc
$ source $HOME/.bashrc

# Gogs'un kaynak kodunu kendi yerelimize çekelim ve derleyelim.
$ go get -u github.com/gogits/gogs (bağımlılıklar için)
$ cd $GOPATH/src/github.com/gogits/gogs
$ go build

# Şimdi "$ ./gogs web" dediğimizde çıktı aşağıdaki gibi olmalı: (varsayılan port 3000)

Bu çıktıda da dediği gibi ilk kez çalıştırdığımız için [w] uyarısını görmezden gelebiliriz.

Çıktıda bu uyarı dışında sorun yoksa şimdi app.ini dosyasını oluşturmalıyız. Bu kendi git servisimizin yapılandırmasını içeren dosya. (/custom/conf/app.ini

Benim yapılandırma dosyam şu şekilde:

APP_NAME = Gogs: Go Git Service
RUN_USER = git
RUN_MODE = prod

[database]
DB_TYPE  = mysql
HOST     = 127.0.0.1:3306
NAME     = gogs
USER     =root
PASSWD   =*********
SSL_MODE = disable
PATH     = data/gogs.db

[repository]
ROOT = /home/git/gogs-repositories

[server]
DOMAIN       =foo.bar.baz
HTTP_PORT    = 3000
ROOT_URL     = http://foo.bar.baz/
DISABLE_SSH  = false
SSH_PORT     = 22
OFFLINE_MODE = false

[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL     = false
DISABLE_REGISTRATION   = false
ENABLE_CAPTCHA         = true
REQUIRE_SIGNIN_VIEW    = false

[picture]
DISABLE_GRAVATAR = false

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /home/git/go/src/github.com/gogits/gogs/log

[security]
INSTALL_LOCK = true
SECRET_KEY   =*************

# Son olarak konsol dışında 80.porttan erişip Github gibi arayüzü kullanmak istiyorsak, Nginx ya da Apache yapılandırmasını yapmalıyız.

Nginx yapılandırması için git kullanıcısından exit diyerek çıkalım.

$ vim /etc/nginx/sites-available/gogs

server {
    listen 80;
    server_name foo.bar.baz;
    location / {
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    Host        $ http_host;
        proxy_pass              http://127.0.0.1:3000;
    }
}

Yeniden servisi çalıştıralım:

$ cd $GOPATH/src/github.com/gogits/gogs
$ ./gogs web


Şimdi tarayıcımıza "foo.bar.baz" dediğimizde bu sayfa ile karşılaşıyor olmalıyız.


Görüşmek üzere o/

12 Mayıs 2016

Posted In: free software, Gezegen, git, go, gogs, Özgür yazılım, service

Mercurial vs Git

Bir proje üzerinde çalışırken, sürüm takip sistemi kullanmak projenin sağlığı açısından çok büyük öneme sahip. Kullanınca ne oluyormuş ya, diyenler için:

* Masaüstünüzdeki "proje_son.*", "valla_bu_son.*", "valla_son_v2.*" gibi dosyaların çoğalmasını engelleyip masaüstü arkaplanınızı net görebilmenize yardımcı olur.
* İşletim sisteminize birşey olsa da (bilgisayarınıza kahve dökseniz bile) projeniz uzak depoda da bulunduğu için içiniz bir miktar rahat olur.
* Projenin önceki versiyonlarına rahatça dönebilirsiniz.
* Dünyanın bir ucundaki proje ortaklarınız ile rahatça çalışabilirsiniz.

Kısacası yukarıda "Yıl olmuş 2016 sürüm takip sistemi kullanmayan mı kaldı" demek istiyorum.

Mercurial da bir sürüm takip sistemi aracı. Çok büyük kısmı Python ile yazılmış. GNU/Linux, Unix-benzeri sistemler, FreeBSD, Mac OS X ve MS Windows işletim sistemlerinde kullanılabiliyor.
 
Ben şimdiye kadar hep Git kullanmıştım. Git, dünyada çok yaygın şekilde kullanılan, oldukça marifetli bir araç. Linux çekirdek geliştiricileri kendi ihtiyaçları doğrultusunda geliştirmiş ve büyük bir kitlenin kullanıldığı bir araç hale gelmiş.

Mercurial'ı öğrenmek için belgelerini okurken şunu gördüm; eğer bir araç gerçekten ne işe yaradığını bilerek, iyi kullanılıyorsa, aynı işi yapan başka bir araca çok az zamanda uyum sağlanıyor. 

Ubuntu 15.04 mercurial kurulumu için: 

    $sudo apt-get install mercurial meld

GİT(git)                       MERCURİAL(hg)

git pull hg pull -u
git fetch hg pull
git reset --hard hg update -C
git revert <commit> hg backout <cset>
git add <new_file> hg add <new_file>
git grep <search>hg grep <search>
git commit -a hg commit
git commit --amend hg commit --amend
git blame hg blame or hg annotate
git blame -C (closest equivalent): hg grep --all
git bisect hg bisect
git rebase --interactive hg histedit <base cset>
git stash hg shelve
git merge hg merge
git cherry-pick <commit> hg graft <cset>
git rebase <upstream> hg rebase -d <cset>
git checkout HEAD hg update
git log -n hg log --limit n
git push hg push


Ayrıntılı karşılaştırmaya buradan ulaşabilirsiniz.
Görüşmek üzere :)
 

16 Mart 2016

Posted In: git, gnu/linux, hg, mercurial, ubuntu

Libreoffice Derlemek ve Gerrit İle Yama Göndermek

Libreoffice'in ne olduğunu bilmeyen de yoktur ama yine de kısaca bahsetmiş olayım. Libreoffice bir masaüstü ofis paketidir. Uzun da bir geçmişe sahip. Staroffice adı altında başlayıp, daha sonra Openoffice olarak geliştirilmiş ve en son Libreoffice adıyla hala geliştirilmeye devam ediyor. Bunun güzel bir yanı da uğraştığımız birşey hakkında rahatça belge bulabilmek oluyor.

Gelelim derleme işlemine. Bekleme kısmını saymazsak çok da zor bir yanı yok. Büyük bir proje olduğu için birazcık sabırla beklemek gerekiyor. Ben Ubuntu 15.04 kullandığımdan izlediğim adımları yazacağım. Tüm Linux türevleri için de sayfa oldukça güzel anlatmış.

Bağımlı paketleri kuralım:

$ sudo apt-get build-dep libreoffice

Depoyu yerelimize alalım ve proje dizinine geçelim:

$ git clone git://anongit.freedesktop.org/libreoffice/core libreoffice
$ cd libreoffice

Make işleminden önce betik dosyasının hatasız çalıştığını görmeliyiz:

$ ./autogen.sh

Daha sonra uzunca bekleyeceğimiz make komutunu çalıştıralım:

$ make -j[çekirdek sayisi]

Derlemeden sonra writer'ı çalıştırıp Libreoffice5'in çalıştığından emin olalım:

$ instdir/program/soffice --writer

Bir de derleme yaparken karşılaştığım bir hata:
(libkrb5-dev paketini kurduğumda düzelmişti)

configure: error: could not find function 'krb5_sendauth' required for Kerberos 5

Yazarın notu :D
Geliştirme yapmak işteyenler için KDevelop aracı öneriliyor. Bunun için modüllerin kdevelop ile açılabilir olması gerekiyor.
"make kdevelop-ide-integration" komutu ile modüller Kdevelop ile açılabilir hale geliyor.

Yama Yollarken:

Gerrit kod işbirliği aracı olarak kullanılıyor. İlk kez yama yollayanlar için önce buraya kendinizi eklemeniz gerekiyor. Eklerken Lisans kısmı için libreoffice@lists.freedesktop.org a bir mail atmanız gerekiyor.
mail başlığı:
<your name> license statement

içeriği:
"
 All of my past & future contributions to LibreOffice may be
licensed under the MPLv2/LGPLv3+ dual license.

Gerrit kullanmak için adımlar:

$ ./logerrit setup komutunu çalıştırdıktan sonra oluşan "/home/[username]/.ssh/id_rsa.pub" içerigini gerrit üyeliğimizde ayarlar sekmesinden ssh kısmına eklemeliyiz.
 
$ ./logerrit test komutu sorunsuz çalışıyorsa gerrit aracını kullanabiliriz. 

Daha sonra yeni bir dal oluşturup değişiklik yaptığımız dosyaları ekleyip commit yapacağız.

$ git checkout -b <yeni dal adı>

$ git add dosya (tüm değişiklik yapılan dosyalar için 'git add .')

$ git commit (burada commit mesajı ile bug numarasını ilişkilendirmeliyiz. bunu da commit mesajına "tdf#<bug _id>" ekleyerek yapıyoruz )

Son olarak gerrit'e bu commiti yollayacağız:

$ ./logerrit submit master

Gerrit sayfasından da commitinizi görebilirsiniz :)

Kolay gelsin.

30 Eylül 2015

Posted In: compile, derleme, gerrit, Gezegen, git, gnu/linux, libreoffice, patch

Git’te Yama Uygularken Oluşan Çakışmaları Çözmek


Yazma iznimizin olmadığı depodaki projeye katkı verme işlemini yama dosyası oluşturarak yaparız. Yama dosyaları karşı tarafa yaptığımız değişiklikleri insan okuyabilir şekilde özetler. Bu konu hakkında kısa bir yazı yazmışım, buradan bakabilirsiniz.

Github üzerinden geliştirdiğim kendi projelerime olan katkıları kabul ederken terminal kullanmadan, web sayfası üzerinden hallediyorum.

Linux çekirdeğinde her takım farklı alt dizinlere baktığından ve çoğu github kullanmadığından işlemleri konsol üzerinden yapmak gerekiyor.

Linux çekirdeğinde uzunca bir süredir büyük bir yama  setini kabul ettirmeye çalışıyorum. İnsanlık için küçük olabilir ama benim için büyük demeden geçmeyelim. Yamanın konusu özetle bellek üzerinde büyük bir baskı olduktan sonra swapten dönerken, ihtiyaç duyulmayan sayfaları da swapten belleğe getirip büyük sayfa oluşturarak, performans sağlamak.

Bu yama uzun bir sürece girdiğinden, linux çekirdeği sürekli güncelleniyor ve benim değişikliklerim deponun eski halindeki gibi kalıyor. Bu durumda karşı taraf uygulamaya çalışırken çakışma oluşacak, yama bu nedenle reddedilecek.

Eskiden hep küçük değişiklikler yaptığımdan ve daha kısa süreçte bittiğinden, kendi yamamı güncel depoya uygulama ihtiyacı duymadım. Her satırı tekrar kontrol ederek yeniden oluşturuyordum. Yama büyük olduğunda işler böyle olmadı. Her satırı tekrar oluşturmak çok zor ve derlemede hata almıyorsam bile mantıksal hata yapma ihtimalim çok yüksek.

Değişiklikleri uygulamadan önce git apply --check yama_dosyası şeklinde yamanın uygulanabilir olup olmadığını kontrol edebiliriz. Eğer git apply yama_dosyası komutunu verirsek, yamayı commit yapmadan depoya ekler. Bu durumda değişiklikler commitlenmediği için de git diff ile farkları görebiliriz. Bu bize yama dosyasını ekleyip, commit yapmayarak elle başka değişiklikler yapmaya olanak verir. Tüm değiştirmek istediğimiz dosyalar bittikten sonra kendimiz git commit -a komutuyla değişiklikleri loglayabiliriz.

Yamanın commit yapılarak depoya eklenmesini istiyorsak git am < yama_dosyası şeklinde uygulamalıyız.

Eğer daha önceden yaptığımız commitlerde düzenlemeler istiyorsak git rebase harika bir araç. Onunla ilgili daha önceden bir yazı yazmıştım, buradan bakabilirsiniz.

Yama uygularken geçenlerde karşılaştığım durum, yamanın (muhtemelen) güncel depoyla uyumlu olmamasından kaynaklıyordu. Hata aldığım makine çok sık kullandığım bir makine değildi, belki daha önceki başka bir şeyden kaynaklanıyor da olabilir. Hata mesajı şu şekilde:

Applying: mm: add tracepoint for scanning pages
error: include/trace/events/huge_memory.h: already exists in working directory
error: patch failed: mm/huge_memory.c:2673
error: mm/huge_memory.c: patch does not apply
Patch failed at 0001 mm: add tracepoint for scanning pages
The copy of the patch that failed is found in:
   /home/ebru/linux-stable/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Bunu görünce daha önceden aynı commitler depoda vardı, bu yüzden bir yerde indeksleri tutuluyor düşündüm. mv linux-stable/.git/rebase-apply ..path/ ile rebase-apply dizinini başka bir yere taşıdım. Tekrar yamayı uygulamaya çalıştım yine aynı hatayı aldım (kaldırdığım dizin tekrar oluştu).

Bunun çözümü şu şekilde hatayı aldıktan sonra, git apply linux-stable/.git/rebase-apply/patch --reject komutunu veriyoruz. Bu sayede yamanın çakışma oluşturmayan kısımları depoda oluşturuluyor.

Checking patch include/linux/mm.h...
Checking patch include/trace/events/huge_memory.h...
error: include/trace/events/huge_memory.h: already exists in working directory
Checking patch mm/huge_memory.c...
Hunk #1 succeeded at 30 (offset 1 line).
Hunk #2 succeeded at 2270 (offset 53 lines).
Hunk #3 succeeded at 2307 (offset 53 lines).
Hunk #4 succeeded at 2319 (offset 53 lines).
Hunk #5 succeeded at 2327 (offset 53 lines).
....
       ........
Hunk #13 applied cleanly.
Hunk #14 applied cleanly.
Hunk #15 applied cleanly.
Hunk #16 applied cleanly.
Rejected hunk #17.
Hunk #18 applied cleanly

Bu şekilde uygulanan/uygulanamayan kısımları özetliyor. Uygulamada sorun oluşturan her dosya için uygulanamayan kısımları dosya_adı.rej uzantılı diff dosyası oluşturarak bize gösteriyor. Bu dosyaları git status ile bakarsak görebiliriz. Bu süreçte depo aslında rebase etme gibi git apply sürecinde oluyor. Yamanın uygulanmayan kısımlarına .rej uzantılı dosyalardan bakıp, kendimiz dosyaları açıp değişiklikleri yapıyoruz. git status ile tekrar bakıp eklememiz gereken dosyaları git add ile ekledikten git am --resolved ile işlemi sonlandırıyoruz. Bu şekilde çakışma oluşan yama dosyalarını depoya uygulamış olduk.

Çakışma çözme işlemini bu yazıdan okuyarak öğrendim. Umarım benim yazım da faydalı olmuştur.

8 Eylül 2015

Posted In: çekirdek, Gezegen, git, git am, git apply, github, kernel, linux, yama

Reverting Changes From Remote Git Repo

If you want to revert multiple changes So the solution is to create a new commit which reverts changes that you want to get rid of.

A <– B <– C <– D

$ git revert --no-commit D$ git revert --no-commit C
$ git revert --no-commit B
$ git commit -m'the commit message'

9 Şubat 2015

Posted In: commit, git, github, revert

Reverting Changes From Remote Git Repo

If you want to revert multiple changes So the solution is to create a new commit which reverts changes that you want to get rid of.

A <– B <– C <– D

$ git revert --no-commit D$ git revert --no-commit C
$ git revert --no-commit B
$ git commit -m'the commit message'

9 Şubat 2015

Posted In: commit, git, github, revert

Bir Git Deposuna Başka Bir Git Deposunu Geçmişiyle Taşımak

Diyelim ki git deposunda geliştirdiğiniz projenizi başka bir git deposunun içindeki bir yere taşımanız gerekti. (Transfer işleminden bahsetmiyorum.) Ve kendi deponuzdayken yaptığınız commitlerin de kaybolmasını istemiyorsunuz. Öyleyse sırayla aşağıdaki adımları takip edmelisiniz:

$git clone kendi_depom
$git clone hedef_depo
$cd hedef_depo
$git checkout master
$git remote add rm1remote <kendi_depomun_urlsi>
$git fetch rm1remote
$git merge rm1remote/master
$git remote rm rm1remote

7 Ocak 2015

Posted In: Gezegen, git, github, linux, move a repo, ozguryazilim

İmzalamadığınız Commit Sizin Değildir

Git kullananlar bilirler, .gitconfig isimli dosyaya isim soyisim ve e-posta adresi yazılarak commit loglarına commit sahibinin bilgileri otomatik eklenir.

Ancak bu durumun bir olumsuz(?) yanı vardır. Başkaları sizin adınıza commit yapabilir.
Kendi .gitconfig dosyanıza Ali yazsanız Ali’nin adına Veli yazsanız Veli’nin adına commit yapabilirsiniz.

Ancak bir commit’in gerçekten o kişinin yaptığına emin olmak için commit’i imzalamakta fayda vardır.

Peki imzalamayı nasıl yapacağız?

Öncelikle sisteminizde imza var mı bakınız:

gpg --list-keys

(Eğer daha önce GPG ile ilgili işlem yapmamışsanız, bu komut gerekli dosyaları da oluşturacaktır.)

Şuna benzer bir sonuç döndürmeli:

pub   2048R/B489436C 2014-12-14
uid                  Adil Ilhan <no-reply@adililhan.com>

Eğer GPG anahtarınız yoksa boş sonuç dönecektir.

gpg --gen-key

komutu ile GPG anahtarınızı oluşturabilirsiniz. Bu komut size yol gösterecektir.

Ekstra olarak açıklama gereği duyduğum kısım passphrase kısmı. Buraya parola girerseniz oluşturacağınız anahtar bu parola olmadan çalışmayacaktır. Yani anahtarınız çalınsa bile ekstra olarak bir de buraya yazdığınız parolaya ihtiyaç duyulacaktr.

GPG anahtarı artık oluşmuş olmalı. Kontrol için:

gpg --list-keys

Git ortamınıza bu anahtarı tanımlamak gerek:

git config --global user.signingkey B489436C

B489436C bilgisini gpg –list-keys komutunun sonucundan aldım.

Artık commitleri -S parametresi ile imzalayabiliriz:

git commit -m "test" -S

İmzalanmış commitleri görme ve doğruluğunu teyit etme:

git log --show-signature

Bu komut, yerel (local) makinenizdeki GPG bilgisi ile commit log’unda yer alan GPG bilgisini eşleştirir.
Uyuşan loglara gpg: Good signature… yazılır. Uyuşmayan loglara Can’t check signature yazılır.

Örneğin sizin bilgisayarınızdan imzalanarak commitlenen bir commit başka bir bilgisayarda bakıldığında ve o bilgisayarda sizin GPG anahtarınız yoksa log sonuçlarına Can’t check signature bilgisi yazılır.

15 Aralık 2014

Posted In: Genel, Gezegen, git, GPG

Pardus Yaz Kampı 2013 Hakkında…

Eylül ayına girdiğimiz bugün http://kamp.pardus.org.tr/ adresi altında yürütülen Pardus Yaz Kampı ne durumda diye merak edip bir bakınayım dedim. Sitedeki bol ünlemli bir duyuru sayesinde erişilen http://gitweb.pardus.org.tr/ sayfasına girdiğimde beklemediğim bir manzarayla karşılaştım.

pardusyazkampiAçıkçası bu sayfaya en son 1 ay kadar önce girmiştim, bugün girmeden önce “projelerin süresi de dolar yakında, artık ortam şenlenmiştir” diye düşünüyordum ama boşuna… Projelerle ilgili kişiler ya hayatlarında daha önce SVN, Git falan kullanmamışlar, ya da bu projelerde kullanmaya gerek duymuyorlar (o nasıl olacaksa) bilmiyorum ama en son 3 hafta, 5 hafta önce commit yapılan proje nedir yahu? Hem de bir değil, kaç proje birden…

1 Eylül 2013

Posted In: Gezegen Yazıları, git, linux, pardus, pardus yaz kampı

WP Twitter Auto Publish Powered By : XYZScripts.com