6. DVCS: Distributed Version Control System
Example: Git, Mercurial
CVCS: Centralized Version Control System
Example: CVS, Perforce, SVN
DVCS vs CVCS
TU Tran(skype: tranthanhtu83, mail: contact@tranthanhtu.vn)
14. - Scenario:
- Develop should not impact to others during implementing
their tasks/ features
- Solution:
- Create new branch from develop
- Implement your feature there
- Merge back to develop when completed
Branching Model/ Feature branch
TU Tran(skype: tranthanhtu83, mail: contact@tranthanhtu.vn)
15. - Scenario:
- Completed features need to be tested before delivering to
customer
- Other develops can continue on other features in parallel
- Solution:
- Create new branch from develop
- Test your complemented features and fix bugs
- Merge to master, develop branches when ready for new release
Branching Model/ Release branch
TU Tran(skype: tranthanhtu83, mail: contact@tranthanhtu.vn)
16. - Scenario:
- We found bugs on production need to be fixed SAP
- Solution:
- Create new branch from master
- Fix bugs and re-test on staging
- Merge to master, develop branches
Branching Model/ Hotfix branch
TU Tran(skype: tranthanhtu83, mail: contact@tranthanhtu.vn)
17. - Scenario:
- We need to maintain code of each version at the same time
- Solution:
- Create new tag when release new version to customer
Branching Model/ Tagging
TU Tran(skype: tranthanhtu83, mail: contact@tranthanhtu.vn)
Source control helps us share works between members
2 types: Centralized and distributed
Easy to commit the mistake into central repo
Can not work offline
Commit unfinished feature into remote and break others in the team work on the same branch => Hard to co-operate with others
Can work offline, commit local unfinished feature
Push to remote only when finish the feature
Rollback on local
Avoid breaking others
Fast: Commit, reverse, diff on local
Which become common today and why?
- Work on the same folder
- New code from new branch will replace old code
Gitflow tool
Local vs remote
Add more remote source
Team have many members
1 members can break others by typo mistake
It can be future feature, not release at the moment
-> Each member need to have their own work space
Delete feature branch when complete
We should only have a few members working on this
Explain why we need to merge back to develop
Suitable for minor bugs
Create new branch for big bugs? Or missing features???
Issue found in old version of release , old tag??
If having release branch, merge to release branch instead of develop
Can not change code of tag
Update version of tag when do the hotfix
Do hotfix on version 1.0, will we update to other release (2.0, …)
Explain each and when we need it
- Do we need to push feature branch to remote
- How long should we merge from dev to feature