View on GitHub

Github development flow

github, git, development

Download this project as a .zip file Download this project as a tar.gz file

Github development flow

Here is the development flow which I use to work through github. There are 2 main branches in github: master and dev .

master is a stable branch ready for the release at any time. dev is a branch that team works on till next update.

So at the beginning master and dev branches are the same.

1) If developer wants to start a new feature / fix, he should switch to dev branch and get the latest version:

git checkout dev
git pull origin dev

2) E.g., we want to start login page bugfix. In github an issue number is #1234. In this case we should create a new branch from dev branch.

git checkout -b 1234-bug-login

bug-login is just an example. The first word should be bug or feature. Branch has been created locally.

3) Then developer will work with code locally, make changes, commits etc. Commit messages should contain issue number and technical description:

git add ...list of files...
git commit -m "#1234 changing backbone model url"

4) Development is finished, we need to push changes to github.

git push origin 1234-bug-login

Now changes are in the repository, the developer should merge (rebase) his changes with development changes to be able to merge to dev branch without conflicts. At first we should get the latest copy of dev branch

git checkout dev
git pull origin dev

And then make rebase

git checkout 1234-bug-login
git rebase dev
git push -f origin 1234-bug-login

5) Great! Now changes are in the repository and the developer should Create pull request from 1234-bug-login to dev branch in github. Also developer should post link to issue (#1234) in pull request description.

6) Pull request is done, anyone (~same level) can review it, write comments etc. Comments should be fixed and pushed to 1234-bug-login branch. Pull request will be updated automatically.

7) Sometimes other branches have been merge to dev and 1234-bug-login branch is out of date. In this case the developer just makes rebase and push again.

8) Perfect! If all fixes were done and someone wrote merge it in pull request, developer uses Merge pull request button to merge branch into dev .

Testing

9) Once 1234-bug-login is in dev branch, Jenkins is automatically deploying the latest dev branch to dev server for testing. QA will verify or reopen issue.

10) If pull request is big, developer / lead can deploy 1234-bug-login branch to QA server before merging pull request.

Releasing

11) Before release dev is merging to master branch and deploying to QA server. Testers should make regression testing.

12) If tests passed, deployment to production can be done, otherwise developers should make fixes directly to master branch.

13) E.g., QA found a few bugs which were fixed in master. Next step (after release) is to merge hofixes from master to dev

git checkout master
git pull origin master

git checkout dev
git pull origin dev

git merge master

git push origin dev

That's all. It can sound too complex, but it fits well for any team.