GIT ile bir projede çalışan birden fazla kişiyi yönetmek

GIT / GitHub için çok yeniyim (dünden başlayarak yeni). Github ile aynı projede çalışan birden fazla kişiyi yönetmenin en iyi yolunun ne olduğunu bilmek istiyorum. Şu anda dört geliştiricili bir projeyi yönetiyorum.

1. İş akışını nasıl giderim ve her şeyin senkronize olduğundan nasıl emin olurum?

   (Not: Tüm geliştiricilerin tek bir evrensel hesabı olacaktır.)

2. Her geliştiricinin farklı bir dalda olması gerekir mi?

3. Aynı dosya üzerinde çalışan 2 kişiyi idare edebilecek miyim?

Lütfen ayrıntılı bir cevap gönderin, ben utangaç bir okuyucu değilim. Bunu iyi anlamam gerek.

Geliştiricilerin tümü depoya erişime sahipse, özel bir şey yapmanıza gerek yoktur. Depodan değişiklikler yapacaklar, kendi değişikliklerini yapacaklar, yerel olarak iş yapacaklar ve daha sonra bir şeyler yaptıklarında kamuoyuna geri dönecekler.

Öte yandan, repoyu gerçekleştirmekten sorumlu bir (veya birkaç) geliştiriciye sahipseniz ve diğerleri bunlara yamalar sağlıyorsa. Her birinin depoyu kendi hesaplarına klonlamasını ve ana depoda istedikleri değişikliği yaptıklarında istekleri göndermelerini isteyin.

İsterseniz, belirli özellikler üzerinde çalışmak için belirli klonlar yapmak da mümkündür. Özellik yapıldığında ana depoda değişiklik yapmak için çekme istekleriyle aynı iş akışını kullanma.

"Tüm geliştiricilerin tek bir evrensel hesabı olacak" ifadesiyle, tüm geliştiricilerin bir GitHub hesabını paylaşacağı ve depoda aynı müşteri olarak görüneceği anlamına gelirseniz, bu kötü bir fikirdir. Ayrı hesaplar yapın ve hepsinin taahhütte bulunmalarını istiyorsanız, ortak çalışanlar olarak ayarlayın.

Özel sorularınız için:

2. Hayır, birden fazla taahhütte bulunacak özellikler, düzeltmeler vb. İçin dallar kullanın. Aynı dalda birden fazla geliştirici çalışıyor olabilir.

3. Evet, git çatışmaları gerçekten iyi idare ediyor, bu yüzden insanların aynı dosya üzerinde çalışmasını sağlamakta sorun yok. Birden fazla üye tarafından düzenlenen bir dosyada köklü değişiklikler olması durumunda, sorun çözme dışında sorun çözülmesi her zaman önemsiz olmayabilir. Ancak bu, birlikte konuşarak üstesinden gelinemeyecek bir şey değildir. Sürüm kontrolü iletişim yerine geçmez.

İyi şanslar!

2 geliştirici ile çalışıyoruz ve bu iş akışını kullanıyoruz:

• Github'da bir master dalımız ve dev bir dalımız var.
• Ana dal üretim ile aynıdır veya dağıtım hazır kodu içerir
• Dev dalı master'ın önünde ve üzerinde çalışmakta olan tüm yeni kodları içeriyor
• Yerel olarak ikimiz de dev dalı üzerinde çalışıyoruz ve bir şey hazır olduğunda github'a itiyoruz
• Diğer geliştirici, yeni kodunu zorlamadan önce geliştirici dalından yeni değişiklikler alır.
• Dev dal iyi olduğunda, ana dalla birleşiriz.
• Yerel olarak birkaç özellik dalı şubeleri vb. Var.

Burada sadece metin cevapları görüyorum, bu yüzden başlamak için güzel bir gitflow resmi gönderebileceğimi düşündüm. Bir resim binden fazla kelimeyi açıklar:

• Bu akış, Sürekli Dağıtım'da da iyi çalışır.
• Ana şubenizde şu anda üretim sunucunuzda çalışan kod var.
• Geliştirme şubenizde şu anda bir hazırlama / test sunucusunda çalışan kod var.

Diğer 3 geliştiriciyle çalışıyorum ve bununla biraz mücadele ediyoruz. Geliştiriciler bazen, prime hazır olmadıkları için henüz hazır olmayan taahhütleri üretime iteceklerdir, çünkü diğer taahhütleri değişikliklerine çekecek ve daha sonra üretime iteceklerdir. Sürüm dalları bizim için uygun görünüyor. Dolayısıyla, sürüm 1.0 mevcut kararlı sürüm ise, v1.1 geliştirme için bir dal oluşturacağız. Geliştiriciler bu dalda değişiklik yapacaktır. Test sunucumuz bu şubeyi kontrol eder ve gereken değişiklikleri yapar. V1.1 için tüm özellikler kullanıma hazır ve test yapıldığında, v1.1'i master ve push ile birleştireceğiz. Dallarla, geliştirici takım A v1.1 üzerinde çalışabilir ve geliştirici takım B v1.2 üzerinde çalışabilir. Her iki takım da birbirlerini etkilemeden çalışabilir. A takımı B'nin kullanabileceği bir şey geliştirirse,

Ayrıca acil değişiklikler için kullanılan bir düzeltme dalı kullanıyoruz.

İşte bunun neye benzediği ile ilgili bir resim. http://nvie.com/img/git-model@2x.png