Development cycle through Github

Development

I will talk about the development cycle through Github, which I use. He was tested throughout the year on teams of different sizes: 3 - 14 people.

There are 2 main branches: master and dev .
')
master - stable branch, ready to roll out to the production server at any time.

dev is the branch that the command is currently working on.

So, at the beginning of the development of the master and dev branches are identical.



1. When a programmer starts working on a new defect / functionality, he should switch to the dev branch and get its latest version.

git checkout dev git pull origin dev 

2. For example, the developer wants to start correcting the authentication page defect. The error number on Github is 1234. The developer must create a new branch from dev.

 git checkout -b 1234-bug-login 

1234-bug-login is just an example. The first word should be the defect number, the second - bug / feature, and then the problem description.

3. Next, the developer continues to work locally: makes changes, commits, etc. Commit messages should contain an error number and a technical description.

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

4. So, the development is finished, and now you need to send the changes to Github

 git push origin 1234-bug-login 

All changes are now in the repository. After that, the developer needs to update his branch from dev in order to be able to merge it without conflicts.
First you need to get the latest version of the dev branch.

 git checkout dev git pull origin dev 

And then inject all changes that occurred in the dev branch into its branch (1234-bug-login)

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

5. Great! A branch with resolved conflicts in the repository. Now the developer makes the Create Request Request from 1234-bug-login to the dev branch using Github. It is also necessary to place a link to the task (# 1234) in the description of Pull Request.

6. Pull Request sent, any developer can make a code review, write comments, clarifications, etc.
Comments should be corrected and sent to Github in the usual way. Pull Request will update automatically.

7. Sometimes, fixes take some time, and other developers have already merged their branches with dev . In this case there are 2 options:

- The Merge pull request button on Github is active. This means that changes from other developers do not conflict with current changes, and nothing extra needs to be done.

- button Merge pull request is inactive. It is necessary to return to point 4) and re-merge and send the changes from the dev branch to 1234-bug-login .

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

8. Great! All changes are made, and someone wrote a “merge it” comment in Pull Request. It's time to click the Merge pull request button to merge the 1234-bug-login changes into the dev branch.

Testing

9. As soon as 1234-bug-login gets into dev , Jenkins (continuous integration system) automatically updates the dev server from the dev branch. QAs can start testing and, as a result, confirm or rediscover the task.

10. If Pull Request makes a lot of changes, the developer can upload his branch to the qa server with the help of Jenkins for testing by testers.

Release

11. Before updating the production server, you need to add the dev branch to the master . To do this, we create a pull request from dev to master using Github and click Merge pull request , that's all. When performing the preceding paragraphs, there will be no conflicts.

12. If the regression testing is successfully completed, you can update the production server, while taking the last package (the one on which it was tested), and it is installed on the production server.

13. Sometimes QA find errors during regression testing. In this case, corrections are performed according to the standard scheme, except that the branch is created and merged not from dev , but from master . After the release, you need to infuse fixes 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