...
Now the pull request is opened for review and collaborators may log in to GitHub to comment, decline or accept the pull request. When a pull request is created, the related JIRA issues are automatically transitioned into the status Waiting for Review to indicate that a review process has been started. If the pull request is accepted, then the code will be merged to the target branch and the related JIRA issues are automatically transitioned into the status Merged with Development. If the pull request is closed, i.e. declined, then the corresponding JIRA issues are transitioned back to their implementation status.
Once the pull request has been merged with development, make sure to update your local copy of the Git repository:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
$ git checkout development
$ git pull origin development |
Forks
Working with forks is quite similar to the branching approach above. Basically, the entire repository is copied (forked) to another project or profile in GitHub. Developers work directly towards the fork in any way they prefer and once code needs to be merged back into the original repository a pull request is created. To create a pull request based on a fork, click on the link compare across forks when creating the pull request:
A fork workflow is suitable for people outside of the involved organisations. The fork workflow means less branches in the original repository at the cost of not being able to view all branches and their progressions directly from the repository.
Once the pull request has been merged, the fork needs to be updated. See Configuring a remote for a fork and Syncing a fork for details on how to do this.