Git workflow
Our git workflow is based on a slightly modified version of the famous git flow backed with pull request. If you haven’t read this great article, please do so before going further..
There are 2 main, ever living branches: dev and release.
- dev is the ever evolving development branch
- release is the stable branch deployed in the various environment.
Every modification, even the smallest one has to be done on a new branch.
The feature branches have to be forked from dev.
TODO IMAGE
| I want to | Git command | Comment |
|---|---|---|
| create new branch | git checkout -b my_feaure dev |
it's just a branch, no file updated here |
| update remote repository information | git fetch canaltp |
get last change on github/canaltp |
| update file with last update | git rebase canaltp/dev |
get last modification on files |
| Commit |
|
|
| push on remote | git push origin my_feature |
|
| Get latest dev modifications |
|
|
| Pull request | No git command! 😄 |
Every dev should have his own github repository. It reduces the potential mistakes as almost all changes on the central repository are done via pull request and helps keeping clean the history of the central repository.
By convention we use origin as our personal repository and canaltp (or upstream) as the central one.
|bob
TODO IMAGE
For dev purpose, no pushes are done on the central repository. The central modifications are fetched on the central repository and rebased on the local branches. The features are pushed on the personal repository and merged via pull request.
The workflow is:
TODO IMAGE
You can add a new remote in your repository: git remote add <remote_name> <remote_url>
eg: git remove add canaltp [email protected]:CanalTP/navitia.git
your configuration file (.git/config) should contains:
[remote "origin"]
url = [email protected]:bob/navitia.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "canaltp"]
url = [email protected]:CanalTP/navitia.git
fetch = +refs/heads/*:refs/remotes/canaltp/*
Ready to share you work with the amazing worldwide community of navitia? Then you have to choose carefully your commit message.
First, you have to prefix your commit. Here are the different prefix:
- "Doc:"
- "Georef:"
- "Ptref:"
- "Raptor:"
- "Schedules:"
- "Jormungandr:"
- "RT:"
- "Autocomplete:"
- "Ed:"
- "All:" if your code changes all parts
Then, you have to explain with one simple sentence on the same line (no more than 75 characters), what your work will change for the end user.
Then one blank line and a more complete explanation. The complete explanation should be enough to understand the purpose of the pull request. Try to be as precise as possible, it will greatly help the pull request reading!
Thank you!
When you think the feature is complete, you need to fetche the latest modifications on canaltp/dev and pushe the branch on your github repository. Then open a new pull request between the feature branch and canaltp/dev.
A notification is send by github to ask for review and the continuous integration platform build the branch and check if all tests still pass.
Build failed in Jenkins: click on "Details" to see the error.
TODO IMAGE
Build sucess, the branch can bo merged after review.
TODO IMAGE
When the source code in the dev branch reaches a stable point and is ready to be released, the dev branch is merged into the release one.
TODO IMAGE
To help the release process a python script is available in the repository: script_release.py (python script_release.py major|minor|hotfix canaltp)
When a production environment has a serious problem that cannot wait for the next scheduled release, a hotfix can be done.
A hotfix branch branches from the release branch and is merged back in the release AND dev branch.
TODO IMAGE
To ease the hotfix process, the script_release.py can be also used (python script_release.py hotfix)
TODO
Pull request tutorial from github: https://help.github.com/articles/using-pull-requests (we're using the fork & pull model)
Good interactive git tutorial: http://pcottle.github.io/learnGitBranching/