Git kaynak kontrolü altında IntelliJ IDEA proje dosyaları sürekli olarak nasıl değiştirilir?


151

Ekibimizdeki herkes IntelliJ IDEA kullanıyor ve derleme yapılandırmalarını, ayarları ve denetimleri paylaşabilmemiz için proje dosyalarını (.ipr ve .iml) kaynak kontrolüne almanın yararlı olduğunu düşünüyoruz. Ayrıca, bu inceleme ayarlarını TeamCity ile sürekli entegrasyon sunucumuzda kullanabiliriz. (Kaynak kontrolünde değil, .gitignore dosyasında kullanıcı başına çalışma alanı .iws dosyasına sahibiz.)

Ancak, IDEA'da hemen hemen her şeyi yaptığınızda bu dosyalar küçük şekillerde değişir. IDEA'nın sorun veritabanında bir sorun var ( IDEA-64312 ), bu yüzden belki de IDEA'da bir hata olarak düşünülebilir, ancak öngörülebilir gelecek için birlikte yaşamamız gerekecek.

Yakın zamana kadar Subversion kullanıyorduk, ancak yakın zamanda Git'e geçtik. Her biri, görmezden geldiğimiz ve başkalarıyla paylaşmak istediğimiz proje dosyası değişiklikleri olmadıkça teslim etmediğimiz proje dosyalarının değişiklik listesine sahip olmaya alıştık. Ancak Git ile, gerçek güç (keşfettiğimiz şeyden) teşvik ettiği sürekli dallanma gibi görünüyor ve dallar arasında geçiş, her zaman değiştirilen proje dosyalarıyla bir acıdır. Genellikle değişiklikler bir şekilde birleştirilebilir ve şimdi yeni şubeye uygulanmakta olan proje dosyası değişiklikleriyle uğraşmaya çalışır. Ancak, yeni şube proje dosyalarını değiştirdiyse (şube henüz diğer şubelerde olmayan yeni bir modül üzerinde çalışıyorsa) git sadece yapmadığı bir hata atar ' t Hem şube hem de yerel olarak değişiklikleriniz olduğunda dosyalarda birleştirmek için herhangi bir anlam ifade etmeyin ve ben onun amacını anlayabiliyorum. Komut satırından, "git checkout" komutundaki "-f" komutunu yerel değişiklikleri atmaya ve dalın yerine kullanmaya zorlamak için kullanılabilir, ancak (1) IDEA'daki Git Checkout GUI komutu (10.5.1) bulabileceğimiz bir seçenek olarak görünmüyor, bu yüzden komut satırına düzenli olarak geçmemiz gerekecek ve (2) Bunu kullanma alışkanlığımızda olmak istediğimizden emin değiliz bayrak ve Git'e yerel değişikliklerimizi atmasını söyler.

Yani, bununla başa çıkmak zorunda olduğumuz seçenekler hakkında bazı düşüncelerimiz var:

  1. Proje dosyalarını tamamen kaynak denetiminden çıkarın. Onları .gitignore'a koyun ve belki başka bir yolla veya başka isimler altında kaynak kontrolüne koyarak başka bir yolla her bir kişiye ve TeamCity'ye dağıtın. Ekibimiz yeterince küçük bu seçenek göz önünde bulundurulması mümkün, ancak harika görünmüyor.
  2. Belirli bir zamanda hangi dallarda hangi dosyalara sahip olduğumuzu yönetmeye çalışarak, onunla yaşamaya devam edin. Bunun bir parçası olarak, her geliştiriciyi sistemlerindeki her projenin birden fazla kopyasına sahip olmaya teşvik edebiliriz, böylece her biri muhtemelen farklı proje dosyaları kümeleriyle farklı bir şubeye teslim edilebilir.
  3. Kaynak denetiminde değil, modül (.iml) dosyaları ve .gitignore dosyasında sadece proje (.ipr) olmasını deneyin. Düzenli olarak .ipr'de kendi kendine dolaşan ana şey, paylaşılan derleme yapılandırmalarının sırasıdır, ancak belki bunları nasıl kuracağımızla ilgili bilgileri ayrı olarak paylaşabiliriz. IDEA'nın özellikle yeni bir kasada, dosyalarından bazılarına sahip olmanın nasıl bir şeyle uğraştığından emin değilim.

