Mesajlarını aradığınız kullanıcı: doganaydin (7)

konu: İlk 'pull request'i ekledim  ; forum:: Projeler Genel
doganaydin #1
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
acehreli:
Ben de öyle anlıyorum ama 'pull request'in kabul edilmesini beklerken bir yandan da çalışmaya devam etmek istendiğinde kişinin github'daki kendi deposuna 'push' etmesi gerekiyor, değil mi?

Küçük parçalarla uğraşmak daha kolay olduğu için bana daha kolay geliyor.

Ali

Not: Aslında ev bilgisayarlarımız arasında bağlantı kurmuş olsak github'daki kişisel depolarımıza da gerek yok. Ama bunun sorunlarıyla uğraşmak yerine github'a teşekkür ediyor ve onlardan yararlanıyoruz. :)
Pull request gönderdiktek sonra diğer commitler de bu pull requestte görünür. Ama dediğiniz gibi küçük parçalarda commit edildiği zaman pull requestlerde de daha rahat çalışılıyor.
konu: İlk 'pull request'i ekledim  ; forum:: Projeler Genel
doganaydin #2
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3566
github için bir ipucu vereyim. Mesela birden fazla sorunu çözmemiz lazım veya farklı kısımlara kod yazmamız lazım, bir sorunu gideren yamayı hazırladınız bitti. Bu yamayı push etmeyin, sadece commit edip bırakın. Daha sonra 2.,3. ve daha sonraki sorunları çözün ve toptan push edin. Böylece pull requestlerde de kolaylık olur, eklediğiniz commit mesajlarını ayırt etmesi de daha kolay olur. Mesela deneme.d dosyasında bir sorunu çözdünüz. commit -m "yazdırma sorunu çözüldü" gibi o dosyada yaptığınız değişikliği commit edin, daha sonra diğerlerini. Çok uzattım ama kısacası her commit işleminden sonra push etmek zorunda değilsiniz :)
konu: git'i Pro Git kitabı ile anlamaya başladım  ; forum:: Projeler Genel
doganaydin #3
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3557
Githubta gördüğünüz pull request sadece bir bilgilendirme. Yani aslında ben size pull request gönderdiğimde ben size mesaj atıyorum "X deposu bak seni güncelledim gel al yamalarını" şeklinde. Sonra X deposu bu requesti kabul ettiğinde Y deposundaki değişiklikleri kendisi çekiyor. Remote eklemek zorunda değilsiniz remote kısayoldur sadece. Yani direk adresler üstünden de işlem yapabilirsiniz. Remote eklerseniz uzun uzun adres yazmak yerine git fetch doganaydin diyebilirsiniz. :)
konu: git'i Pro Git kitabı ile anlamaya başladım  ; forum:: Projeler Genel
doganaydin #4
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3555
Staging area değişen dosyaların sıraya alındığı bölümdür. Ama bu bölüm sadece yereldedir. Yani git add komutuyla eklediğiniz dosyalar githuba eklenmez. Bunun için git commit ve git push komutunu vermelisiniz. Eğer pull request ile çalışacaksanız başkalarını repoya eklemenize gerek yok. Tabii isterseniz eklersiniz fark etmiyor.
Tam olarak olmasa da (a) seçeneği izlemeniz gereken yol. Adım adım:
1-) pull request gönderilir.
2-) Gelen pull requestte yapmanız gereken işlemler gösterilir. Eğer git pull derseniz çakışmaları görmezden gelip gelen pull requesti direk birleştirir. Ama önce git fetch ile pull requesti yerel depoya ekleyip çakışmaları çözdükten sonra birleştirirseniz daha iyi olur. Yoksa program uçabilir.
3-)fetch komutuyla çektiğinizde değişiklikler direk master brancha gelmezler. Başka bir brancha yerleştirilirler. Sonra bu iki branch merge komutuyla birleştirilir. Yani:
a-) X deposu ana depodur. Y ve Z forklanmış halidir.
b-) Y deposu pullrequest gönderir.
c-) X deposu gelen pull requesti fetch ile yerel depoya çeker(Henüz githubtaki depoyu etkilememiştir) Sonra master branch ile pull requesti çektiğimiz branch karşılaştırılır, çakışmalar kontrol edilir, gerekirse düzenlemeler yapılır. İşlemler bittikten sonra hazır hale geldiği düşünülüyorsa bu branch master branch ile birleştirilir.(merge)
d-) Eğer gerekliyse git add komutuyla dosyalar eklenir, sonra bilindik git commit ve git push ile birleştirilmiş X deposu githuba gönderilir. İsterse Y deposu yeni depoyu çekip senkronize edebilir istemezse de sorun değil.
e-) X deposu Y deposundan aldığı değişiklikler ile yoluna devam eder.
konu: Proje Sahibinde Kodlar Barınsın Diğerleri Çatallama İle Edinsin  ; forum:: Projeler turna
doganaydin #5
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3525
Ben genelde üstünde çalışmak istediğim projeleri küçük-büyük çatallarım. Benim projelerim üstünde çalışmak isteyenlere de çatallamasını söylerim. Bana göre çatallama işlemiyle ana kod daha temiz kalıyor. Çünkü diğer kişinin ne şekilde çalıştığını bilemem veya nasıl kod yazabildiğini. Diğer kişi de beni bilemez veya herkesi projeye dahil etmek istemez. Eğer pull requestler sık sık değerlendirilir ve merge edilirlerse sorunsuz bir şekilde ilerliyor.
konu: Proje Sahibinde Kodlar Barınsın Diğerleri Çatallama İle Edinsin  ; forum:: Projeler turna
doganaydin #6
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3511
Mengu on 2011-02-20, 03:20:
acehreli:
Ben bu konuyu anlamış değilim.

