Banich Lab Tutorial

GitHub Workflow Guide for banich_lab

A practical guide for anyone working in the banich_lab repository. This tutorial explains setup, GitHub concepts, the daily workflow, pull requests, merge preparation, and what to do when multiple people are working on the same code.

Open Repository Download GitHub Desktop Download Git Jump to Daily Workflow
Repository: github.com/jakederosa123/banich_lab
Clone URL: https://github.com/jakederosa123/banich_lab.git

1. What this system is for

This repository is the shared workspace for code and related materials.

Multiple contributors can work safely
Accidental overwrites are reduced
Changes are tracked over time
Reviewed work reaches main
Main idea: GitHub makes it possible for several people to work on the same project without constantly replacing each other’s files.

2. Required setup

Step 1, Create a GitHub account Go to github.com and create an account.
Step 2, Install GitHub Desktop Download it from desktop.github.com, install it, then sign in.
Step 3, Install Git Download Git from git-scm.com/downloads if it is not already installed.
What each tool does

GitHub stores the remote project online.

GitHub Desktop gives you a visual interface for pulling, creating branches, committing, pushing, and opening pull requests.

Git is the version control system underneath everything.

3. Key concepts

RepositoryA project folder stored locally and on GitHub.
LocalThe version on your computer.
RemoteThe version stored on GitHub.
BranchA separate working version of the project.
mainThe official branch of the project.
CommitA saved snapshot of your changes.
PushUpload your commits to GitHub.
PullDownload the latest changes from GitHub.
Pull RequestA request to merge branch work into main.

4. Core rule

Never work directly on main. Always create a branch first, make your changes there, and then submit a pull request.

5. First-time setup

Clone the repository once so you have a local copy on your computer.

1
Open GitHub Desktop

After signing in, choose the option to clone a repository from a URL.

2
Use this repository URL
https://github.com/jakederosa123/banich_lab.git
3
Choose a local folder

Mac example: /Users/yourname/Documents/GitHub/banich_lab

Windows example: C:\Users\yourname\Documents\GitHub\banich_lab

6. Standard and daily workflow

Use this pattern each time you start new work.

  1. Switch to main.
  2. Click Fetch origin.
  3. Click Pull origin if updates are available.
  4. Create a new branch, for example jake-fix-readme.
  5. Edit your files.
  6. Write a clear commit message.
  7. Commit to your branch.
  8. Click Push origin.
  9. Create a pull request on GitHub.
A
Start

Pull the newest version of main, then create a fresh branch.

B
Work

Edit files and commit your changes with a clear description.

C
Submit

Push your branch and open a pull request.

D
After merge

Switch back to main and pull the newest updates.

  1. Push your branch to GitHub.
  2. Open the repository on GitHub.
  3. Click Compare & pull request.
  4. Add a clear title, for example Update README setup instructions.
  5. Add a short description of what changed and why.
  6. Submit the pull request for review.

7. Working on the same file

Two or more people can work on the same repository safely, but coordination matters.

Best practice

  • Each person works on their own branch.
  • Pull the latest main before starting.
  • Merge one pull request at a time.
  • Keep branches focused on one task.

Why conflicts happen

  • Two people edit the same lines in the same file.
  • One branch is behind the newest version of main.
  • Large branches stay open too long.
Important: if two people changed the same exact lines, Git may ask for a manual conflict resolution before the pull request can be merged.

8. Before merging into main

  • Make sure the code runs as expected.
  • Check that the changes are understandable and limited to the intended task.
  • Confirm you did not accidentally include temporary files, hidden files, or unrelated edits.
  • Review the pull request diff before merging.

9. After merging

  1. Switch back to main.
  2. Pull the newest version of main.
  3. Delete the old branch if it is no longer needed.
  4. Create a new branch for the next task.

10. Example folder structure

banich_lab/ ├── README.md ├── scripts/ ├── data_examples/ ├── docs/ └── notes/

11. Naming conventions

Branch names

Use a name like yourname-task or yourname-task-description.

Examples:

  • jake-update-readme
  • marie-fix-data-import
  • kenny-add-plot-function
Commit messages

Use clear descriptions that explain what changed.

Examples:

  • Fix file path in preprocessing script
  • Add example data to docs folder
  • Update README with setup steps

12. Common mistakes to avoid

Do not work on mainAlways create a branch first.
Do not skip pullingStart by updating main.
Do not use vague commitsAvoid messages like stuff or updates.
Do not mix unrelated editsKeep one branch focused on one purpose.

13. Command line version

This is the same workflow using terminal commands.

git clone https://github.com/jakederosa123/banich_lab.git cd banich_lab git checkout main git pull origin main git checkout -b yourname-task git add . git commit -m "Describe changes" git push -u origin yourname-task
What these commands mean

git clone downloads the repository.

cd banich_lab moves into the project folder.

git checkout main switches to the main branch.

git pull origin main downloads the newest changes from GitHub.

git checkout -b yourname-task creates and switches to a new branch.

git add . stages your changes.

git commit -m "Describe changes" saves your changes locally.

git push -u origin yourname-task uploads your branch to GitHub.

14. Quick examples

Example 1, updating a README
  1. Pull main.
  2. Create branch jake-update-readme.
  3. Edit README.md.
  4. Commit with message Update README setup instructions.
  5. Push and open pull request.
Example 2, two people editing different files

Person A works on scripts/analysis.py in one branch. Person B works on docs/setup.md in another branch. Both can open separate pull requests with little risk of conflict.

Example 3, two people editing the same script

Both people should still use separate branches. The first pull request merges into main. The second person should then pull the updated main, update their branch, resolve any conflicts if needed, and then finish the pull request.