Giriş
Bu kullanımda sadece iki tane branch tipi var.1. Master branch
2. Feature branch
Açıklaması şöyle.
1. master must always be deployable.
2. all changes made through feature branches (pull-request + merge)
3. rebase to avoid/resolve conflicts; merge in to master
Açıklaması şöyle
If you have participated in open source projects and contributed code, this is definitely not unfamiliar to you. Github has its own unique way, fork, pull request (PR for short), and issue tracking.
First, it will have a remote repository, and then each fork to its own repository. After the development is completed, PR will be sent to the remote repository. If you have any questions You can file an issue, and the person in charge will merge it into the master after approval.
Its core idea is PR and review. The review process is a natural code review process, which can help developers reduce bugs and make the code base more robust. If it is not for the cooperative development of multiple people in the company, I am more inclined to this.
Açıklaması şöyle. Yani ürünün farklı sürümlerini farklı müşterilere vermiyorsam ve ürüne tek bir yerden erişiliyorsa GitHub Flow kullanılabilir. Daha karşık işler için "Git Flow" kullanılabilir
Single version in production simple software
If your code is having only one version in production at all times (i.e. web sites, web services, etc) you may use github-flow. Main reason is that you don't need to complex things for the developer. Once developer finish a feature or finish a bugfix its immediately promoted to production version.
Ben Nasıl Kullandım
Sürüm 5.0, 5.1, 6.0 gibi sürümlere ait yeni branchler açıldı ve bu branchler GitHub Flow gibi kullanıldı. Yani bulunan her hata her bir branch'te ayrı ayrı düzeltildi. Niye Git Flow kullanılmadı ? Bilmiyorum. Çünkü her şey gelip master'a birleşmiyordu
Hiç yorum yok:
Yorum Gönder