Git & Github

Practical introduction to version control

 

Slides originally by Felix Grund

Version Control

A system that records changes to a file or set of files over time so that you can recall specific versions later

Why Version Control?

I'm done
changing
InsideFacade

Ok I'll do
my changes
now...

:(

You overwrote
my changes!

Version control systems help us a lot in development. We wouldn't be where we are today without them.

Git

Github

Distributed version control system

Others: SVN, CVS, Mercurial

Hosting service for Git repositories

Others: Bitbucket, GitLab, SourceForge

GitHub is a service for projects that use Git

Git and Github are sometimes confused by but they are two completely different things.

Basic Git Interactions

  • git add: add files to the staging area
  • git commit: add changes from the staging
    area to the local repository
  • git checkout: switch branches or restore files
  • git merge: join development histories

Communicating with remote

Not communicating with remote (only local)

  • git clone: create a local copy of a remote repository
  • git push: update remote repository with changes in local repository
  • git pull: update local repository with changes in remote repository

Left side: needs no connection to hosting service (i.e. no internet)

Right side: needs this connection

Staging Area?

Modified

Staged

Committed

(Unmodified)

Unmodified

Edit files

git add

git commit

In Git, a file is always in one of the following states:

File wasn't changed since the last commit

File was changed since the last commit

Changes to the file were staged

Changes in the staging area were committed to the local repository

Nothing modified

Change files
=> files are modified but not staged

git add src/Math.ts

git add test/Math.spec.ts

=> files are on the stage

git commit -m ...

=> files are committed

All these interactions do not communicate with remote! As long as we don't push they remain local!

Branches

  • Independent line of development
    • You can both work on the same code base in parallel
  • Each branch contains its own staging area, history of commits, etc. (almost like its own repository)
  • Branches can be merged into other branches
    • This will simply put all commits in branch A into the history of branch B

A branch is nothing more than a sequence of commits. When we merge branches we just copy all commits in branch A into the history of branch B

Branches (cont.)

  • Creating a branch and "moving" into it:
    • git checkout -b new_branch
  • ​Pushing local commits to a branch:
    • ​git push
  • ​Merging into a branch
    • ​git checkout base_branch
    • ​​git merge new_branch
    • git push

Sync with Remote

Harry-Local

Sally-Local

Remote
(e.g. Github)

git push origin master

git pull origin master

Name of remote

Name of branch

Pull Requests & Code Reviews

  • Previously: version control system (Git)
  • Now: hosting service (Github)
  • Pull Request:
    • "Please pull the changes (i.e. merge) in my branch into the base branch."
    • Most hosting services offer this feature
  • Code Review:
    • Other developers looking over the changes in a pull request
    • Comments and then approval, request for change, decline (depending on host system)

Merge Conflicts

  • Git is generally very smart with merges
    • But sometimes it cannot know what to do
    • In those cases you need to tell Git what to do
  • Merge conflicts occur when both the target branch and the base branch modified "the same section" of a file
    • In most cases when a file was edited in two branches, Git will be smart enough
    • Otherwise, we have to step in

Anatomy of a merge conflict

Resolving merge conflicts

  • Less confusing than it looks!
  • Edit the file(s) until they look how you want
    • You could pick one of the two changes
    • Or you could write a combination of the two
    • Make sure you delete the markers
  • Add the file(s) and commit
  • You're done!

Issues

  • Comprise requirements for features, bugfixes, tasks, support tickets, etc.
    • Used for separating specifications into smaller units (tasks, user stories, requirements)
    • You can use them for this project (on Github)
  • Should be the starting point for requirements
  • Platforms: JIRA, Github, Bugzilla, etc.

Agile Workflow (simplified)

Issue

Branch

PullRequest

  • What issues would you create from the C1 spec?
  • This is great territory for practicing your development skills and workflows!

Specification
(e.g. in Wiki)

Continuous Integration (CI)

Old 310 issues

Example: issue for the red box in the reference UI

Activity

https://github.students.cs.ubc.ca/CPSC310-2019W-T2/GitTesting

Thank you!

Made with Slides.com