Git development

Overview

Standard and suggested workflow for developers to contribute to project.

Workflow goals

• Keep full history of commits
• Group feature/fixes together so easy to see related commits
• Have an online/remote backup of coding activity, including feature/fixes etc
• Can roll back feature/fix merges easily

Reasons for chosing Forking flow

• Probably most robust
• common method for larger open source projects
• allows developers to start work without any authorization on main repo
• no need to clean up branches once finished
• cleaner commit history on central repo
• cleaner branch structure on central repo
• is more complex than branching with more steps involved

Protocol - Central repo

• has a master branch = release ready (some call stable or release branch)
• has a development branch = work preparing for next release (some call master branch)
• possible to have feature/fix branches, eg if large long term feature, although most changes will be done on forks and merged into development
• restricted developer access, maybe allow wider access for code reviewers only, pushing restricted to smaller number

Protocol - Each developer forks

• Fork the central repositories development branch
• Can share forked repository with multiple developers, or each have their own and can and use a similar forking flow to merge with each other

Protocol - Developers working on code

• Their fork is set as the remote push/pull repo
• This allows each developer to backup in progress work to online remote, without affecting central repo
• Clone fork to local com
• The central repo gets added by developers as a second remote repo on their local repo (called upstream), so when working locally they have both their fork repo and the central repo as remotes:

git remote add upstream git@bitbucket.org:stb_Working/{repository}.git

• Check remote repos:

git remote -v

• On local repo create a new feature branch, changes are made there:

git checkout -b [name_of_your_new_branch]

• Push feature branch to forked remote:

git push origin [name_of_new_feature_branch]

• Make regular commits to forked repo so work gets safely backed up
• Feature branch does not exist in central repo, only on developers forked remote repo
• Development branch on developers local computer never gets changed by developer, keep it as a clean copy of upstream repo's development branch. Changes to upstream are pulled into local development branch and can be merged into developers feature branch as needed