Git & Collaboration

A separate copy of a project's files where you can experiment without affecting anyone else. It's like saving a draft of a document under a new name and editing it freely: when you're happy, you can merge your version back into the official one.

Grabbing one specific change from somewhere else in the project's history and applying it to where you're working: without bringing along any of the other changes that came around it. It's how teams move a single fix into a place that needs it.

Cloning means copying a project to your own computer so you can work on it locally. Forking means making your own personal copy of someone else's project up on the internet, which you can then change freely and later offer your changes back to the original.

A saved snapshot of your work at a particular moment, with a short note describing what you changed. Each commit is a checkpoint you can come back to. The history of an entire project is just one commit after another, going back to its very first day.

A bookmark that points to the version of the project you're currently looking at. Wherever HEAD is, that's the version of the files sitting on your computer. When you switch branches or jump to an older snapshot, HEAD moves with you.

Combining the work from one branch into another, so the two histories come together. Merging is how a feature that was being built off to the side gets folded back into the main version that everyone uses.

When two branches try to combine, but they both changed the same lines in the same file in different ways. The system can't pick a winner on its own, so it pauses and asks a human to look at the disagreement and decide which version (or which mix of the two) should stay.

A formal proposal that says 'I've finished some work on a side branch: please look at it and let me know if it can be merged into the main version.' It's where teammates leave comments, suggest changes, and finally give the green light to bring the work into the project.

Picking up your work-in-progress and placing it neatly on top of someone else's latest changes, so the project's history stays in a clean straight line. It's a tidier alternative to merging when you want the timeline of changes to read in a simple, linear way.

A private safety log on your computer that quietly records every move you've made: every checkpoint, every branch switch, every reset. If you accidentally throw away a piece of work, the reflog usually still remembers where it was, so you can get it back.

A nickname for a copy of the project that lives somewhere else: usually on a shared server like GitHub. You work locally on your computer, then push your changes to the remote so teammates can see them, and pull from the remote to bring in their latest work.

Two ways to undo a change. Reset rewinds the project's history as if the change never happened: fine in private, but disruptive on a shared branch where teammates have already seen it. Revert leaves the original change in the history and adds a brand-new change on top that cancels it out: safer for shared work.

Mashing several small checkpoints together into a single tidy one before they get merged into the main project. The little 'oops, fixed a typo' and 'tried something' moments disappear, and what's left is one clean, meaningful entry in the history.

A side pocket where you can tuck away unfinished changes for a moment. Useful when you're halfway through one thing and suddenly need to switch to something urgent. You stash your half-done work, deal with the emergency, and then bring your work back exactly as it was.