Typical rules on branches:
- master is always ready to release; develop is used to integrate and test new features
- Development happens in feature branches
- Before pushing to develop, feature branches must be rebased first
- git fetch --all
- git checkout develop && git pull
- git checkout feature && git pull
- git rebase develop # updating other changes done in develop
- git commit
- git checkout develop
- git merge feature #Applying the new feature to develop
- child branches are always rebased, parent branches never!!
- Feature branches MUST be tested and reviewed before merging to master
- Feature branches should be internal (local or in a user repository) to avoid having a dirt tree in the public repository
- bugfixes done in master should be also rebased to develop before merging
- Once develop is ready for merging to master , a TAG/Release must be created
I added some custom rules:
- develop contains the new release developments, so it's not the right place for bugfix
- To avoid having a branch for each sep/issue, secure commits may be done directly on master
- although, having a fork repository for bugfix would allow using pull-request
- previous tagged release can be kept in a separate branch just for backport/maintenance
Files in a git repository can be in various states:
- Untracked: Files in your local repository directory that Git is not tracking changes to and are not in the central repository.
- Tracked: Files that git tracks changes to.
- Unstaged: Tracked files that have had modifications to them but have not yet been staged or committed.
- Staged: Tracked files that have had modifications made to them and have been marked to be included in the next commit
- Committed: Files that git is tracking and that have been included in a local commit that may or may not be included in the central repository.
No comments:
Post a Comment