Perforce, kurumsal ortamlarda çok popüler olan bir sürüm kontrol sistemidir. Bu, bu bölümde ele alınan, 1995’ten beri varolan en eski sistemdir. Bu nedenle, o günün kısıtlamaları dahilinde tasarlanmıştır: her zaman tek bir merkezi sunucuya bağlı olduğunuzu ve yerel diskte yalnızca bir sürümünün tutulduğunu varsayar. Elbette, özellikleri ve kısıtlamaları belirli problemlere yönelik çok uygun olmakla beraber, aslında Git’in daha iyi çalışacabileceği birçok projede yine de Perforce kullanılmaktadır.
Perforce ve Git’i karıştırmak isterseniz iki seçeneğiniz bulunmaktadır.
İlk olarak, Perforce’un yapımcılarından Git Fusion köprüsünü ele alacağız, bu size Perforce depo ağacının alt kısımlarını okuma-yazma Git repoları olarak açmanızı sağlar.
İkincisi, Perforce sunucusunun yeniden yapılandırılmasını gerektirmeyen Git’i bir Perforce istemcisi olarak kullanmanıza izin veren bir istemci tarafı köprüsü olan git-p4’tür.
Perforce, bir Perforce sunucusunu sunucu tarafındaki Git repolarıyla senkronize eden "Git Fusion" adlı bir ürün sağlar. Bu ürünü http://www.perforce.com/git-fusion adresinden temin edebilirsiniz.
Örneklerimiz için, Git Fusion’ın en kolay kurulum yöntemini kullanacağız. Bu yöntem, Perforce cini (daemon) ve Git Fusion’ı çalıştıran bir sanal makine indirmeyi içerir. Sanal makine görüntüsünü http://www.perforce.com/downloads/Perforce/20-User adresinden edinebilir ve indirme tamamlandıktan sonra dilediğiniz bir sanallaştırma yazılımıyla (biz VirtualBox kullanacağız) içe aktarabilirsiniz.
Makineyi ilk çalıştırdığınızda, üç Linux kullanıcısı (root, perforce ve git) için özel şifre belirlemenizi ve bu kurulumu ağdaki diğer kurulumlardan ayırt etmek için bir örnek adı girmeniz istenir.
Bu işlemler tamamlandığında aşağıdakini göreceksiniz:
İleride kullanacağınız için burada gösterilen IP adresini not etmelisiniz.
Sonraki adımda bir Perforce kullanıcısı oluşturacağız.
Alt kısımda bulunan Login seçeneğini seçin ve root olarak giriş yapın.
Ardından aşağıdaki komutları kullanarak bir kullanıcı oluşturun:
$ p4 -p localhost:1666 -u super user -f john
$ p4 -p localhost:1666 -u john passwd
$ exitİlk komut, kullanıcıyı özelleştirmek için bir VI düzenleyici açacak, ancak varsayılanları kabul ederek :wq yazıp enter tuşuna basarak çıkabilirsiniz.
İkinci komut, sizden iki kez bir şifre girmenizi isteyecektir.
Shell komut istemimizle yapmamız gereken bu kadar, bu yüzden oturumu kapatabilirsiniz.
İlerlemek için yapmanız gereken bir sonraki adım, Git’in SSL sertifikalarını doğrulamamasını söylemektir. Git Fusion görüntüsü bir sertifika ile birlikte gelir; ancak bu, sanal makinenizin IP adresiyle eşleşmeyecek bir alan adı için olduğundan, Git HTTPS bağlantısını reddedecektir. Bu kalıcı bir kurulum olacaksa, farklı bir sertifika yüklemek için Perforce Git Fusion kılavuzuna başvurun; ancak örnek amaçlarımız için, bu yeterlidir:
$ export GIT_SSL_NO_VERIFY=trueŞimdi her şeyin çalışıp çalışmadığını test edebiliriz.
$ git clone https://10.0.1.254/Talkhouse
Cloning into 'Talkhouse'...
Username for 'https://10.0.1.254': john
Password for 'https://john@10.0.1.254':
remote: Counting objects: 630, done.
remote: Compressing objects: 100% (581/581), done.
remote: Total 630 (delta 172), reused 0 (delta 0)
Receiving objects: 100% (630/630), 1.22 MiB | 0 bytes/s, done.
Resolving deltas: 100% (172/172), done.
Checking connectivity... done.Sanal makine görüntüsü, kopyalayabileceğiniz bir örnek proje ile birlikte gelir.
Aşağıda, yukarıda oluşturduğumuz john kullanıcısı ile HTTPS üzerinden kopyalama işlemini gerçekleştiriyoruz; Git bu bağlantı için kimlik bilgisi isteyecek, ancak kimlik bilgisi önbelleği sonraki isteklerde bu adımı atlamamıza izin verecektir.
Git Fusion’ı kurduktan sonra yapılandırmayı ayarlamak isteyeceksiniz.
Aslında bunu favori Perforce istemciniz kullanarak kolayca yapabilirsiniz; sadece Perforce sunucusundaki //.git-fusion dizinini çalışma alanınıza eşleyin.
Dosya yapısı şuna benzer:
$ tree
.
├── objects
│ ├── repos
│ │ └── [...]
│ └── trees
│ └── [...]
│
├── p4gf_config
├── repos
│ └── Talkhouse
│ └── p4gf_config
└── users
└── p4gf_usermap
498 directories, 287 filesobjects dizini, Perforce nesnelerini Git’e ve tersine eşlemek için Git Fusion tarafından içsel olarak kullanılır.
Bu dizindeki herhangi bir şeyle uğraşmanız gerekmez.
Bu dizinde bir tane global p4gf_config dosyası bulunur ve her bir repo için de ayrı bir tane (bunlar, Git Fusion’ın nasıl davrandığını belirleyen yapılandırma dosyalarıdır).
Şimdi, kök dizindeki dosyaya bir göz atalım:
[repo-creation]
charset = utf8
[git-to-perforce]
change-owner = author
enable-git-branch-creation = yes
enable-swarm-reviews = yes
enable-git-merge-commits = yes
enable-git-submodules = yes
preflight-commit = none
ignore-author-permissions = no
read-permission-check = none
git-merge-avoidance-after-change-num = 12107
[perforce-to-git]
http-url = none
ssh-url = none
[@features]
imports = False
chunked-push = False
matrix2 = False
parallel-push = False
[authentication]
email-case-sensitivity = noBu bayrakların anlamlarına burada girmeyeceğiz, ancak bunun yalnızca Git yapılandırması için kullanılan INI dosyaları gibi biçimlendirildiğini unutmayın.
Bu dosya, repos/Talkhouse/p4gf_config gibi özel repo yapılandırma dosyaları tarafından geçersiz kılınabilecek global seçenekleri belirtir.
Bu dosyayı açarsanız, global varsayılanlardan farklı olan bazı ayarları içeren [@repo] bölümünü göreceksiniz.
Ayrıca şu şekilde görünen bölümler de göreceksiniz:
[Talkhouse-master]
git-branch-name = master
view = //depot/Talkhouse/main-dev/... ...Bu, bir Perforce dalı ile bir Git dalı arasındaki eşlemeyi belirtir.
Bölüm adı benzersiz olduğu sürece istediğiniz şekilde adlandırabilirsiniz.
git-branch-name, Git altında sıkıntılı olabilecek bir depo yolunu daha dostane bir isme dönüştürmenize olanak tanır.
view ayarı, Perforce dosyalarının Git reposuna eşlenme şeklini, standart görünüm eşleme sözdizimini (standard view mapping syntax) kullanarak kontrol eder.
Bu örnekte olduğu gibi birden fazla eşleme belirtilebilir:
[multi-project-mapping]
git-branch-name = master
view = //depot/project1/main/... project1/...
//depot/project2/mainline/... project2/...Bu şekilde, normal çalışma alanı eşlemeleriniz dizin yapılarında değişiklikler içeriyorsa, bunu bir Git reposuyla çoğaltabilirsiniz.
Bahsedeceğimiz son dosya, Perforce kullanıcılarını Git kullanıcılarına eşleyen ve belki de hiç ihtiyaç duymayacağınız users/p4gf_usermap dosyasıdır.
Bir Perforce değişiklik kümesi bir Git katkısına dönüştürülürken, Git Fusion’ın varsayılan davranışı; Perforce kullanıcısını aramak ve Git’teki yazar/adlandırıcı alanı için orada saklanan e-posta adresini ve tam adı kullanmaktır.
Diğer yöne dönüştürülürken, varsayılan olarak, Git katkısının yazar alanında saklanan e-posta adresine sahip Perforce kullanıcısını aramak ve değişiklik kümesini, (uygulanan izinlerle) o kullanıcı olarak göndermektir.
Çoğu durumda, bu yeterli olacaktır, ancak aşağıdaki eşleme dosyasını düşünün:
john john@example.com "John Doe"
john johnny@appleseed.net "John Doe"
bob employeeX@example.com "Anon X. Mouse"
joe employeeY@example.com "Anon Y. Mouse"Her satır, bir kullanıcı eşlemesi oluşturan <user> <email> "<tam ad>" formatındadır.
İlk iki satır, iki farklı e-posta adresini aynı Perforce kullanıcı hesabına eşler.
Bu, birkaç farklı e-posta adresi altında (veya e-posta adreslerini değiştirip) Git katkıları oluşturduysanız, ancak bunların aynı Perforce kullanıcısına eşlenmesini istiyorsanız faydalıdır.
Bir Git katkısı oluşturulurken, Perforce kullanıcısını eşleştiren ilk satır Git yazar bilgileri için kullanılır.
Son iki satır, Bob ve Joe’nun gerçek adlarını ve e-posta adreslerini oluşturulan Git katkılarından gizler. Bu, iç bir projeyi açık kaynağa dönüştürmek istiyorsanız, ancak çalışan dizininizi herkese yayınlamak istemiyorsanız iyidir. E-posta adreslerinin ve tam adların benzersiz olması gerektiğini unutmayın, aksi takdirde tüm Git katkıları tek bir kurgusal yazarla ilişkilendirilir.
Perforce Git Fusion, Perforce ve Git sürüm kontrolü arasında iki yönlü bir köprüdür.
Şimdi Git tarafından çalışmak nasıl hissettiriyor, ona bir göz atalım.
Yukarıda gösterildiği gibi bir yapılandırma dosyasını kullanarak Jam projesini eşlediğimizi varsayalım.
Şu şekilde kopyalayabiliriz:
$ git clone https://10.0.1.254/Jam
Cloning into 'Jam'...
Username for 'https://10.0.1.254': john
Password for 'https://john@10.0.1.254':
remote: Counting objects: 2070, done.
remote: Compressing objects: 100% (1704/1704), done.
Receiving objects: 100% (2070/2070), 1.21 MiB | 0 bytes/s, done.
remote: Total 2070 (delta 1242), reused 0 (delta 0)
Resolving deltas: 100% (1242/1242), done.
Checking connectivity... done.
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/origin/rel2.1
$ git log --oneline --decorate --graph --all
* 0a38c33 (origin/rel2.1) Create Jam 2.1 release branch.
| * d254865 (HEAD, origin/master, origin/HEAD, master) Upgrade to latest metrowerks on Beos -- the Intel one.
| * bd2f54a Put in fix for jam's NT handle leak.
| * c0f29e7 Fix URL in a jam doc
| * cc644ac Radstone's lynx port.
[...]Bunu ilk kez yaptığınızda, biraz zaman alabilir. Olup biten şey, Git Fusion’ın Perforce geçmişindeki tüm uygun değişiklikleri Git katkılarına dönüştürmesidir. Bu, sunucuda yerel olarak gerçekleştiği için, nispeten hızlıdır, ancak geçmişiniz çok kalabalıksa, biraz zaman alabilir. Sonraki çekmeler, artımlı dönüşüm yapar, bu yüzden Git’in kendi hızı gibi hissettirecektir.
Görebileceğiniz gibi, repomuz Git ile çalıştığınız diğer herhangi bir Git reposuna benzer.
Üç dal var ve Git, origin/master’ı izleyen bir yerel `master dalı oluşturdu.
Biraz çalışıp birkaç yeni katkı oluşturalım:
# ...
$ git log --oneline --decorate --graph --all
* cfd46ab (HEAD, master) Add documentation for new feature
* a730d77 Whitespace
* d254865 (origin/master, origin/HEAD) Upgrade to latest metrowerks on Beos -- the Intel one.
* bd2f54a Put in fix for jam's NT handle leak.
[...]İki yeni katkımız var. Şimdi başka birinin de çalışıp çalışmadığını kontrol edelim:
$ git fetch
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://10.0.1.254/Jam
d254865..6afeb15 master -> origin/master
$ git log --oneline --decorate --graph --all
* 6afeb15 (origin/master, origin/HEAD) Update copyright
| * cfd46ab (HEAD, master) Add documentation for new feature
| * a730d77 Whitespace
|/
* d254865 Upgrade to latest metrowerks on Beos -- the Intel one.
* bd2f54a Put in fix for jam's NT handle leak.
[...]Görünüşe göre biri çalışmış!
Bu ekrandan bunu bilmezsiniz, ancak 6afeb15 katkısı aslında bir Perforce istemcisi kullanılarak oluşturuldu.
Git’in açısından sadece başka bir katkı gibi görünüyor, işte bahsettiğimiz tam olarak bu.
Şimdi Perforce sunucusunun bir birleştirme katkısı ile nasıl başa çıktığına bakalım:
$ git merge origin/master
Auto-merging README
Merge made by the 'recursive' strategy.
README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 917 bytes | 0 bytes/s, done.
Total 9 (delta 6), reused 0 (delta 0)
remote: Perforce: 100% (3/3) Loading commit tree into memory...
remote: Perforce: 100% (5/5) Finding child commits...
remote: Perforce: Running git fast-export...
remote: Perforce: 100% (3/3) Checking commits...
remote: Processing will continue even if connection is closed.
remote: Perforce: 100% (3/3) Copying changelists...
remote: Perforce: Submitting new Git commit objects to Perforce: 4
To https://10.0.1.254/Jam
6afeb15..89cba2b master -> masterGit’e göre iş tamam.
Şimdi de Perforce açısından, p4v 'nin revizyon grafiği özelliğini kullanarak README dosyasının geçmişine bir göz atalım:
Bu görüntüyü daha önce hiç görmediyseniz, kafa karıştırıcı görünebilir ancak tıpkı Git geçmişi için tasarlanan bir grafiksel görüntüleyici gibi çalışır.
README dosyasının geçmişine bakıyoruz, bu yüzden sol üst köşedeki dizin ağacı, dosyanın çeşitli dallarda nasıl göründüğünü göstermetderir.
Sağ üstte, dosyanın farklı revizyonlarının nasıl ilişkilendirildiğini gösteren bir görsel grafik vardır, sağ altta ise bu grafiğin genel görünümü bulunur.
Geri kalan görünüm, seçilen revizyonun detaylı görünümüne (burada 2) ayrılmıştır.
Dikkat edilmesi gereken bir şey de, grafiğin tam olarak Git geçmişindeki gibi görünmesidir.
Perforce, 1 ve 2 katkılarını depolamak için adlandırılmış bir dalı olmadığı için, onu saklamak için .git-fusion dizininde "isimsiz" bir dal oluşturdu.
Bu davranış ismi olan Git dalları için de gerçekleşir (bu dalları daha sonra bir Perforce dalına yapılandırma dosyasını kullanarak eşleştirebilirsiniz).
Bunların çoğu arka planda gerçekleşir, ancak sonuç olarak bir ekip içinde bir kişi Git’i kullanırken, diğeri Perforce’u kullanabilir ve ikisi de diğerinin tercihinden haberdar olmaz.
Perforce sunucunuza erişiminiz varsa (veya edinebilirseniz), Git Fusion’ın Git ve Perforce’un birbirleriyle iletişim kurmasının harika bir yolu olduğunu göreceksiniz. Bunun için biraz yapılandırma gereklidir, ancak öğrenme eğrisi çok dik değildir. Bu bölüm, Git’in tam gücünü kullanmanın sakıncalarıyla ilgili uyarıların pek yer almadığı nadir bölümlerden biridir. Bu, Perforce’un üzerine fırlattığınız her şeyden mutlu olacağı anlamına gelmez (mesela, zaten gönderilmiş olan geçmişi yeniden yazmaya çalışırsanız, Git Fusion bunu reddedecektir) ancak Git Fusion normal davranmak için çok çaba sarf eder. Hatta Git altmodüllerini bile kullanabilirsiniz (ancak bunlar Perforce kullanıcıları için garip görünebilir) ve dalları birleştirebilirsiniz (bu, Perforce tarafında bir entegrasyon olarak kaydedilecektir).
Sunucunuzun yöneticisini Git Fusion’ı kurmaya ikna edemezseniz, bu araçları birlikte kullanmanın yine de bir yolu vardır.
Git-p4, Git ile Perforce arasında iki yönlü bir köprüdür. Tamamen Git reposu içinde çalışır, bu nedenle Perforce sunucusuna erişim sağlamanıza gerek yoktur (elbette kullanıcı kimlik bilgilerine ihtiyacınız olacaktır). Git-p4, Git Fusion kadar esnek veya tam bir çözüm değildir, ancak sunucu ortamına aşırı müdahale etmeden istediğiniz çoğu şeyi yapmanıza izin verir.
|
Note
|
You’ll need the |
Örnek amaçlar için yukarıda gösterildiği gibi Git Fusion OVA’sından Perforce sunucusunu çalıştıracağız, ancak Git Fusion sunucusunu atlayacak ve doğrudan Perforce sürüm kontrolüne gideceğiz.
Git-p4’ün bağımlı olduğu p4 komut satırı istemcisini kullanabilmek için birkaç ortam değişkenini ayarlamanız gerekecektir:
$ export P4PORT=10.0.1.254:1666
$ export P4USER=johnGit’teki herşeyde olduğu gibi, ilk iş kopyalamaktır:
$ git p4 clone //depot/www/live www-shallow
Importing from //depot/www/live into www-shallow
Initialized empty Git repository in /private/tmp/www-shallow/.git/
Doing initial import of //depot/www/live/ from revision #head into refs/remotes/p4/masterBu, Git terimleriyle bir "yüzeysel" bir kopya oluşturur; sadece en son Perforce revizyonu Git’e aktarılır. Unutmayın, Perforce, her revizyonu her kullanıcıya vermek için tasarlanmamıştır! Bu, Git’i bir Perforce istemcisi olarak kullanmak için yeterlidir, ancak diğer amaçlar için yeterli değildir.
İşlem tamamlandığında, tamamen işlevsel bir Git reposuna sahip olacaksınız:
$ cd myproject
$ git log --oneline --all --graph --decorate
* 70eaf78 (HEAD, p4/master, p4/HEAD, master) Initial import of //depot/www/live/ from the state at revision #headPerforce sunucusu için uzak bir p4 reposu var gibi görünse de, diğer her şey standart bir kopya gibi görünür.
Aslında, bu biraz yanıltıcıdır; zira aslında bir uzak repo yoktur.
$ git remote -vBu repoda hiçbir uzak repo yoktur.
Git-p4 sunucunun durumunu temsil etmek için bazı referanslar oluşturmuştur ve bunlar git log için uzak referanslara benzeyebilir, ancak Git’in kendisi tarafından yönetilmezler ve bunlara itme işlemi gerçekleştiremezsiniz.
Hadi, biraz iş yapalım. Varsayalım ki çok önemli bir özellik üzerinde biraz ilerleme kaydettiniz ve geri kalan ekibinize göstermeye hazırsınız.
$ git log --oneline --all --graph --decorate
* 018467c (HEAD, master) Change page title
* c0fb617 Update link
* 70eaf78 (p4/master, p4/HEAD) Initial import of //depot/www/live/ from the state at revision #headPerforce sunucusuna gönderilmeye hazır iki yeni katkımız var. Bugün başka birinin çalışıp çalışmadığını kontrol edelim:
$ git p4 sync
git p4 sync
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
Import destination: refs/remotes/p4/master
Importing revision 12142 (100%)
$ git log --oneline --all --graph --decorate
* 75cd059 (p4/master, p4/HEAD) Update copyright
| * 018467c (HEAD, master) Change page title
| * c0fb617 Update link
|/
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headGörünüşe göre master ile p4/master ayrışmış durumda.
Perforce’un dal sistemi kesinlikle Git’inki gibi değil, bu nedenle birleştirme katkılarını göndermek hiçbir anlam ifade etmez.
Git-p4 katkılarınızı yeniden temellemenizi önerir ve hatta bunu yapmanız için size bir kısayol sunar:
$ git p4 rebase
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
No changes to import!
Rebasing the current branch onto remotes/p4/master
First, rewinding head to replay your work on top of it...
Applying: Update link
Applying: Change page title
index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)Çıktıdan anlayabilirsiniz ama git p4 rebase, git rebase p4/master’ı takiben `git p4 sync için bir kısayoldur.
Özellikle birden fazla dal üzerinde çalışırken biraz daha akılcı bir yöntem ve iyi bir yaklaşımdır.
Şimdi geçmişimiz tekrar çizgisel hale geldi ve değişikliklerimizi Perforce’a tekrar katkıda bulunmaya hazırız.
git p4 submit komutu, p4/master ile master arasındaki her Git katkısı için yeni bir Perforce revizyonu oluşturmaya çalışacaktır. Çalıştırdığımızda, bizi favori metin düzenleyicimize götürür ve dosyanın içeriği şuna benzemektedir:
# A Perforce Change Specification.
#
# Change: The change number. 'new' on a new changelist.
# Date: The date this specification was last modified.
# Client: The client on which the changelist was created. Read-only.
# User: The user who created the changelist.
# Status: Either 'pending' or 'submitted'. Read-only.
# Type: Either 'public' or 'restricted'. Default is 'public'.
# Description: Comments about the changelist. Required.
# Jobs: What opened jobs are to be closed by this changelist.
# You may delete jobs from this list. (New changelists only.)
# Files: What opened files from the default changelist are to be added
# to this changelist. You may delete files from this list.
# (New changelists only.)
Change: new
Client: john_bens-mbp_8487
User: john
Status: new
Description:
Update link
Files:
//depot/www/live/index.html # edit
######## git author ben@straub.cc does not match your p4 account.
######## Use option --preserve-user to modify authorship.
######## Variable git-p4.skipUserNameCheck hides this message.
######## everything below this line is just the diff #######
--- //depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
+++ /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/index.html 2014-08-31 18:26:05.000000000 0000
@@ -60,7 +60,7 @@
</td>
<td valign=top>
Source and documentation for
-<a href="http://www.perforce.com/jam/jam.html">
+<a href="jam.html">
Jam/MR</a>,
a software build tool.
</td>Bir Perforce Değişiklik Belgesi.
Değişiklik: Değişiklik numarası. Yeni bir değişiklik listesi için 'new.
Tarih: Bu belgenin son olarak ne zaman değiştirildiği.
İstemci: Değişiklik listesinin oluşturulduğu istemci. Salt okunur.
Kullanıcı: Değişiklik listesini oluşturan kullanıcı.
Durum: 'pending' veya 'submitted' olabilir. Salt okunur.
Tür: 'public' veya 'restricted' olabilir. Varsayılan olarak 'public'.
Açıklama: Değişiklik listesi hakkındaki yorumlar. Gereklidir.
İşler: Bu değişiklik listesi tarafından kapatılacak açık işler.
Bu listeden işleri silebilirsiniz. (Yeni değişiklik listeleri için.)
Dosyalar: What opened files from the default changelist are to be added to this changelist.
You may delete files from this list. (New changelists only.)Bu, p4 submit komutunu çalıştırarak görebileceğiniz içeriğin çoğunlukla aynısıdır, ancak git-p4’ün yardımcı olarak dahil ettiği son kısımdan farklıdır.
Git-p4, bir katkı veya değişiklik kümesi için bir isim sağlamak zorunda kaldığında, Git ve Perforce ayarlarınızı ayrı ayrı dikkate almaya çalışır, ancak bazı durumlarda bunu geçersiz kılmak isteyebilirsiniz.
Örneğin, içe aktardığınız Git katkısı bir Perforce kullanıcı hesabı olmayan bir katılımcı tarafından yazılmışsa; sonuçta oluşan değişiklik kümesinin, sizin tarafınızdan değil de onun tarafından yazıldığı gibi görünmesini isteyebilirsiniz.
Git-p4, bu Perforce değişiklik listesi için içerik olarak Git katkı mesajı ithal ettiği için, yapmamız gereken tek şey her bir katkı için kaydetmek ve çıkmaktır. Sonuçta oluşan shell çıktısı şuna benzer olacaktır:
$ git p4 submit
Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Synchronizing p4 checkout...
... - file(s) up-to-date.
Applying dbac45b Update link
//depot/www/live/index.html#4 - opened for edit
Change 12143 created with 1 open file(s).
Submitting change 12143.
Locking 1 files ...
edit //depot/www/live/index.html#5
Change 12143 submitted.
Applying 905ec6a Change page title
//depot/www/live/index.html#5 - opened for edit
Change 12144 created with 1 open file(s).
Submitting change 12144.
Locking 1 files ...
edit //depot/www/live/index.html#6
Change 12144 submitted.
All commits applied!
Performing incremental import into refs/remotes/p4/master git branch
Depot paths: //depot/www/live/
Import destination: refs/remotes/p4/master
Importing revision 12144 (100%)
Rebasing the current branch onto remotes/p4/master
First, rewinding head to replay your work on top of it...
$ git log --oneline --all --graph --decorate
* 775a46f (HEAD, p4/master, p4/HEAD, master) Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headSonuçta, aslında git push yapmışız gibi oldu, bu gerçekte olan şeye en yakın benzetimdir.
Bu süreçte her Git katkısı bir Perforce değişiklik kümesine dönüştürülür.
Eğer onları tek bir değişiklik kümesine sıkıştırmak istiyorsanız, bunu git p4 submit komutunu çalıştırmadan önce, etkileşimli bir temelleme ile yapabilirsiniz.
Ayrıca, değişiklik kümesi olarak gönderilen tüm katkıların SHA-1 karmalarının değiştiğini unutmayın.
Bu, git-p4’ün dönüştürdüğü her katkıya bir satır eklemesinden kaynaklanır:
$ git log -1
commit 775a46f630d8b46535fc9983cf3ebe6b9aa53145
Author: John Doe <john@example.com>
Date: Sun Aug 31 10:31:44 2014 -0800
Change page title
[git-p4: depot-paths = "//depot/www/live/": change = 12144]Birleştirme katkısını göndermeye çalışırsak ne olacağını bir görelim. İşte kendimizi içine soktuğumuz durum:
$ git log --oneline --all --graph --decorate
* 3be6fd8 (HEAD, master) Correct email address
* 1dcbf21 Merge remote-tracking branch 'p4/master'
|\
| * c4689fc (p4/master, p4/HEAD) Grammar fix
* | cbacd0a Table borders: yes please
* | b4959b6 Trademark
|/
* 775a46f Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headGit ve Perforce geçmişi 775a46f sonrasında ayrılıyor. Git tarafında iki katkı var, ardından Perforce başı ile birleştirme katkısı, ve onun ardından başka bir katkı daha. Bu katkıları tek bir değişiklik kümesinin üzerine Perforce tarafında göndermeyi deneyeceğiz. Şimdi göndermeye çalışırsak ne olacağını görelim:
$ git p4 submit -n
Perforce checkout for depot path //depot/www/live/ located at /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Would synchronize p4 checkout in /Users/ben/john_bens-mbp_8487/john_bens-mbp_8487/depot/www/live/
Would apply
b4959b6 Trademark
cbacd0a Table borders: yes please
3be6fd8 Correct email address-n bayrağı, --dry-run için kısaltmadır ve gönderme komutunun gerçekten çalıştırılsaydı ne olacağını rapor etmeye çalışır.
Burada, üç adet Perforce değişiklik kümesi oluşturacağımızı gösteriyor.
Bunlar Perforce sunucusunda henüz bulunmayan birleştirmesiz (non-merge) üç katkıya karşılık gelir.
Tam olarak istediğimiz gibi görünüyor.
Şimdi nasıl sonuçlandığını görelim:
$ git p4 submit
[…]
$ git log --oneline --all --graph --decorate
* dadbd89 (HEAD, p4/master, p4/HEAD, master) Correct email address
* 1b79a80 Table borders: yes please
* 0097235 Trademark
* c4689fc Grammar fix
* 775a46f Change page title
* 05f1ade Update link
* 75cd059 Update copyright
* 70eaf78 Initial import of //depot/www/live/ from the state at revision #headGeçmişimiz, katkıları göndermeden önce yeniden temellemişiz gibi çizgisel hale geldi (gerçekte olan budur). Bu, Git tarafında dallar oluşturabileceğiniz, üzerinde çalışabileceğiniz, silebileceğiniz, birleştirebileceğiniz ve geçmişinizin Perforce ile uyumsuz hale gelme korkusu olmadan özgürce çalışabileceğiniz anlamına gelir. Yeniden temelleme yaparsanız, bunu bir Perforce sunucusuna gönderebilirsiniz.
Perforce projenizde birden fazla dal bulunuyorsa, şansınız tükenmiş değil, git-p4 bunu Gitmişçesine yönetebilir. Diyelim ki Perforce deponuz şu şekilde düzenlenmiş:
//depot
└── project
├── main
└── devVe diyelim ki dev adında bir dalınız var ve bu dalın bir görünüm özelliği şu şekilde görünüyor:
//depot/project/main/... //depot/project/dev/...Git-p4 bu durumu otomatik olarak algılayabilir ve doğru işlemi yapabilir:
$ git p4 clone --detect-branches //depot/project@all
Importing from //depot/project@all into project
Initialized empty Git repository in /private/tmp/project/.git/
Importing revision 20 (50%)
Importing new branch project/dev
Resuming with change 20
Importing revision 22 (100%)
Updated branches: main dev
$ cd project; git log --oneline --all --graph --decorate
* eae77ae (HEAD, p4/master, p4/HEAD, master) main
| * 10d55fb (p4/project/dev) dev
| * a43cfae Populate //depot/project/main/... //depot/project/dev/....
|/
* 2b83451 Project initDepo yolundaki @all belirleyicisine dikkat edin: git-p4’e yalnızca bu alt ağaç için en son değişiklik kümesini değil, bu dizinlere dokunmuş tüm değişiklik kümelerini kopyalamasını söyler.
Bu Git’in kopya (clone) kavramına daha yakındır, ancak geçmişi uzun bir projede çalışıyorsanız, biraz zaman alabilir.
--detect-branches bayrağı git-p4’ün Perforce’un dal özelliklerini kullanarak dalları Git referanslarına eşlemesini söyler.
Bu eşlemeler Perforce sunucusunda bulunmuyorsa (bu, Perforce’u kullanmanın tamamen geçerli bir yoludur), git-p4’e dal eşlemelerinin ne olduğunu söyleyebilirsiniz ve aynı sonucu alırsınız:
$ git init project
Initialized empty Git repository in /tmp/project/.git/
$ cd project
$ git config git-p4.branchList main:dev
$ git clone --detect-branches //depot/project@all .git-p4.branchList yapılandırma değişkenini main:dev olarak ayarlamak, git-p4’e main ve dev 'in her ikisinin de dallar olduğunu ve ikincisinin birincisinin bir alt dalı olduğunu söyler.
Şimdi git checkout -b dev p4/project/dev yapar ve bazı katkılar işlersek, git p4 submit yaptığımızda git-p4’ün doğru dala hedef alacak kadar akıllı olduğunu göreceğiz.
Ne yazık ki, git-p4 sığ kopyaları ve birden fazla dalı karıştıramaz.
Büyük bir projede ve birden fazla dalda çalışmak istiyorsanız, göndermek istediğiniz her dal için bir kez git p4 clone yapmanız gerekecektir.
Dallar oluşturmak veya entegre etmek için bir Perforce istemcisini kullanmanız gerekecektir. Git-p4 yalnızca mevcut dalları senkronize edip ve kaydedebilir ve bunu da sadece bir çizgisel değişiklik kümesiyle yapabilir. Eğer Git’te iki dalı birleştirir ve yeni değişiklik kümesini göndermeye çalışırsanız, kaydedilen tek şey bir sürü dosya değişikliği olacaktır. Entegrasyona hangi dalların katıldığına dair meta veriler kaybolacaktır.
Git-p4, bir Perforce sunucusu ile Git iş akışını kullanmayı mümkün kılar ve bu konuda oldukça iyidir. Ancak kaynakların kontrolünün Perforce’da olduğunu ve Git’i sadece yerelde çalışmak için kullandığınızı unutmamalısınız. Git katkılarını paylaşırken çok dikkatli olun. Başkalarıyla ortak kullandığız bir uzak sunucunuz varsa, Perforce sunucusuna göndermediğiniz hiçbir katkıyı oraya göndermeyin.
Eğer Perforce ve Git’i özgürce kaynak kontrolü istemcileri olarak karıştırmak ister ve sunucu yöneticisini bunu kurmaya ikna edebilirseniz; Git Fusion, Git’i bir Perforce sunucusu için birinci sınıf bir versiyon kontrol istemcisi olarak kullanmanızı sağlar.