GCWeb git workflow

Fork and merge

How it works

• Rather than everyone working off wet-boew/gcweb repo, every developer should work on their own server-side repo.
• Typically used / seen in the open source community (like projects on GitHub).
• This avoids the situation where everyone is pushing code to the wet-boew/gcweb repo at the same time. Rather developers make changes in their own repo forked from wet-boew/gcweb and when ready, submit a merge request from their own repo to wet-boew/gcweb.

NOTES:

• Forked is nothing more than a server side git clone.
• Typically you’ll have two remotes with this workflow, one for your forked version of wet-boew/gcweb and one for the primary wet-boew/gcweb repo.
  • By convention, yours will be named origin and the primary will be called upstream.
  • Having an upstream means you can keep your copy of the repo up to date with the latest from the primary, while continuing to work on your changes.

Example

• Original repository is created – wet-boew/gcweb.
• Jenny Gen “forks” the wet-boew/gcweb, creating a new, personal / public copy on the server.
• Git clone the newly forked repo to local – private work copy.
• Commit any changes and push to the forked repo, not the original repo.
• Initiate a pull request from the forked repo with the latest changes over to the original repository.
  • Discussion about the branch / changes can also occur as part of this process.
• wet-boew/gcweb repo maintainer pulls branch to be integrated down to local, then merges it into local master branch.
• Maintainer then pushes master up to main centralized repo.

Pros

• Keeps primary repo’s nice n’ clean.
• Limits those who have write access to the upstream repo.

Cons

• More work and slightly more complicated than other workflows.

When should the seasoned Git guru use it?

Any time you plan to contribute to wet-boew/gcweb.