Sanırım kaçırdığımız bazı bariz (veya aşikar olmayan) bir çözüm olduğunu umuyorum, belki de Git ve IDEA'nın sahip olduğu büyük özelleştirilebilirlikle ilgileniyorlar. Ama öyle görünüyor ki, bu sorunu yaşayan tek ekip biz olamayız. Stack Overflow'da benzer olan sorular 3495191 , 1000512 ve 3873872'yi içerir , ancak tam olarak aynı sorun oldukları için bilmiyorum ve belki birileri çeşitli yaklaşımlar için artıları ve eksileri ile gelebilir ana hatlarıyla, bu soruların cevaplarında listelenen yaklaşımlar veya önerdikleri yaklaşımlar.



Aşağıdaki cevap iyi bir temel olarak gitignore.io sağladı. Bundan üç yıl sonra bile yararlı buldum: gitignore.io/api/java,android,eclipse,intellij
WernerCD

Bahsettiğim IDEA sorununun youtrack.jetbrains.com/issue/IDEA-64312 IntelliJ IDEA 14'te sabit olarak işaretlendiğini unutmayın, bu nedenle en son sürümü kullanan ve dosyaları kaynak kontrolünde tutmak isteyenler şimdi daha iyi bir zamana sahip olabilir bu soruyu gönderdiğim zamandan daha fazla.

Yanıtlar:


48

IDEA'nın, ayarların .ipr dosyası yerine .idea dizininde depolandığı dizin tabanlı proje yapısını kullanabilirsiniz . Sürüm kontrolünde depolananlar üzerinde daha hassas kontrol sağlar. .İml dosyaları hala etrafında olacak, bu yüzden bunlardaki rastgele değişiklikleri çözmez (belki onları kaynak kontrolünden uzak tutar mı?), Ancak kod stili ve denetim profilleri gibi şeyleri paylaşmak kolaydır, çünkü her biri kendi dosyasında .idea dizini altında.


Dizin tabanlı yapıya geçmek kesinlikle çok yardımcı oldu. .İml dosyalarını kaynak kontrolünden çıkardık, bu da IDEA'yı ilk kez kontrol ederken biraz karışık hale getirdi, ancak şimdilik en iyi uzlaşma gibi görünüyor. Ayrıca TeamCity denetimlerinin Maven dosyasından ve dışa aktarılan denetimler profilinden çıkarılması gerekiyordu, ancak bunu da yaptık. Teşekkür ederim!

Bağlantı koptu. Orijinal içeriğin ne olduğundan emin değilim, ancak burada IDEA'nın proje yapısı ile ilgili bir dokümanın bağlantısı var. Ve işte bu özel konuyla ilgili başka bir bağlantı.
Ben.12

31

Resmi DOC'tan: http://devnet.jetbrains.com/docs/DOC-1186

IntelliJ IDEA proje biçimine (.ipr dosya tabanlı veya .idea dizin tabanlı) bağlı olarak, aşağıdaki IntelliJ IDEA proje dosyalarını sürüm denetimi altına koymalısınız:

.ipr dosya tabanlı biçim

Proje .ipr dosyasını ve tüm .iml modül dosyalarını paylaşın .iws dosyasını kullanıcıya özel ayarları sakladığından paylaşmayın.

.idea dizin tabanlı biçim

Kullanıcıya özgü ayarları saklayan workspace.xml ve task.xml dosyaları dışında .idea dizini altındaki tüm dosyaları proje kökünde paylaşın .iml modül dosyalarını da paylaşın.

Bunu .gitignore'uma koydum:

#Project
workspace.xml
tasks.xml

8
Evet ve soruda söylediğim gibi .ipws değil .ipr ve .iml paylaştık. Sorun youtrack.jetbrains.com/issue/IDEA-64312'de .iml dosyalarının her zaman değişmesi ve sık sık çatışmalara neden olması sorunudur. IDiml dosyaları Maven POM'dan yeniden oluşturduğundan ve daha sonra diğer geliştiricilerle çatışma olmadan yerel olarak değişmeye devam edebildikleri için .iml dosyalarını kaynak kontrolünün dışında tutmak bizim için daha iyi çalışıyor gibi görünüyor. Teşekkürler!

