Collaboration with Git and Github¶

Madicken Munk

University of Illinois at Urbana-Champaign

Lesson Objectives¶

  • Review git commands
  • Describe individual and collaborative workflows with git
  • Introduce git commands for collaborative workflows
  • Demo of collaborative workflows in practice
  • See additional useful git tips/tricks

Acknowledgements¶

This material is heavily influenced by the previous works of Karthik Ram and James Howison from the previous summer school

Other Resources I have found helpful/fun for git

  • https://git-school.github.io/visualizing-git/
  • https://pcottle.github.io/learnGitBranching/?NODEMO
  • https://allisonhorst.com/git-github
  • https://jvns.ca/blog/2023/11/23/branches-intuition-reality/
  • https://git-scm.com/docs
  • https://swcarpentry.github.io/git-novice/

Workflows with git¶

An Individual Workflow (without a remote)¶

commit, commit, commit .....

madicken@computer: ~/repos/research-code $ git init
Initialized empty Git repository in /Users/madicken/repos/research-code/.git/
madicken@computer: ~/repos/research-code $ git branch -M main
madicken@computer: ~/repos/research-code $ git add README.md
madicken@computer: ~/repos/research-code $ git commit -m 'add readme with code description'
[main (root-commit) 49c9e77] add readme with code description
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

An Individual Workflow (with a remote)¶

commit push, commit commit push, commit push .....

madicken@computer: ~/repos/research-code $ git remote add origin git@github.com:munkm/research-code.git
madicken@computer: ~/repos/research-code $ git push -u origin main 
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 4 threads
Compressing objects: 100% (11/11), done.
Writing objects: 100% (13/13), 8.03 KiB | 4.01 MiB/s, done.
Total 13 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), done.
To github.com:munkm/research-code.git
 * [new branch]      main -> main
Branch 'main' set up to track remote branch 'main' from 'origin' by rebasing.
madicken@computer: ~/repos/research-code $ git add LICENSE
madicken@computer: ~/repos/research-code $ git commit -m 'add BSD-3 license for my code'
[main 6c65ead] add license
 1 file changed, 401 insertions(+)
 create mode 100644 LICENSE
madicken@computer: ~/repos/research-code $ git push

With your code on a remote (like github, gitlab, or an internal server for your lab), your work is easily accessed by peers!

... But what about working with others?¶

Centralized Workflow¶

All members work on the same repository

Centralized Workflow¶

git pull before starting work

Everyone commits to main

git push

If there is no merge conflict, 🙌

Otherwise fix merge conflict, then push

Feature Branching Workflow¶

Members work on the same repository but use individual branches to do feature development

Feature Branching Workflow¶

Create and switch to a branch

Add commits

Push feature branch to GitHub

Start a pull request

Discuss, add more commits, merge

Some important commands for this workflow:

  • git branch
  • git checkout -b <branchname>
  • git push -u origin <branchname>

.. add some more commits

then git push and open a pull request

Pull Requests¶

Pull requests are an excellent tool for fostering code review. If you’re using Github for team projects, you should be using these extensively.

Pull request best practices:¶

A good practice is for someone else to merge your code into master, ensuring two people understand each feature. Sometimes a reviewer may not have merge rights; in these cases the requirement may be an approving review must be given before the feature is merged.

Pull request tip:¶

Using the github interface, you can change the target of a pull request. The default is to the main branch, but it could be another feature branch. This can be used if you want to help develop a feature branch outside of main with a collaborator.

⛔️ Never send a pull request from master 🙅

⛔️ Never send a large pull request without notice 🙅

Forking Workflow¶

In this workflow each collaborator "forks" a copy of the centralized repository. These forks represent individual remote repositories for each collaborator. Collaborators submit pull requests from their forks to the centralized repository.

Forking Workflow¶

Everyone has a fork of a "central" repository

Add commits to feature branches

Push feature branches to individual forks

Send pull-request from feature branch on fork to central repository

Extra Tips:¶

Tip #1: Always git pull before you start new work

Tip #2: Keep branch names descriptive

Tip #3: Generously use branches (but delete them when they're merged or stale)

Tip #4: Use github command line tool (gh) to simplify your workflow

More useful git commands¶

tagging commits¶

branches are special labels that track a series of commits, but what if you want a special name for a particular commit (like when you released a new version of your code)? you can "tag" these

  • git tag -a <tagname> <hash> -- useful for tagging a particular commit farther back in history
  • git tag -a <tagname> -m "tag message" -- this should tag the current commit with a descriptive message
  • git push origin <tagname> -- push a particular tag up to your remote
  • git push origin --tags -- push all of your tags up to your remote

amending a commit¶

Oh no! I made a typo in my commit message!

git commit --amend is useful for both fixing commit messages and for adding in files that were suppoosed to be committed and werent

cherry picking¶

What if you have a commit that really belongs on a different branch? Or in development you fixed a bug that you think should be in its own PR? You can "cherry pick" that commit to a new branch.

git cherry-pick <hash>

undoing changes¶

Reverting vs. Restoring

stashing changes¶

oh no! I started making changes but I'm not on the feature branch I thought I was!

git stash can be used to hide the changes in your working tree and then bring them back out when you're on the appropriate branch

co-authoring changes¶

Have you pair programmed with a friend and come up with a solution together? How do you deal with attribution?

Co-authored-by: NAME <EMAIL> can add multiple authors to a commit.

More resources¶

  • Do you need to version control large files? git lfs and git annex are tools designed to help with this
  • How to undo almost anything with git link
  • Remove sensitive data (like private keys) from a repository link

Exercises¶

Choose one of the following:

  • If you brought a project to work on: open an issue on your repository for something you'd like to improve that's a beginner friendly issue. Describe the issue thoroughly. Then, working in groups at your tables, have a partner fork your project and submit a pull request fixing that issue. Do not merge the pull request today.
  • Consider the design patterns lecture or the packaging and distributing lecture from yesterday. Make a feature branch on your project and add one of these features to your project. Submit a pull request on your project using that branc. Do not merge the pull request today.
In [ ]: