Setup & Core Concepts Version control uses a central 'remote' repository (Bitbucket) and a 'local' copy on your computer to professionally track every change, eliminating chaotic file naming.

Daily Workflow Scientists save work in snapshots called 'commits' and 'push' them to the cloud, creating a secure, auditable history of their research progress.

Branching & Merging 'Branching' creates safe, parallel versions for experiments, which can be 'merged' back into the main protocol once validated, preventing unstable changes to core work.

Collaboration & Quality Control Teams stay synchronised by 'pulling' updates from the central repository, while 'Pull Requests' ensure that changes are reviewed by peers before final integration.

Setup & Core Concepts

1. Bitbucket is the Remote: This is your lab's central, shared 'source of truth' stored in the cloud.
2. SourceTree is the Local Client: It's the visual application on your computer used to interact with your repositories.
3. A Repository (Repo) is the Project Folder: Git tracks every change to every file inside this special folder.
4. Cloning is a One-Time Setup: You 'clone' a remote repo to create your own local copy to work in.
5. Remote vs. Local: The 'remote' (Bitbucket) is for backup and sharing; the 'local' (your PC) is where you do your work.
6. Version Control Replaces Manual Naming: Instead of Protocol_v3_final.docx, you have one file with a complete, accessible history.

Daily Workflow

1. Stage Your Changes: Before saving, you must select specific file changes and add them to the 'staging area'.
2. Commit Your Changes: A 'commit' is a permanent snapshot of the staged files with a descriptive message.
3. Write Clear Commit Messages: Messages should explain why a change was made (e.g., 'Increased PCR annealing temp to 58C for higher specificity').
4. Push to Back Up: 'Pushing' sends your local commits to the remote Bitbucket server, sharing your work and backing it up.
5. Git Tracks Text Best: Git can show line-by-line changes for text files (.txt, .md, .py) but can only track versions of binary files (.docx, .pdf, .jpg).
6. Use LFS for Large Files: Git LFS (Large File Storage) is needed to efficiently manage large binary files like microscope images.

Branching & Merging

1. 'main' is the Stable Branch: The main branch should always contain the validated, official version of your protocol or data.
2. Branches Isolate Work: Create a new branch to test an experimental change without affecting the stable main branch.
3. Checkout to Switch Branches: 'Checking out' or 'switching' a branch changes all the files in your working folder to that branch's version.
4. Merge to Combine: After a successful experiment, you 'merge' your experimental branch back into the main branch to incorporate the changes.
5. Visualise the History: SourceTree shows your branches as a tree, making it easy to see how your research has diverged and merged over time.

Collaboration & Quality Control

1. Pull to Get Updates: 'Pulling' downloads the latest changes from the Bitbucket remote to your local repository, keeping you in sync.
2. Pull Before You Push: Always pull the latest changes from your colleagues before pushing your own work to avoid conflicts.
3. Pull Requests (PRs) are for Review: A PR is a formal request on Bitbucket for a colleague or PI to review your changes before they are merged.
4. Merge Conflicts Happen: A conflict occurs when two people change the same line in the same file; this must be resolved manually.
5. SourceTree Helps Fix Conflicts: SourceTree provides a visual tool to help you choose which changes to keep when resolving a merge conflict.
6. Tags Mark Milestones: Use 'tags' to create a permanent marker for important versions, like v1.0-Submitted or SOP-v2-Approved.

Repository (Repo): A digital folder where Git tracks all files and their revision history.

• Used in context: "I created a new repository on Bitbucket for our lab's SOPs."
• Topic: Setup & Core Concepts

Clone: The action of creating a local copy of a remote repository on your computer.

• Used in context: "To start working, you first need to clone the project repository using SourceTree."
• Topic: Setup & Core Concepts

Commit: The action of saving a snapshot of your staged file changes to the project history.

• Used in context: "After updating the protocol, I made a commit with the message 'Corrected buffer concentration'."
• Topic: Daily Workflow

Push: The action of uploading your local commits to the remote repository (e.g., Bitbucket).

• Used in context: "I need to push my changes so the rest of the lab can see the updated protocol."
• Topic: Daily Workflow

Pull: The action of downloading the latest changes from the remote repository to your local copy.

• Used in context: "Let me pull the latest data before I start my analysis to make sure I'm up to date."
• Topic: Collaboration & Quality Control

Stage: The process of selecting which modified files will be included in the next commit.

• Used in context: "I only changed the methods section, so I will only stage that one file."
• Topic: Daily Workflow

Branch: An independent line of development used to work on new features or experiments without disturbing the main version.

• Used in context: "I'll create a new branch called 'alternative-reagent-test' to document my experiment."
• Topic: Branching & Merging

