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.
| 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 |
| update git submodule if needed | git submodule update |
Update the submodules |
| 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.
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:
You can add a new remote in your repository: git remote add <remote_name> <remote_url>
eg: git remote add canaltp https://github.com/CanalTP/navitia.git
your configuration file (.git/config) should contain:
[remote "origin"]
url = [email protected]:bob/navitia.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "canaltp"]
url = https://github.com/CanalTP/navitia.git
fetch = +refs/heads/*:refs/remotes/canaltp/*
Note: A nice trick is to define the canaltp remote as https and not ssh, this way you need to authenticate to push on the canaltp repository, and thus you cannot do this by mistake
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 prefixes:
- "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 fetch the latest modifications on canaltp/dev and push 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.
Build sucess, the branch can bo merged after review.
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.
!
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.
!
To ease the hotfix process, the script_release.py can be also used (python script_release.py hotfix)
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/