GitNoon Lesson 3

Get Ready for Lesson 3!

  1. Make sure your blog has no uncommitted changes and that you are up to date with origin/main by checking the output of git status
  2. If you missed the previous lesson, ask for help with the quick-setup on the next slide

Quick Setup

  1. Configuring Git:
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
git config --global core.editor nano
git config --global init.defaultBranch main
# For Linux or macOS:
git config --global core.autocrlf input
# For Windows:
git config --global core.autocrlf true
# If you're behind a corporate proxy on Windows
git config --global http.sslBackend schannel
  1. Setting up a blog repository:
mkdir blog
cd blog
git init
echo "# Entry 1" > entry_1.md
git add entry_1.md
git commit -m "Add first blog entry"
git status
  1. Creating a new public blog repository on GitHub, and pushing your local repo to it:
git remote add origin ssh://git@ssh.github.com:443/<username>/blog.git
git push -u origin main

Thanks

  • To the host for the great venue!
  • To our sponsors

Administrivia

  • Fire escapes
  • Toilets
  • Cleaning up after ourselves
  • Wi-Fi

Lunch Talk: Collaboration Workflows

  • Git is a very flexible tool - there are many ways you can collaborate with Git
  • How your team uses Git will be a trade-off between simplicity and requirements
  • We’re going to look at some of the key workflows and concepts

Workflow 1: Single Branch

The simplest option; what we’ve been using so far:

%%{init: { 'gitGraph': {'showCommitLabel': false} } }%%
gitGraph
  commit
  commit
  commit tag: "v1.0.0"
  commit tag: "v1.0.1"
  commit
  commit
  commit
  commit tag: "v1.1.0"

You may like to add annotated tags to mark specific commits as released versions:

git tag -a v1.0.0 -m "Release of version 1.0.0"
# Push tags to the remote
git push origin --tags
# Any command that accepts a commit SHA will accept a tag:
git diff v1.0.0

Collaboration on a Single Branch

%%{init: { 'gitGraph': {'showCommitLabel': false, 'mainBranchName': 'origin/main'} } }%%
gitGraph
  commit
  commit
  commit
  branch main
  checkout main
  commit
  commit

%%{init: { 'gitGraph': {'showCommitLabel': false, 'mainBranchName': 'origin/main'} } }%%
gitGraph
  commit
  commit
  commit
  branch main
  checkout main
  commit
  commit
  checkout origin/main
  commit
  commit

%%{init: { 'gitGraph': {'showCommitLabel': false, 'mainBranchName': 'origin/main'} } }%%
gitGraph
  commit
  commit
  commit
  branch main
  checkout main
  commit
  commit
  checkout origin/main
  commit
  commit
  checkout main
  merge origin/main
  • Clone the remote repo (origin/main)
  • Make commits on your local main branch
  • But what if someone pushes to the remote branch before you?
  • Git won’t let you push your state of the branch, because the latest commits on the remote would be lost
  • First, fetch the latest commits: git fetch
  • Then merge origin/main into your local main: git merge origin/main
  • If both branches changed the same part of the same file, there will be a merge conflict
    • We’ll learn how to resolve these in the tutorial
  • Finally, push the merged branch to the remote: git push origin main
  • This flow might work for a couple of contributors, but it can get messy with bigger teams

Workflow 2: Feature Branches

%%{init: { 'gitGraph': {'showCommitLabel': false} } }%%
gitGraph
  commit tag: "v1.0.0"
  branch 1234-add-birthday-notifications
  branch 5678-fix-mobile-layout
  checkout 1234-add-birthday-notifications
  commit
  commit
  commit
  checkout 5678-fix-mobile-layout
  commit
  checkout main
  merge 5678-fix-mobile-layout tag: "v1.0.1"
  checkout 1234-add-birthday-notifications
  commit
  commit
  checkout main
  merge 1234-add-birthday-notifications tag: "v1.1.0"
  • A new feature branch is made for every task
  • Makes it easy for contributors to work in parallel
    • (or for one person to switch between tasks)
  • Formalised in GitHub Flow

A Typical Pull/Merge Request

  1. Make a feature branch off the latest main
  2. Make commits to your feature branch
  3. Push your feature branch to the remote
    • If you don’t have permission, you’ll need to push to your own fork of the repo
  4. Open a Pull Request / Merge Request
  5. Respond to reviewer feedback and suggestions by pushing more commits
  6. Once the reviewer is happy, they will merge your branch into main
    • If your branch conflicts with main, you will need to rebase your branch (we’ll cover that next lesson)

Workflow 3: Release Branches

%%{init: { 'gitGraph': {'showCommitLabel': false} } }%%
gitGraph
  commit tag: "v1.0.0"
  branch 1234-add-birthday-notifications
  branch v1.0
  checkout 1234-add-birthday-notifications
  commit
  commit
  commit
  checkout v1.0
  commit
  commit tag: "v1.0.1"
  checkout main
  merge v1.0
  checkout 1234-add-birthday-notifications
  checkout main
  merge 1234-add-birthday-notifications tag: "v1.1.0"
  • Useful if you need to support v1.0 while working on new features for v1.1
  • A hotfix on release branch v1.0 is tagged as point release v1.0.1 and merged forward into main.

Environment Branches

Instead of release tags, you might use branches to track which commit is deployed in each environment:

%%{init: { 'gitGraph': {'showCommitLabel': true, 'mainBranchName': 'origin/main'} } }%%
gitGraph
  commit id: " "
  commit id: "  "
  commit id: "prod"
  commit id: "   "
  commit id: "    "
  commit id: "test"
  commit id: "     "
  commit id: "dev"
  commit id: "      "

(continuous deployments could even be triggered by updates to those branches)

Other Workflows

  • GitLab Flow
    • Extends the Feature Branches workflow (i.e. GitHub Flow) with environment branches and process recommendations
  • Git Flow
    • Extends the Release Branches workflow with more branch types
    • Increases complexity, but allows for more process control
  • Octopus Merges
    • Instead of merging into main one-by-one, many feature branches are “octopus merged” to create a release on-demand
    • Allows you to delay deciding which features to include in a release, but risks octopus conflicts!

Other considerations

  • Versioning non-files
    • Database schemas → database migrations
    • Datasets → dvc, dagster
  • Conventions
  • What belongs in the same repo?
    • Usually: different team or project = different repo
    • Some organisations use monorepos
    • Keep docs close to code so they change together
  • Processes
    • Configure branch protection rules
    • Pull request code review checklists
    • Automate checks (e.g. linting, tests) for Continous Integration (CI)
    • Automate deployments for Continous Deployment (CD)

Choosing your Workflow

Adapt your workflow to fit how your team works and the requirements of your project

Document your workflow and reasons for decisions so that everyone understands how the team uses Git!

Tutorial Objectives

  1. Work on a separate branch
  2. Merge your branch into main
  3. Resolve a merge conflict

Homework

  1. Continue your daily blog entries
    • Instead of working directly on main, make each entry in a new branch that you then merge into main