Herkesin kendi dalı üzerinde çalışması kavramını anlıyorum. Böylece herkes çok sayıda değişiklik yapıyor ve başkalarını beklemeden adım adım kendi işine devam ediyor.

Ama bir noktada Ahmet Barış'ın çalıştığı konuya ihtiyaç duyunca onun söylediği değişiklikleri pull mu ediyor?

Bu arada Cem kendi başına devam ediyor diyelim. İhtiyacı olunca Ahmet'le Barış'ın hangi kodlarını alıyor?

Proje sahibinin rolü ne? Onun kendi dalı bütün bu olanlardan habersiz mi? Sonunda o her şeyi bir araya mı getiriyor? Karışıklıklar olmuyor mu? :)

Hiçbir fikrim yok! :D

Ali

ustad, soyle aciklayayim:

- icimizde d'yi en iyi bilen sensin, dolayisiyla proje sende.

- kendi repolarimizda yazdigimiz kodu bittikten sonra sana pull request gonderiyoruz.

- sen code review yapiyorsun.

- begendiysen sendeki repoyla birlestiriyorsun, begenmediysen bugun git, yarin gel diyorsun.

saygilar, sevgiler.
Selam, şöyle bir şey de var. Kodlar çatallandığı zaman çatallanan repolarla orjinal reponun ayrı geçmişleri oluyor. Mesela ben a deposunu çatalladığımda a deposunun sahibi değişiklikler yapmaya devam ediyor ama bu değişiklikler benim çatalladığım repoyu etkilemiyor. Daha sonra ben a reposunun asıl sahibine pull request gönderdiğim zaman benim değişikliklerimle asıl repodaki değişiklikler hiç birleştirilmeyecek bir hal alabiliyor. Veya aynı dosya aynı satır üzerinde farklı değişiklikler yapıldıysa repolarda çakışma oluyor ve bu çakışma çözülmeden birleştirme işlemi yapılamıyor, veya zorlamayla eski dosya tamamen siliniyor yerine benim dosyam geliyor bu da asıl dosyada yapılan değişikliklerin tamamen yok olmasına sebep oluyor. Bunu önlemek için basitçe bir geliştirme planı yapılabilir veya bu dilde iyi olan biri ekstradan çakışmaları çözmekle uğraşabilir.( Tabii her yapılacak değişiklikten önce çatallanan reponun orijinal repoyla güncellenmesi gerekli. )
konu: Git kullanımı  ; forum:: Projeler Genel
doganaydin #7
Kullanıcı başlığı: Doğan Aydın
Üye Şub 2011 tarihinden beri · 7 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3387
Git ile bir süre ilgilendim, aktif olarakta kullanıyorum. Hala sorunlarınız varsa bilgim olduğu kadar yardımcı olabilirim.
Özel Karakterler:
Özel sorgulamalar

Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-11-21, 10:58:27 (UTC -08:00)