3. Git Procedures
We use git-flow by Vincent Driessen as our source code management procedure.
This means in practice we will:
- Use a feature branch for feature development.
When your feature is complete it is merged to develop. - Use the develop branch for ongoing development.
When there is a new release the develop branch is merged to master. - Use our master branch for production releases only.
No development on the master branch, ever.
Feature branches should contain a prefix identifying your project and the issue number as well as 1-3 word description of what the feature is.
For example, a feature on the Helping Hands project could be feature/HH04-login, where feature is the main branch for features, and the specific branch HH04-login is for building the login.
Some projects will also use the feature branch for contain bugfixes but this decision is up to the Lead Mentor. Some people prefer to label bug fixes on their own branch structure. For example: bugfix/HH27-loginvalidation which could represent a bug found in the validation part of the completed login feature.
Use of SourceTree is optional but we recommend it. We suggest using SourceTree for easy and painless Git management because the visual nature of it can be very helpful. Stashes and Gitflow are also automated and visualized.
While many developers seem to have major reservations about using git in the terminal, we think this kind of attitude is limiting to your growth. Whenever you are unwilling to try new things and change your process you stunt yourself. If you are a seasoned developer you will likely already know the best workflow for git for yourself; if you are a new developer however, do give SourceTree a try. Many businesses use it and learning correct usage will stand you well in future.
Deciding to merge branches or rebase them via git generates much heat online. The CodeDoesGood position is that your project will need to come to a consensus one way or the other. This is a decision that the Lead Mentor will make, but we encourage Lead Mentors to talk to their team before making the decision. Recognize that rebasing often causes complicated git issues and as a Lead Mentor if you choose to have your team rebase their branches onto develop it is also your responsibility to help fix any complications that may come up.
In other words: a healthy develop branch is ultimately your responsibility, so be prepared to teach healthy rebasing to your team.
Every commit should be prefaced with the project prefix and ticket number. Once branches are merged to develop this procedure of labelling commit messages this way is extremely helpful for locating commits. Usually we don't need to find specific commits but when a bug is found going through commits to locate where it started is extremely helpful.
Example Commit:
HH04: Added textfield validation to LoginVC