Git 🔀

Jiří Urban, Tomáš Juřička, Stanislav Čermák, Karolína Nesrstová, David Dlugosz, Tomáš Trčka

Commit vs. Push ❓

• Commit
  • Saves repo changes on local repo
• Push
  • Commit + sends changes to remote repo

Fetch vs. Pull ❓

• Fetch
  • Downloads changes from the remote to your local repo
• Pull
  • Fetch + merges them into your current branch

Head 👈

• Pointer to (the latest) commit

Working directory 📁
/ tree / copy

• Dir on local machine where Git repo was cloned or inited
• You can make changes here
• Can be lost when switching branches or pulling changes

Checkout branch ✅

• Switch to a different branch in your repo
• Make it ‘active’ so you can make changes there
   
• Git updates files in your working dir
• Changes are then specific to that branch

Stash changes

• Save changes to the working dir which are not yet committed

• Allow to temporarily switch to another branch

Stage changes

• Preparing changes to be included in the next commit

Git Merge Conflict ⚔️

• Attempt to merge two branches with conflicting changes
• Auto merge fails
• Manually resolve the changes
   
• Can be time-consuming
• Avoid as much as possible

Pull request vs. Merge request ❓

• Same result
• GitHub ~ pull r.
• GitLab ~ merge r.
• Reviewer (approve / reject)

Squash commits

• Combine multiple commits into a single commit
• Cleaner and more organized history

Git merge vs. rebase

• Both solve the same problem (forked commit history)
• Integrate changes from one branch into another (but in different ways)

Git merge

• Merge the ‘main’ branch into the feature branch
• Creates new commit in the ‘feature’ branch
• Easier
• Non-destructive operation
• Existing branches aren’t changed
• But: additional merge commit

Git rebase

• Rebase ‘feature’ branch onto ‘main’
• Moves the entire ‘feature’ branch at the end of the ‘main’
• Re-writes the project history
• Creates brand new commits

  for each commit in the original branch

• Much cleaner history

• Linear project history
  without forks

• But: safety + traceability

Git rebase 2 - Safety

• Never rebase on public branches (e. g. ‘main’ onto ‘feature’)

• My ‘main’ diverged from others’ main

• Would have to merge them
  back together

• “Is anyone else looking
  at this branch”?

• If no, you can rebase

Git rebase 3 - Traceability

• Less important
• Loses the context provided by a merge commit
• Can’t see when upstream changes were merged into ‘feature’

Git Flow

• = Branching model (vs. trunk-based workflows)
• Feature branches
• Multiple primary branches
• Longer-lived branches
• Larger commits
• Higher risk of conflicting updates

Branches 🌳
(from start to end of a project)

• Main
  • Formerly ‘Master’ ❓
  • Production-ready code that can be released
• Develop
  • Pre-production code with new features which are being tested

Branches 🎄 (supporting)

• Feature
  • Most common
  • Working on a new feature
  • Based on: Develop
  • Merged to: Develop (after review)
• Release branch
  • Preparing new production releases
  • Finishing touches + minor bugs specific to release
• Hotfix branch
  • Quickly address necessary changes in Main branch
  • Based on: Main
  • Merged to: Main + Develop

Git tag 🏷️

• Label to mark a specific point in the history (e. g. version)

• = Reference to a specific commit

Best practices 🏆
(clean and well-organized)

• Commits small and focused
• Branches to isolate changes
• Meaningful commit messages
• Regular fetch / pull
• Review before merge
• Use tags to mark releases
• Use ‘.gitignore’ file (build artifacts, generated files)
• Use one branching strategy (by all members)

Best practices 2 🎖️

• Do not nest (feature) branches
• Merge (feature) branches as soon as possible

GUI git tools 🛠️

• Sourcetree – free, for WIN and MAC
• GitKraken – cross platform, integrates with GitHub, Bitbucket, GitLab
• GitHub Desktop
• GitLab – web-based git repo manager (DevOps platform, CI/CD, wiki)

• Bitbucket – web-based git repo manager by Atlassian, integrates with Jira, Confluence

• TortoiseGit – Win-based, integrates with Win explorer