Learning Git and GitHub
Welcome!
GitHub: sign up for an account if you don’t have one yet,
If you are all set, find a recipe that you can cut and paste as text (yes, for food or drinks) to share – doesn’t have to be yours! It’s for a fun little exercise today.
Introduce Yourself In Chat
- Your Name/Group/Pronouns
- What you hope to learn today
- What’s something delicious you have cooked or eaten lately?
Who is this workshop for?
- Those who want a basic understanding of the version control process
- Those who want to understand how open source collaboration works
- Those who need to build a mental model of Git
Our focus today is on concepts
- Intermediate Git is much more about how you do it with the Command Line
Reproducibility and the Research Lifecycle
What is a Repository?
- Centralized files in a folder
- The ability to look back in time (version control)
- Other people can use it
- Recognition for your work
What is Version Control?
Version control is a systematic approach to record changes made in a file, or set of files, over time. This allows you and your collaborators to track the history, see what changed, and recall specific versions later when needed.
Ways we work with version control
- By ourselves (sole developer)
- As a member of a GitHub repository
- As an external collaborator of a GitHub repository
Version Control Workflow (by ourselves)
- Create files in a repository.
- Work on these files, by changing, deleting or adding new content.
- Create a snapshot, aka commit, of the repository at this time.
- User, time, difference compared to last commit, documentation
You probably already do a version of this:
Git is a formal way of tracking changes
- Each version is called a commit
- We only track changes in the file, not save the entire file
- We can revert changes associated with a commit
What’s the diff-erence?
Git only tracks what’s changed between commits (called a diff):
- Lines of code we add (+)
- Lines of code we delete (-)
Diff Example
Diff Example
Exercise: Create a repository and make a commit
- Create README.md
Exercise: Look at a complex commit history
Ways we work in a repository
- By ourselves (sole developer)
- As a member of a GitHub repository
- As an external collaborator of a GitHub repository
Git / GitHub is a way for multiple developers to work together
- Everything we’ve done so far we’ve done by ourselves
- The key with Git/GitHub is that multiple people can work on a repository at once
How do we do this?
- Multiple people can work on their own versions of the code called branches
- Developers can work on different features on the same code
- Needs a reconciliation process (merging via Pull Requests)
Branches are isolated versions of the original repository
Many People Can Work on the Same Code
Exercise: Add a Recipe to our Cookbook Repository!
Everyone is a member of this repository:
Make a Pull Request
- We are going to merge your code changes into the parent branch.
- Usually the main branch.
- This requires careful communication. A pull request is the communication channel.
- After a pull request is made, someone looks over and decides whether to merge.
Exercise: Make a Pull Request
Merging…
- Need to integrate changes in branches together
- This is called a merge
Who’s responsible for merging?
- Repository Owner
- Could be project manager of a group…
- Could be a software engineer…
- Could be a collaborator…
- Depends on a lot of context!
Who’s responsible for merging?
It is an important responsibility
- Check for any possible conflicts that may arise and address them
- Need to ensure that merge doesn’t break things
- Use automated testing to ensure changes don’t break code
This is all dependent on communication
- You need to communicate with other developers which part of the code you’re working on
- Partition out the tasks
- Multiple developers working on the same part of the code can be difficult
Merging Demo
Ways we work in a repository
- By ourselves (sole developer)
- As a member of a GitHub repository
- As an external collaborator of a GitHub repository
GitHub lets you contribute to code, even if you aren’t a member
- You can still contribute to code you don’t own
- Open source is built on collaborations
- You can do this by making a fork of the code
Forks
- Your version of the code is called a fork - it belongs to you
- Like an external branch
- The fork belongs to you
- Can submit your changes to the code through a pull request to the original repository:
Recap of What we did
Hopefully you will now be able to
- Explain the reasons we use repositories
- Explain how version control tracks changes in your work
- Make a branch in a repository
- Make contributions to a repository using pull requests
- Make a fork of a repository that you don’t own
What’s next?
Intermediate Git and GitHub(*): Feb 9, 2026 (1.5 hour workshop)
Making Code Ready for Publication(*): Feb 23, 2026 (1.5 hour workshop)
Package Management for R and Python(*): March 9, 2026 (1.5 hour workshop)
Feedback for today
Additional Resources
https://github.com/fhdsl/cookbook_winter_2026