Git - Simply Explained

You change one small thing after hours of work, save the file, and suddenly the part that worked yesterday doesn't work anymore. Now you're hunting through folders named Project Final, Project Final Final, and Project Use This One. Git fixes that mess. I'm Mirko Peters from M365, FM, and this knowledge nugget explains Git in plain English. You'll see how it keeps a usable history of your project, how GitHub fits into the picture, and why teams rely on both without copying folders all day. Git is your project history. Git is a version control system. That sounds technical, but the idea is simple. Git keeps a recorded history of a project, so you can see what changed, and return to an earlier point when you need to. Imagine you're building a small website with a login page on Monday the page works. The email box, password box, and sign-in button all look right. Instead of copying the whole folder and calling it "log-in page working", you tell Git "this is a version worth keeping". Git records that point in the project's history. On Tuesday you add a new sign-in option. On Wednesday you change the page layout. By Thursday the button has moved, the page looks wrong on a phone, and you're not sure which edit caused the problem. Without Git you might dig through old folders or try to undo changes by hand. With Git you can look back through the checkpoints and compare the working version with the broken one. You can see which files changed, and often which lines inside those files changed. That makes finding the problem much less like guessing. Those checkpoints have a name and git, they're called "commits". A commit is not every time you press "save in word" or "save a file" in your editor. Git doesn't quietly capture every keystroke you choose when a piece of work deserves a checkpoint. Maybe you fix the login error. Maybe you added the apple sign-in button. Maybe you changed the text on the welcome screen because the old wording confused users. When that piece of work is ready you create a commit and write a short message about it. Something like "add apple sign-in option" or "fix password reset link". That message matters more than people think. Six months later you or someone else can read the project history and understand the reason for a change. Updates and stuff changed don't help much when you're trying to find a bug on a busy Friday afternoon. A good commit covers one clear piece of work. If you change the login page and rebuild the whole navigation menu, those may belong in separate commits. Separate checkpoints make it easier to review work, understand history, and undo one change without touching another. Now many people think git only matters when you work with a team. It helps teams, but it starts with you. Git runs on your computer and keeps its history there. You can create commits while you're offline on a train at home or anywhere else. Nothing needs to go online for Git to record your work. That local first design is easy to miss because people often meet Git through GitHub. But Git and GitHub aren't the same thing. Git is the tool that tracks your project history. GitHub is an online place where people can share that history. We'll get to that shortly, but keep this difference in your head. Git works locally first. Why does Git fit code so well? Code changes in small parts. One line might fix a problem. Another line might create one. Developers need to know who changed a file, what they changed, and when that change entered the project. Git gives you that trail. It can compare one commit with another. It can show a shared history across a team. It can help you return to an earlier version when a new change breaks something that used to work. You can use Git for other kinds of files too, although it works best when it can read and compare text. Code, notes, website files, and settings files all fit naturally. So think of Git as your project's memory, not a magic undo button, and not a coding language. It's a system for creating deliberate, named checkpoints that you can inspect later, but a checkpoint needs somewhere to live on your computer. To understand that part, picture where your work sits before Git turns it into history. The three local areas. Git uses three local places to move a change from active work into recorded history. Think of a normal office. You have your desk where you do your work. You have a review tray where you place the papers ready for filing. Then you have a filing cabinet where approved papers stay as part of the record. Your Git project works in much the same way. The first place is the working directory. That simply means the normal project folder on your computer. It might contain your website files, your notes, your images, and your settings. Your open files there, change them, create new ones, and delete old ones. When you edit the login page in your code editor, you're working in the working directory. This is your desk. It can be messy. That's fine. You might start changing the sign-in button, then notice a spelling mistake in another file. You may create a new file to test an idea, then decide you don't need it. Git doesn't force every change into the project history, just because it happened in this folder. Before you save a checkpoint, you usually want to know what Git can see. That is where a command called GitStatus helps. In plain English, GitStatus asks Git, "What has changed in this project since the last recorded checkpoint?" Git can tell you that a file changed, that a file is new, or that a file has been removed. It can also tell you which changes are ready for the next commit, and which ones are still only sitting on your desk. For a beginner, this command becomes a safety check. If you're unsure where you are, run GitStatus. Imagine you changed the login page, edit a help file, and removed an old image. Before you record anything, GitStatus gives you a simple view of that situation. You don't need to trust your memory. The second place is the staging area. This name confuses many people because it sounds like a technical storage room. Think of it as the review tray beside your desk. You place only the changes you want in your next checkpoint into that tray. Suppose you fixed an error in the password reset link, but you also started an unfinished redesign of the welcome screen. You don't want both changes in one commit, the password fix is ready, the redesign isn't. So you select the password reset file for the staging area. The command for that is GitAdd, followed by the file you want to prepare. Despite the name, GitAdd doesn't permanently save the change. It doesn't send anything online either. It just places a chosen version of that file into the review tray for the next commit. That small pause gives you control. You can check the stage changes, remove something from the staging area if you picked it too early, or add another file if it belongs with the same piece of work. The point is not to stage every change automatically. The point is to decide what this one checkpoint should contain. A useful habit is to keep one commit focused. Fix password reset link is clear. Fix password reset link, change the header, update colors, and clean up random files. Tells a future team made far too much happen at once. Small clear commits are easier to check and easier to undo when something goes wrong. Once the review tray contains the exact changes you want, they move to the third place, the local repository. This is the filing cabinet. The local repository stores your commits and the project history on your computer. Git creates and manages the hidden files that hold that history, so you normally don't need to open or edit them yourself. To create the checkpoint, you use Git commit and write a message. For example, Git commit, M, fix password reset link. That tells Git to take the changes already in the staging area and record them together as one point in the project history. Notice the order. You edit a file in the working directory. You check your situation with Git status. You choose what belongs in the checkpoint with Git ad. Then you record that selected work with Git commit. Nothing in that root requires GitHub, a browser, or an internet connection. Everything so far happens on your own computer. The review tray also explains something beginners often miss. If you change a file after staging it, Git can treat the new edit separately. The staged copy reflects what you selected at that time, while the latest edit remains on your desk until you select it too. It sounds fussy at first. Then you work on a real project with several half-finished changes and it starts to feel practical. Your working directory is where you work. The staging area is where you choose. The local repository is where Git records the choice that gives one person a much safer way to work. But projects also need a safe way to try ideas without disturbing the version everyone trusts. Branches, merges, and conflicts. A commit gives you a safe point in history. A branch gives you a safe place to work on what comes next. Most projects have a branch called main. Think of main as the version of the project the team currently trusts. It holds the work that has already been checked and accepted. You don't always want to change that trusted version directly. Imagine the login page works, but you want to add a sign-in option using a company account. It might take several files. You may need to change the page, add a new button, and update the logic behind it. During that work, some parts may not work yet. You don't want half-finished work mixed into main, so you create a branch. A branch is a separate line of work that begins from the current project version. It isn't a second folder that you keep copying around. Get remembers the shared history, then records only the changes that belong to the new line of work. You might name that branch ad company login. At the start, it looks the same as main because both branches begin at the same commit. Once you start changing files and creating commits, the branch starts building its own history. Your new sign-in button can be unfinished there. You can test ideas, you can change your mind. You can create several commits as the work takes shape. While main keeps showing the version everyone already relies on. That separation matters when more than one person works on the project. One developer can repair a password problem on one branch while another adds company sign-in on another. Neither person needs to wait for the other just to start work. When the company sign-in option works and the team has checked it, you can bring the branch back into main. That action is called a merge. A merge combines the approved changes from one branch into another branch. In this case, Git looks at the work from ad company login and brings the right changes into main. Git can usually do this on its own. For example, if one branch changes the sign-in page and another branch changes a help document, Git can see that those changes don't overlap. It combines them without needing anyone to step in. But sometimes two people change the same part of the same file. Suppose you change the text beside the password field on your branch. At the same time, another person changes that exact text on main, but they choose different wording. Git sees two possible versions. It can't know which wording the team intends to keep because Git understands file changes, not the meaning behind a decision. So it stops the merge and shows a conflict. A conflict doesn't mean the project is broken. It means Git needs a person to make the choice. Your editor will show both versions of the conflicting section. You read them, decide whether to keep yours, keep the other persons, or combine both, then save the final text. After that, you mark the resolved file as ready and create the merge commit. The project history now records the final choice. That is much better than Git guessing and silently deleting somebody's work. Conflicts can feel alarming the first time you see them, but they are Git being careful. You still need to slow down. Don't just choose the first option in your editor because it makes the warning disappear. Look at what each change tried to do. If you aren't sure, ask the person who wrote the other change. The best final version may include work from both branches. There is one habit that keeps conflicts smaller. Keep branches short-lived. If you create a branch, work on it for three weeks, and ignore changes arriving on main, your branch drifts away from the shared project. By the time you try to merge it, many files may have changed in both places. That creates harder decisions. Instead, make a focused change. Bring the latest changes from main into your branch regularly and merge your completed work back sooner. Smaller changes are easier to understand, easier to review, and less likely to collide. So a branch gives you a separate route for a piece of work, a merge brings that route back into the trusted project version. And the conflict is Git pausing when two routes reach the same point with different answers. Branch is protect your work locally, but a team also needs one shared place where everyone can see the same project history. GitHub, the shared online repository, branches solve a problem on your computer. GitHub solves the next problem. How does the rest of the team see that work? Git and GitHub have similar names, so people often treat them as one thing. They aren't. Git is the history tool installed on your computer. GitHub is an online platform where a team can store, share, discuss, and review Git repositories. Think of GitHub as the shared project space for a team. You still have your own copy of the project on your laptop, including your own commits and branches. GitHub holds a shared online copy, called a remote repository. Remote simply means it lives somewhere other than your computer. That shared copy gives the team one place to meet. If you work from home one day and from another computer the next, the remote repository gives you a place to retrieve the project history. More importantly, it lets colleagues exchange their work without emailing zip files back and forth. There are three words you'll hear all the time, push, pull, and clone. A push sends commits from your local Git repository up to GitHub. Say you finished the company sign an option on your branch. Your commits exist on your computer, but nobody else can see them yet. When you push that branch, GitHub receives those commits and makes the branch available to the team. A pull does the opposite. Someone else may have merged a bug fix or added a new file to the shared project. A pull brings those shared changes from GitHub down into your local copy so you can work from the same current version. And a clone is how you begin when a project already exists on GitHub. Instead of creating an empty folder and building every connection yourself, you clone the repository. Git downloads a working copy of the files and the project history onto your computer then connects that local copy to the shared online repository. So clone means give me my own connected copy of this project. Push means send my committed work to the shared copy. Pull means bring the team's latest work into my copy. Those words describe direction. That's all. GitHub also adds a team process around branches. When your branches ready, you usually don't merge it into main alone. You open a pull request, despite the name, a pull request isn't mainly about downloading anything. It's a request that says, "Please look at the changes on my branch and if they're ready, bring them into this other branch." Usually that other branch is main. On the pull request page, your teammates can see the commits, the files you changed, and the exact lines that changed. They can leave comments beside a line of code, ask a question, suggest a better approach or approve the work. This moves the conversation next to the change itself. No more message that says, "Can you look at that thing I sent yesterday?" The review has a clear record attached to the exact work under discussion. Many teams also run automated checks when a pull request opens or changes. For example, a service can try to build the project, run tests, check code style, or scan for known security problems. GitHub reports whether those checks passed or failed before the change reaches main. The checks don't replace human review. A test can tell you whether a rule passed. It can't always tell you whether the feature solves the right problem or whether the new text makes sense to a user. People still make that call. Once the review is complete and the checks pass, the pull request can merge. The approved branch changes enter the shared main branch and everyone can pull that updated version. GitHub is a familiar choice, but it isn't the only place to host Git repositories. GitLab, Bitbucket, and services inside platforms, such as Azure DevOps, can do similar jobs. The name of the website can change. The Git ideas stay the same. Each person works locally, shares committed work online, and uses review before changing the version the team trusts. A Git-based team workflow. Imagine you arrive on Monday morning and need to fix a small problem in the login page. Before changing anything, you update your local copy from main, you pull the latest shared changes because someone may have merged work while you were away. Starting from an old version creates avoidable problems later, especially when the same files have changed. Once your local main is current, create a branch for your work. Keep the name clear and specific. If you are fixing a password reset link, a branch called FixPasswordResetLink tells the team exactly what it contains. A name like MercoWork tells them nothing. Then make the smallest useful change. Maybe the reset link points to the wrong page. You change that one part, test it, and check which files changed. If you also noticed a spelling error somewhere else, leave that for another branch, unless it belongs to the same fix. Small changes move through review faster. They are also easier to understand when something later goes wrong. If a commit says FixPasswordResetLink, everyone knows where to start looking. If it says many updates, nobody knows what happened. When the change is ready, select the files for the commit and write a useful message. A message like FixPasswordResetLink gives the next person a clear record. You don't need a novel. You need a short sentence that explains the work. After the commit is stored locally, push your branch to GitHub. Now your teammates can see it. The next step is to open a pull request. This gives the change a place for review before it joins main. A teammate might spot a missing test. Someone may ask why the link changed. An automated check may find that the page fails to build. That is the point of the process. Problems are cheaper to fix while the change is still small and separate from the shared version. You correct what needs correcting, make another commit and push again. The pull request updates with the new work. Once the review is approved and the automated checks pass, the branch merges into main. At that point main becomes the version the team agrees on. The branch has done its job, so teams often delete it after the merge. The history remains in Git, but the active list of branches stays tidy. This same flow can also start work behind the scenes. When a pull request opens, a connected service can automatically build the project and run tests. When the pull request merges, another process can prepare the software for release or send it to an environment where people can use it. You may hear this called CI/CD. Continuous integration means the team brings small changes together often and checks that they still work together. Continuous delivery or deployment means those check changes can move toward release with fewer manual steps. It doesn't perform every test or release the software by itself. It provides the agreed record that other tools react to. A push, a pull request or a merge can trigger those tools because Git identifies the exact version of the project they should check. AI now joins some parts of this workflow too. It can draft a commit message, write a short pull request summary, point out files that changed, or suggest a review comment. That can save time, especially on routine work, but AI doesn't own the decision. Someone on the team still needs to read the change, decide whether it belongs in the project and approve it before shared work moves forward. A clean-looking summary can't prove the code does the right thing. So the daily route is straightforward. Update from main, create a focused branch, make a focused change, commit it, push it and open a pull request. That routine turns a group of separate computers into one team that can move without losing track of what changed. Git records deliberate checkpoints in your project, while GitHub gives the team a shared place to review and combine them. Keep this route in mind. Work, stage, commit, push, review, merge. Subscribe on M365.fm for more knowledge nuggets that explain the tools behind modern work and play in English. And share this episode with someone who still thinks Git and GitHub are the same thing.