Bu yaklaşımla, bazı kaynak adlarında sorun yaşıyoruz, örneğin: Android JDK sürümleri. Ekibimizin bazı üyelerinin yapılandırılmış SDK'dan farklı adları veya farklı sürümleri var. Repo için proje dosyaları göndermek, bu tür şeyleri ekibinizle hizalamanız gerekir. Düne kadar proje dosyalarını repoya göndermek için kullanılmadık, ancak zorlaşıyor çünkü projemiz büyük ve yapılandırılması zorlaşıyor.
Felipe

Kullanılmış SDK'ları ve göreli yolları birleştirmek basit ve etkili bir çözümdür
Kumait

1
Evet. Şimdi tüm modüllerimiz "SDK Projesi" ne işaret ediyor ve aynı SDK'yı kullanmak için ekiple hizalanıyoruz. En azından değiştirilecek tek yer. Ancak IntelliJ daha iyisini yapabilirdi.
Felipe

23

Bir resmi cevap kullanılabilir . Modern (ve şimdi varsayılan) .ideaklasör proje biçimini kullandığınızı varsayarsak :

  • Her şeyi ekle ...
  • Dışında .idea/workspace.xml(kullanıcıya özgü)
  • Dışında .idea/tasks.xml(kullanıcıya özgü)
  • Parola / anahtar / vb. İçerebilecek diğer bazı dosyalar hariç (ayrıntılar için yukarıdaki bağlantıya bakın)

Bu örnek .gitignore dosyası yararlı bir referans olabilir, ancak yine de bu girişlerin neden göründüğünü anlamak ve ihtiyacınız olup olmadığına karar vermek için yukarıdaki bağlantıyı okumalısınız.

Şahsen ben de .idea/find.xmlbir arama işlemi her yaptığınızda değişiyor gibi dosyayı görmezden .


1
"örnek gitignore dosyası" bağlantısına dayanarak, bir adım daha ileri götürür ve bunu sağladığınıza sevindim. temel adrese gidin ve "tam" bir gitignore elde etmek için farklı türleri birleştirebilirsiniz. Açıkça Java, Android, Eclipse, IntelliJ kullanan Android projem için: gitignore.io/api/java,android,eclipse,intellij
WernerCD 19:14

16

Workspace.xml dosyasını kaynak denetiminden aldım (+ .gitignore öğesine eklendi).


10

Ekibimiz yola özgü IntelliJ dosyalarını kontrol etmiyor. İnsanların IDE'yi nasıl kullanacaklarını bildiklerini ve bir proje kurduklarını varsayıyoruz. IntelliJ dosyaları 'yok sayıldı' değişiklik listesine girer.

GÜNCELLEME:

Maven ve varsayılan dizin yapısını kullandığım için artık cevap daha kolay.

IntelliJ tüm dosyaları görmezden sorulmalıdır /.svn, /.ideave /targetklasörleri. Bireyin yol bilgisiyle ilgili her şey saklanır /.idea.

Diğer her şey Subversion veya Git'e bağlı olmak için adil bir oyundur.


14
Projeyi kurmak, sık sık gerçekleşmediği için çok önemli değildir, ancak ekran görüntülerini veya başka bir şeyi e-postayla göndermeye gerek kalmadan derleme yapılandırmaları ve denetleme profillerini paylaşmak çok kullanışlıdır.

1
Bireyin yoluna bağımlı olmayan şeyleri kontrol edin.
duffymo

2

Ekibimin kullandığı başka bir yaklaşımı paylaşmak için: IDE ile ilgili dosyaları IntelliJ'in tanımadığı farklı bir konuma taşıyın ve bunları GIT tarafından yok sayılan 'etkin' konuma kopyalamak için bir komut dosyası oluşturun.

Bu yaklaşımın avantajı, IDE ayarlarını sürüm kontrolü yoluyla paylaşma seçeneğini korumanızdır. Tek dezavantajı, komut dosyasının ne zaman çalıştırılacağına (muhtemelen çalışma alanı klonu başına bir kez veya değişiklikler istendiğinde) karar vermeniz ve komut dosyasını oluşturma işleminize veya birleştirme sonrası kancanıza dahil ederek bunu otomatikleştirebilirsiniz.

Bu yaklaşım, IntelliJ'nin ayar dosyaları için yalnızca belirli konumları aradığına dayanır, bu nedenle çerçeve yapılandırma dosyalarıyla da uygulanır. Aslında Grails .properties dosyasını aynı şekilde görmezden geldik, bu nedenle geliştiriciler yanlışlıkla yerel yapılandırma değişikliklerini iade etmeyecekler.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.