The wiki is now available again. However, some recent changes may not have been restored.
Please see Computing Services' blog post for more details
Skip to end of metadata
Go to start of metadata

Every repo that the team works on should have at least three branches:

  1. production
  2. staging
  3. feature-name

Repo guidelines

(from https://github.com/thoughtbot/guides/tree/master/protocol/git)

  1. Avoid including files in source control that are specific to your development machine or process
  2. Delete local and remote feature branches after merging and acceptance
  3. Perform work in a feature branch
  4. Rebase frequently to incorporate upstream changes
  5. Use a pull request for code reviews (thoughtbot's code review guidelines are good).

How to set up a new repo

  1. Create private repo in digital org with README.md
  2. Remove Wikis and Issues under Settings > Options
  3. Create production and staging branches
  4. Set staging to be the default branch
  5. Delete master branch
  6. Add the Digital team as 'Admin' under Settings > Collaborators and teams
  7. Set the default branch to be protected and require pull request reviews before merging, including administrators

Continuous integration and continuous deployment

We set up a build and deploy of the production branch in Bamboo and then enable plan branches. This means that all new branches will automatically get a build plan created for them.

We use the GitHub Bamboo Service (via repo_page -> Settings -> Webservices & Hooks) to trigger a build each time a commit is made.

Commits to the production and staging branches are automatically deployed by Continuous Integration, provided they pass their unit tests and acceptance tests.

See detailed instructions on how to set this up.

And another thing

Tom has some notes on how to use git on his personal space. Use at own risk!

  • No labels

6 Comments

  1. Unknown User (lm317)

    The words of 4. I understand not.

    1. Unknown User (pgw22)

      Rebasing is where you apply changes that have happened on the branch you based yours on, to your feature branch.

      This makes sure your branch will be OK to merge back in to the source branch easily by making sure your files are all up-to-date.

  2. Questions!

    1) Production/Staging branches - Can we set GHe to default to these instead of automatically creating Master?

    2) The feature branches - How do you name a 'tinker' branch (ie: a branch that you want to mess around with and possibly keep hold of but is not particularly important)

    3) Rebase - can someone explain this to me specifically in relation to Tower. I suspect Tower is doing something like rebase regularly in the background but I'd like to understand what this actually means.

    4) Pull requests are only for production/staging? Or should we be using this for sharing updates between feature branches as well?

    5) Do we have a plan for handling submodules or subtrees in general?

    1. Unknown User (pgw22)

      1. No
      2. I would suggest you fork it into your own space in GitHub Enterprise
      3. It's a button for clicking (smile)
      4. I would suggest not using pull requests between feature branches, I think that way madness lies
      5. No. Usage of them should be sufficiently rare that we should discuss it each time.

       

  3. Unknown User (pgw22)

    More questions:

    1. should we be squashing commits together for a pull request like in http://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/ ? This makes review easier
    2. do we need a clearer set of steps on rebasing, e.g. in circumstances like this: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
    1. Unknown User (pgw22)