Merge: The action of combining the changes from one branch into another.

• Used in context: "The experiment on the new branch was successful, so I will merge it back into the main protocol."
• Topic: Branching & Merging

Merge Conflict: An issue that arises when Git is unable to automatically merge changes because two people have edited the same part of a file.

• Used in context: "We both edited the introduction, which caused a merge conflict that we need to resolve."
• Topic: Collaboration & Quality Control

Pull Request (PR): A formal request made on a platform like Bitbucket to merge your changes into another branch, allowing for team review.

• Used in context: "I submitted a pull request so my PI can review and approve the changes to the SOP before it becomes official."
• Topic: Collaboration & Quality Control

The Daily Workflow Cycle: Edit, Stage, Commit, Push

Step 1: Edit Files

• What happens: You make changes to your protocols, analysis scripts, or manuscript drafts in your local repository folder.
• Key indicator: SourceTree shows the modified files under 'Unstaged files'.

Step 2: Stage Changes

• What happens: You review your edits and select the files (or specific lines) that form a single logical change. You move them to the 'Staged files' area.
• Key indicator: The files you want to save now appear in the top 'Staged' panel in SourceTree.
• Common error: Staging unrelated changes together (e.g., a protocol update and a data analysis script in the same commit).

Step 3: Commit Staged Files

• What happens: You write a clear, descriptive commit message and press 'Commit'. This creates a permanent, timestamped snapshot of the staged files in your local history.
• Key indicator: The repository becomes 'clean' again, with no pending changes shown.
• Common error: Writing useless commit messages like 'updated file'. Be specific!

Step 4: Push to Remote

• What happens: You click the 'Push' button to upload your new local commits to the Bitbucket server.
• Key indicator: The push button in SourceTree no longer shows a number indicating pending commits to be pushed.

Topic: Daily Workflow

Branching for a New Experiment

Step 1: Create a New Branch

• What happens: From the main branch, you create a new branch. Give it a descriptive name (e.g., test-new-antibody). You are automatically switched to this new branch.
• Key indicator: The currently checked-out branch name in SourceTree changes to your new branch name.

Step 2: Work on the Experiment

• What happens: You modify protocols, add data, and make commits on this new branch. This work is completely isolated from the main branch.
• Key indicator: SourceTree's history view shows your new commits appearing on the new branch, separate from main.

Step 3: Switch Back to Main

• What happens: You can check out the main branch at any time. Your files will instantly revert to the stable, official versions.
• Key indicator: The branch name in SourceTree is main, and your experimental changes are no longer visible in the files.

Step 4: Merge the Branch

• What happens: Once the experiment is successful, you check out the main branch and then merge your experimental branch into it. The changes are now integrated.
• Key indicator: The commit history in SourceTree shows the experimental branch's commits now connected to the main branch line.
• Common error: Merging an unfinished or failed experiment into main.

Topic: Branching & Merging

❌ MISTAKE: Forgetting to pull before starting work.

• Why it happens: You assume your local copy is up-to-date, but a colleague has pushed new changes to the remote.
• ✅ Instead: Always start your day by pulling from the remote repository to get the latest updates from your team.
• Memory aid: 'Pull before you proceed.'
• Topic: Collaboration & Quality Control

❌ MISTAKE: Committing large binary files (images, PDFs) directly to the repository.

• Why it happens: Git is not designed to handle large files efficiently, which quickly inflates the repository size and slows everything down.
• ✅ Instead: Set up Git LFS (Large File Storage) for your repository. This stores large files separately while keeping a lightweight pointer in the main repo.
• Topic: Daily Workflow

❌ MISTAKE: Working directly on the main branch for experimental changes.

• Why it happens: It seems easier than creating a branch, but it puts the stable, working version of your protocol at risk if your experiment introduces errors.
• ✅ Instead: Always create a new branch for any new piece of work. This keeps your main branch clean and reliable.
• Topic: Branching & Merging

❌ MISTAKE: Writing vague commit messages like 'stuff' or 'updates'.

• Why it happens: It's quick, but it makes the project history useless. No one (including your future self) will know why a change was made.
• ✅ Instead: Write short but descriptive messages in the imperative mood, e.g., 'Update antibody concentration from 1:500 to 1:1000'.
• Topic: Daily Workflow

❌ MISTAKE: Pushing a broken or incomplete protocol.

• Why it happens: You push your work at the end of the day without checking if it's in a stable state, potentially breaking the protocol for your lab mates.
• ✅ Instead: Only push completed, working changes. For collaborative work, use a Pull Request to have someone else review it first.
• Topic: Collaboration & Quality Control