|
|
| Line 1: |
Line 1: |
| − | !IMAGE!Pictures/mh-hg-infographic01.png!/IMAGE!
| + | |
| − | The Unstable branch is where the development happens. This is our working branch, and so we can refer to it as default branch too.
| + | |
| − | The Stable branch is used for official release only.
| + | |
| − |
| + | |
| − | It's just for mainteinance of the current official version. It's rarely used, except in the case of very noticeable bugs that will cause a service release. Any bugfix in the Stable must be merged in Unstable.
| + | |
| − | When the Unstable is ready for the release, it's merged in the Stable and a tag (a sort of bookmark) is created on this exact revision.
| + | |
| − | !IMAGE!Pictures/mh-hg-infographic02.png!/IMAGE!
| + | |
| − | Working on experimental clone for new features in early development is a great comfort for the developer.
| + | |
| − |
| + | |
| − | He doesn't have to keep his code on the local drive since he can commit it immediately.
| + | |
| − |
| + | |
| − | It doesn't matter if the code does not work yet or breaks the app, it is the private playground of the developer.
| + | |
| − | !IMAGE!Pictures/mh-hg-infographic03.png!/IMAGE!
| + | |
| − | To start up a new feature yet unproven or that is unsure how to implement it exactly, or for a big refactor that might make a lot of problems until solved, we will create experimental repos, cloning the main one. One repo for (large) feature.
| + | |
| − | !IMAGE!Pictures/mh-hg-infographic04.png!/IMAGE!
| + | |
| − | Once the developer has something to show, he can communicate with other team members so they can:
| + | |
| − | * clone the experimental repo to a new folder on their local disk
| + | |
| − | * test it
| + | |
| − | * give feedback
| + | |
| − | * perhaps even commit fixes
| + | |
| − | Once a feature is proven to work well enough and accepted by the rest of the team, it can be merged in official unstable branch, where it can be integrated in nighly build version and further finalized (it can now be tested by a broader audience and we will receive bugs reports from them)
| + | |
| − | !IMAGE!Pictures/mh-hg-infographic05.png!/IMAGE!
| + | |
| − | It is also possible that an external programmer, without commit rights on the official repo, make changes on his own personal clone (that he can make public on his own account if he desires).
| + | |
| − |
| + | |
| − | This is a good way to test new team members, where we can accept changes after verifying them. When we trust a new developer, we can give him direct access to official repo.
| + | |
