The document provides instructions on how to use Git and GitHub for version control and collaboration. It begins with an example scenario that illustrates issues with sharing code between developers without proper version control. It then introduces Git as a version control system that allows tracking changes to code through branches and commits. The document walks through setting up GitHub accounts and repositories, making commits locally and pushing them to a remote repository, and collaborating through pull requests. It also demonstrates common Git commands like cloning, branching, adding/committing, and pushing.
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
3DC Intro to Git Workshop
1. How to Git gud
3DC 29th May 2023
Thank you Zayne for the workshop name
Count the total number of cats
in this presentation! Github
logos don’t count
4. Imagine this scenario…
A B C
Has the project code
v0 v1 v0
Finished Feature 1! Still working on Feature 2…
5. Imagine this scenario…
A B C
Has the project code
v1 v1 v0
Finished Feature 1! Still working on Feature
2…
v0 v1
6. Imagine this scenario…
A B C
Has the project code
v1 v1 v2
Finished Feature 1! Just finished Feature 2!
v1 v1
Merge over
7. Imagine this scenario…
B’s Code C’s Code
v1 v2
const x = 80;
const y = 200;
//B’s new code
const z = y + x;
const x = 80;
const y = 200;
//C’s new code
const z = y - x;
Merge
Conflict!
8. Imagine this scenario…
Merged Code? v3
const x = 80;
const y = 200;
const z = y + x; // from B
const w = y - x; // from C A B C
v1 v1 v3
9. Imagine this scenario…
Merged Code? v3
const x = 80;
const y = 200;
const z = y + x; // from B
const w = y - x; // from C A B C
v3 v3 v3
Was
working on
Feature 3 on
v1
Was
working on
Feature 4 on
v1
v4 v5
10. ● Multiple versions of the code are in circulation
● Back and forth sending of repositories to ensure everyone is
on the same page
● Merge conflicts
● Without proper communication, changes made to the code
are unknown to other developers
The issues:
Scenario was loosely inspired by this
11. ● Centralised Repository: Stores the source code and all
updates made to the code. Developers pull from this
centralised repository whenever it is updated so they are
kept on the same page
● Version tracking: Code changes are tracked. Developers
can switch between different versions if needed
● Branches: Multiple developers can implement different
features on the same code in separate branches, before
combining them back into the main branch to resolve
conflicts.
Introducing: Git
A version control system
13. Visual Git Diagram
Centralised
Repository
B creates Branch 1
from the repo and
develops Feature 1 on
that branch
A
B C
Branch 1
C creates Branch 2
from the repo and
develops Feature 2 on
that branch
Branch 2
Main
Branch
Simplified
14. Visual Git Diagram
Centralised
Repository
When B is done, they
push their branch to
main branch in the
repo, hence updating
it
with B’s changes
A
B C
Branch 1 Branch 2
Main
Branch
Simplified
15. Visual Git Diagram
Centralised
Repository
A
B C
Branch 2
Main Branch
(with B’s code)
Simplified
C pulls the updated code
from the main branch into
their own branch. Git will
notify C if there is a
conflict and guide them in
resolving the conflict
16. Visual Git Diagram
Centralised
Repository
A
B C
Branch 2 (with
B and C’s code)
Main Branch (with
B’s and C’s code)
Simplified
When C is done, they
push their branch to
main branch in the
repo, hence updating
it
with C’s changes
While C is still working, A and B can also create their own
separate branches first to work on other features
(Features 3 and 4 in the previous scenario!)
17. ● Kind of like Google Cloud for repositories with
✨extra features✨ for collaboration
● Showcase the projects you have worked on (your
developer portfolio essentially)
● Platform for many open-source projects
An online platform owned by Microsoft
What’s Github then?
18. Let’s start!
What you’ll need:
● A Github account
● Github Desktop
● Git installed on your OS (optional)
19. 1.Go to github.com
2.Click on Sign up (or
Sign in if you have an
account)
3.Create your account
4.Profit!
Github Account
1.Go to
desktop.github.com/
2.Download the
application for your
OS
3.Sign in to your Github
account in the app
4.Profit!
Github Desktop
1.Go to git-
scm.com/download/
2.Choose your OS and
download
3.Open terminal/Command
Prompt
4.Type in the following
commands
Git
git config --global user.name "[Your name]"
git config --global user.email "[Your email]"
21. Creating a repository
https://github.com/new
Name your repository! (No
spaces)
Set your repository as
Private (I mean, you can set
it to Public if you want)
Check the box
next to add a
README file
22. README? README!
●A README file is sort of like a
landing page for your
repository on Github
●Usually contains a
description of your project,
documentation of the code,
and instructions on how to
install and run the code
●Written in Markdown
23. ● Click on the README.md file in your
repository
● Click on the pencil icon at the right
hand corner to edit
● Type anything that you would like to
showcase on your repository!
● There are different ways to style
your text in Markdown (see right!)
Let’s edit our README page!
# Heading level 1
## Heading level 2
**Bold text**
*Italicised text*
> Here is a blockquote
`Here is some code`
https://www.markdownguide.org/ba
sic-syntax/
24. ● A commit signifies a change in a
code
● Edit the code → make a commit →
push the commit into the
centralised repo
● Usually you commit after
implementing a feature
● You can create multiple commits
before pushing all of them to the
repo!
● If we commit directly on Github, the
commit is also automatically pushed
Committing (Not to a relationship)
Good commit messages are:
●Concise
●Clear and specific
25. Now let’s explore the rest of Github
Congrats on making your first commit!
https://github.com/rappleit/routourist
(Totally not a shameless plug)
26. ● Create a new repository
● Name the repository with
your Github username
● Update the README.md
file!
● You can search online for
widgets such as Github
statistics
Bonus: Editing your profile on
README
29. Common Workflow
main/master repo
Project
Owner /Team
Lead
Developers fork and
clone the main repo
to create a local copy
on their computer
This is usually the workflow
for open-source projects!
30. Common Workflow
main/master repo
branch 1
in forked repo
branch 2
in forked repo
branch 3
in forked repo
branch 4
in forked repo
Project
Owner /Team
Lead
Developers then create
different branches in their
forked repos and start
working on their features
They then stage their
files and commit into
those branches
31. Common Workflow
main/master repo
Project
Owner /Team
Lead
Developers create a pull
request: A request to the
project owner to pull the
code from the branch in their
forked repo
branch 1
in forked repo
branch 2
in forked repo
branch 3
in forked repo
branch 4
in forked repo
32. Common Workflow
main/master repo
branch 1 branch 2 branch 3 branch 4
Project
Owner /Team
Lead
If everything’s ok, the
project owner will merge
the developers’ branch into
the main repo
34. ● The previous example is a common workflow for open-source
projects (developers are not listed as collaborators)
● For projects where the developers are collaborators, they
can work directly on the original repo without forking it
● Rather, they create a branch on the original repo itself and
commit their changes to said branch, and the project owner
reviews then merges that branch
Note:
35. ● You are a developer working on a project
● …With 30+ other developers, who are also working on the
same project
● You are tasked with implementing one feature for the
project (a simple change to the code will suffice)
● The project: https://github.com/rappleit/3dc-github-
workshop
● We will be using Github Desktop
The scenario:
Time for some action
36. Step 1: Fork the repo!
Forking creates an isolated copy of the original repo for
yourself
37. Step 2: Clone the forked repo
Cloning creates a local copy of the repo onto your computer
38. Step 3: Create a new branch
You’ll be working on the new feature in this branch
39. Step 4: Start editing the code!
Here’s a quick guide:
Choose between cat1,
cat2, cat3, cat4 or cat5
40. Step 5: Stage, Commit and Push
Staging marks the files that you plan to commit. Github
Desktop helps with the staging so you don’t need to do it
manually
41. Step 6: Make a pull request!
A pull request is a request to the project owner to “pull”
the code from your repo into the original repo!
42. Live Demo of The
Merge™
Merging your pull requests into the main
repository!
44. Using git commands
So you can flex on everyone who
uses Github Desktop ✨
Fork this project:
45. Step 0: Setting up
Open the terminal/command prompt. Make sure you are in the
folder that you would like to clone the repo to.
cd [folder name]
cd ..
Move into the directory
Move up a directory
46. Step 1: Clone the repo
git clone [repo url]
You don’t need to do this since you already have the cloned
repo on your computer
47. Step 2: Create a new branch
git branch [branch name]
git checkout [branch name]
Create a new branch
Switch to working in this branch
instead of main
48. Step 3: Start editing!
Choose between cat1,
cat2, cat3, cat4 or cat5
49. Step 4: Stage, Commit, and Push
git add . Stages all changed files
git commit -m “[message]” Create a commit with a
message
git push origin [branch name] Pushes the commit to the
branch on Github
51. Fetching and pulling
git remote add upstream [original repo url]
git pull upstream
git checkout main
Switch to the main branch
Add original repo as the upstream repo
Fetch the original repo and merge it with your local main branch