The flow is triangular. Write access to the main branch on Github is restricted to certain committers. Other team members will just have read access to this branch on github. Some teams may also have a protected development branch, used for staging changes so as to protect the main branch from code that may not be fully tested. If your project is using a development branch, developers will pull from it, and do pull requests to it, instead of the using main branch, in the process described below.
Setting Up for the Git Process
Go to the directory where you would like to do your work, and clone the repository.
Git Process for Features
- git checkout main (always start your new feature branch here)
- git pull origin main (make sure you are up to date)
- git checkout -b your-feature-name
- Develop your feature
- Add and commit your changes.
- Push your feature branch. This should be done periodically, even before you are done with your feature, so that you don’t lose your work.
- Test your feature, including Rspec testing. Make any changes necessary to make the tests pass.
- Commit and push your changes again.
- git checkout main (You need to merge in any changes that your colleagues have made in the meantime.)
- git pull origin main
- git checkout your-feature-name
- git merge main (Now, at this point, if anyone has made changes to the same files you changed, you will need to resolve merge conflicts.)
- resolve merge conflicts, if any, and add and commit your changes
- test again to make sure the merge conflict resolution did not break anything
- push your changes
- Do a pull request. The target of the pull request must be the main branch, unless your project is using a development branch.
- Someone will review your code and may request changes.
- Make any necessary changes to the your-feature-name branch and test the result. Then add, commit, and push again.
- Once all required changes have been made, the committer will merge your code.
- Time for a new feature branch!