Once you've made changes to your files, like updating a protocol, you need to save them into your repository's history. This isn't like a normal 'save' in a word processor. With Git, it's a deliberate two-step process: staging and committing.

Think of it like preparing an entry for your official lab notebook. You wouldn't just scribble notes randomly. First, you'd gather the specific results and observations for one experiment. That's staging. Then, you'd write a clear, dated entry explaining what you did. That's committing.

In SourceTree, any file you've edited appears in the 'Unstaged files' pane. Staging is as simple as selecting a file and clicking a button to move it to the 'Staged files' pane. This action tells Git, "This is a change I want to include in my next snapshot."

You can be selective. If you've updated a protocol and also drafted a new results summary, you can stage and commit just the protocol change first. This keeps your project history clean and organised, with each commit representing a single, logical change.

After staging your changes, you write a commit message. This is the most important part of the process for maintaining a clear lab record. It’s the note you write in the margin of your lab book explaining what you did and why.

A good commit message is a short, descriptive summary. It should be clear enough that a colleague, or you in six months, can understand the change without having to look at the files.

Once your message is written, you click 'Commit'. This takes a permanent snapshot of the staged files and saves it to your local repository's history with your message attached. You now have a secure, time-stamped record of that specific change.

Committing saves changes to your computer, but your lab mates can't see them yet. Your local repository is out of sync with the shared remote repository on Bitbucket. To share your work, you need to push.

Pushing uploads all your new, local commits to the remote repository. In SourceTree, this is usually a single button. It's the digital equivalent of placing your updated protocol in the central filing cabinet for everyone to use. It also serves as a crucial backup.

One of the great benefits of this system is seeing exactly what has changed. In SourceTree, you can view the history of any file. For text files like your protocols, it will show you a 'diff'—a side-by-side comparison that highlights every line that was added or removed. This makes reviewing changes incredibly fast and precise.

With this simple workflow—stage, commit, and push—you can build a reliable, auditable trail of your research. Every change is tracked, explained, and safely backed up.