layout | title | permalink | weight | parent | subnav | ||
---|---|---|---|---|---|---|---|
page |
Version Control |
/version-control/ |
6 |
General |
|
For Support & Maintenance
- Refer: GitFlow
For End-End Development projects
- Fork the main project repository
- Create a feature branch and perform work
- Submit a merge request of that feature branch to the main repository for peer review.
- The reviewer reviews - accepts/rejects the merge request.
- Commits should be atomic to the maximum extent possible. If extraneous commits become necessary, they should be in a different branch and rewritten before being merged with any of the main branches.
- Rebase your branches off latest dev before submitting for review or merge. Learn to use git rebase with squashing options.
- No hard-and-fast rules here, but ideally your branches are named after Jira tickets, with the understanding that sometimes you need to submit code that doesn't relate to an existing Jira ticket.
- If you forget and don't name your branch after a ticket, just be sure to reference the ticket in the commit or pull request message.