I get git, but I don't get git. Why get git?

Ok, so right upfront, I’ve taken the beginner Python course, and am currently finishing up the building a website with HTML and CSS and GitHub pages course. I’m new to coding, having only been learning this for a year or so at this point, but for the most part I’m understanding it.

One thing I haven’t been able to really understand though, is the “why” of git.

I understand that it can be used to build a repository, but that really seems to be the go-to answer to what it’s for. As a beginner, that doesn’t really tell me anything.

I’ve looked at articles, I’m getting a beginner’s grasp on the command line and how to create/stage/commit with git, but I still don’t know why I would use it instead of something like VScode when I’m looking at creating code.
I’ve seen a few articles expressing frustration over why people skip learning git, and I think this may be a core reason. Without understanding the “why” many will not see the need for the “how”.

Can anyone explain to me, in laymen’s terms, what the purpose of git is? I’m looking for something more clarifying than “to create repositories for GitHub”.

Thanks in advance for any and all clarifying input :bowing_man:

4 Likes

Git is about version control.

  • you can roll back to working versions of your code
  • you can therefore have different “branching versions” so this is great for modular testing in larger structures.
  • invaluable tool when working as a team, since it can be micromanaged and people can work on different bits without stepping on each other’s toes.
  • it’s portable, if you have a remote server you can clone from a repo really easily, in case you don’t want to scp from the computer where you have the files. If you’re updating your remote-hosted website, doing scp every time is a bit overkill and is more error prone the more complex your operation is (in comparison to having a repo where you can role back to versions of your site that were running without errors).
  • git and github are two different things, though related. Github can be used for other purposes (like acting as a portfolio, sharing code, and inviting people to collaborate on your code, github can even host cheap barebones website for free)

Advanced git is a skill that’s acquired over time and study, but often times just fundamental knowledge is enough to get by. But if you plan to work in teams in the future it’s good pick up.

11 Likes

I’ll give you my take:
I haven’t used git for most of my projects because I found it useless for the project I was working on.

  • Some situations where it could have been useful but I managed without it:
    I wanted to make some changes to some existing website I developed, maybe adding a new feature or fixing a bug, with Git I could have forked the existing project (creating a new branch), made the changes, if those changes would actually fix the problem I would then merge the fork. However without git I simply selected my Project folder in Windows, ctrl-C ctrl-V, named the clone to something like Project-copy-feature1, made the changes to the clone, if all right, I either kept both folders or deleted the first (if it would have been obsolete now).

  • Some situations where I used git (as a third party service such as gitlab or github):
    I needed to share an online a project I was working on with some other devs, the easiest way to do that has been to upload it on my gitlab and share the repo. These guys would then modify the project with some features I was not able to do on my own, while I would focus on some other aspects of the code (styling in particular), in order to do that was essential to use git (as in version control) to avoid overwriting each other’s work.

Hope this helps :slight_smile:

3 Likes

Thanks @toastedpitabread and @usernamegiapreso
That insight definitely helps me begin to understand more about git, but I feel like I’m still missing something about it.
Is it that it’s main purpose/benefit is the team aspect of coding?
Maybe I need a usable example.
If, for example, I’m creating a CSS stylesheet that I want to link to a website I’m building, would I create that with git and then host it on github so that I could link it to my html code on the website I was developing? Or is that not a task I would use git for?
And if that is something I would use git for, would I start with something like VScode to create the initial file and then somehow transfer it to a git repository?
I feel like I’m still missing something important with the understanding of why git is used and how to implement it in a beneficial way.

I think its value from a single user perspective depends on complexity of what you’re writing. For simple scenarios it’s often overkill.

In terms of implementation, the most direct way to access it and use it is via the command-line.

Think of it like keeping a diary (or if you play games, like save files). If you don’t like the direction your project is going, but remember a time when it was going in a good direction, it basically rolls you back to that point.

Maybe another analogy is like a detective building a case:
Day 1: you have data, you make hypothesis, you have plans to uncover more data
Day 2: you make a discovery, and this discover nullifies some, but not all of your previous assumptions, so you need to “undo” the state of some of the day 1 assumptions (but you wouldn’t throw away all the data). Each change may have cascading effects that you have to work out… if you don’t have a system… you lose a lot of time re-writing charts.
etc.

Day 365: After the trial, a shocking revelation gets made, but now because you still have a clean record of your processes, you can just roll back and plug in the new information and build out what the ramifications are much quicker.

Why am I using analogies? Because even for beginners the type of things you might think to do with it in your code are vastly different. It’s ok to not fully “get it”. Sometimes you just have to see it in action and sit with how it works long enough to think “aha”. It’s very much a process-oriented tool.

Is it that it’s main purpose/benefit is the team aspect of coding?

Team yes, but also structured individual projects with many moving parts (that may benefit from changes over time).

2 Likes

a single developers project can get large enough that keep track of changes and being able to rollback is beneficial.

git (version control) and github are not the same thing, we can host the website on any VPS (virtual personal server) without git. Github uses git, but the opposite is not always true

creating and updating files is done with a text-editor like VSCode.

git is merely keeping track of the changes you make in VScode, allowing you to view which change you made and when. And to undo this changes.

3 Likes

Is it that it’s main purpose/benefit is the team aspect of coding?

Surely it is one. But more broadly I would say that the word rollback used by @stetim94 is a perfect description of the main benefit of version control. Its name says it: “to control the different versions of the project throughout its lifetime”.

Maybe I need a usable example.

Another practical example is this: if I need to center a div (common stylesheet issue) I have many ways to do that. Now let’s say I want to try all of them to see what’s the best method. You can either:

  1. do the changes on your project and then ctrl Z your way back to its original state if/when you’re not comfortable with the result you’re getting
  2. copy your project as many times as are the features you want to test
  3. or you can just create several branches on git of the original project without ever modifying it directly

You’ll understand that number 1 is ok if the changes you made are few, but if you spent the last 4 hours making changes and you decide you got to go back, ctrl Z is going to be painful.

Number 2 is ok if the feature is one, maybe 2, but imagine copying a 3 or 4 pages website, with all of its assets, many times, it’s surely the most inefficient way to do the job and it is going to get messy adapting one thing to all of the other versions manually.

If, for example, I’m creating a CSS stylesheet that I want to link to a website I’m building, would I create that with git and then host it on github so that I could link it to my html code on the website I was developing? Or is that not a task I would use git for?

Sure you can try that, that would be using your repo as a sort of CDN, it’s a benefit accountable to using a free third party service to host some piece of text, not a benefit of version control. Doing that you’re not using Git. You’re just uploading something that is externally reachable and linking to it.
Small note about that, I don’t think it would give you any advantage in terms of web performances, instead I think it could be a performance penalty. But the only way to know for sure is to test it in prod. For website performances I refer to what Google Pagespeed Insight suggests.

And if that is something I would use git for, would I start with something like VScode to create the initial file and then somehow transfer it to a git repository?

Setting up your developing environment (IDE) is the first thing you should do, and in my experience it is often overlooked. Visual Studio Code is definitely one of the top choices for beginners, but there are many alternatives out there, one very cool I used for a while was Cloud9, basically an online IDE, has been bought by Amazon a while back and it is still available through AWS, but I find AWS too complex for my level, another one I used for a bit was Eclipse Che, which you can install on your machine or you can use the online version managed by Redhat through Openshift.
There are a lot of good youtube videos, beginner friendly, explaining how to setup VSCode. Check them out.

Git is just an open source library you can install on your machine to keep track of version changes. Git is part of a category of software called Source Control Management (SCM) software.
Some IDE could come with SCM software already pre-installed. In VSCode for example this is the case.
If you decide to use Git, you do it locally, however some companies offer a kind of “hosting” service for your code that benefit from integrating Git. The main reason for this is online collaboration.
Now, VSCode is owned by Microsoft, Github is also owned by Microsoft, thus they have a direct interest in having VSCode users connect to Github. But that’s not mandatory.

2 Likes

TL;DR:

  • There are different types of rolling back: one is common, the other less so
  • Git’s best features (for me) are branches and documenting commits
  • Tips on how/when to start a repository at the end

That is not its main purpose, but I think the power of Git is most easily recognized when collaborating with others and hosting the codebase on a website such as GitHub or GitLab. This is where it becomes crucial to allow each contributor to work on discrete issues on separate branches without affecting the main codebase until the changes are ready to merge.

That said, Git is a very powerful and useful tool for personal projects as well. I think the idea of “rolling back” to a previous commit has been brought up a fair bit here, but there might be a few different interpretations of what that means. One interpretation might be if you add new (uncommitted) changes to your code and decide to toss them all out and go back to your last commit. I do this all the time. Another interpretation is “rolling back” from your current commit to a previous commit. I find that in practice I rarely do this.

Let me explain.

Say you are working on a project and you have four commits: A - B - C - D.

These commits are like checkpoints in a game. They are completely unrelated to saving the file with Ctrl + S. You will likely save your code many times before you commit it.

In roll-back scenario #1, it would be as though you start trying to add a feature to your project after commit D (e.g., new formatting/styling on your website). You save your code, test it out, and decide you don’t like it and want to scrap all the code you wrote in the last 3 hours. So you just discard all the changes that came after commit D. I do this all the time and I think it’s a very common use of Git.

In scenario #2, you decide that you liked commit C better than the code added in commit D. Even though all those changes have been saved and committed, you can still revert your code back to the state it was in at commit C. Although this is very powerful, in my experience it’s less common.

It is more common to make the changes you want and commit them in commit E. Why? Because quite often you’ll like part of what commit D does, but you’ll want to improve it by adding/removing/changing some code. Going all the way back to commit C is probably not what you want (you did make commit D for a reason after all).


All of that was just a long-winded way to say that I think rolling back is a critical and powerful part of Git, but depending on which type of rolling back you’re talking about, it might not be what you use Git for on a daily basis.

For me personally, I find the most important aspects of Git to be:

  • The ability to work on separate branches of the code; and
  • Documenting the “what” and the “why” of my changes.

As for the first, it is so much easier to make changes to your code when you don’t have to worry about messing anything up (especially if your code is live). You just make a new branch and add whatever changes you want – break as many features as you want – and your main codebase stays safe and intact. If your changes go well, you can merge them in to the main branch. If not, you can delete the branch with no repercussions.

The second, documentation, hasn’t really been discussed much here but it is one of the most important parts of Git BY FAR. Each time you commit, you should be making a commit message. This message should explain what the change was and why it was made. The “how” is usually evident by reading the code itself. The audience you are writing these commit messages for is either: other people; or your future self.

Everyone has moments when they come back to a project after a few weeks and can’t remember why a piece of code is there. This is what commit messages are for: to tell anyone reading the code at a later date about the changes and the reasoning behind them. See this excellent article on how to properly write Git commit messages: How to Write a Git Commit Message

There are many ways to go about this, and you can run git init later on in a project, but ideally you want to create your git repository at the beginning of your project so you can track changes from the beginning.

Two common ways are as follows:

  1. Create a local git repository, add code, upload to GitHub later:

    • Make a new directory
    • Navigate to that dir on the command line
    • Run git init
    • Open that repository in VS Code with the command code .
    • Later on, if you want it on GitHub follow these instructions
  2. Create a repository on GitHub and clone it to your machine:

2 Likes

There are two fundamental short answers to your question:

1 - Versioning
2 - Collaboration

The projects you’re working on now are relatively small, and can be easily overviewed by a single person. You’re not dealing with having two or more different versions (a “live” one that thousands or millions of people are actively using, and a “development” one that you’re adding new functionality to at the same time that all those people are using the “live” one), keeping them separate so that bugs that crop up during development don’t crash the live version, and handling updates from the development phase to a new live release.

When you get into bigger projects, though, where you’re dealing with millions of lines of code, git will begin to make more sense.

Also, git is not the only answer. It’s just one version control system out of many. It just happens to be the “cool kid” right now.

When I was working full time in software development, CVS (Concurrent Versioning System) was the go-to, and Perforce was an up-and-comer. Git didn’t even exist yet. (Yes, I’m an Old Fart™). There’s also Subversion, RCS, SCCS, Vesta, SCM and any number of other proprietary ones built in-house by various companies over the years.

All of these systems, git included, are designed to make it more manageable to have dozens or even hundreds of devs working on many millions of lines of code.

Take a look at any Linux distro. There will always be a “stable” branch - the “production” version that’s been thoroughly tested and deemed ready for widespread use (Ubuntu, for example, calls this their “LTS” or “Long Term Support” branch) - and a “current” branch, where new features are being added and debugged - an “experimental” version that’s not yet “ready for prime time”.

Imagine trying to do that manually: Track and tag the 27+ million lines of code in the Linux kernel (not to mention all the code that runs the X server, the window manager, the GUI based file managers, the CLI shells, etc.) with a “current” and “experimental” tag, log all the changes, track which ones are part of which compile, which ones are working and which ones aren’t, roll back to a previous working version when needed, …

It’s a daunting task. Which is why tools like git were invented.

It would be nigh on impossible to have things like WoW or CoD or MineCraft without version control tools like git.

2 Likes

Thank you to everyone for the insightful and varied responses. I really appreciate that different approaches were taken in giving answers, it helps me get a better overall picture of what git is and how it can be used.
I don’t know that there is any one answer that I should check as a solution as they all contribute to the big picture.
Thank you again. Hopefully this helps others who are having the same questions.

I came in with the same question, this is great and I’m glad you asked!

My one question is if I’m using MS visual studio, I can see that GIT is part of this but how do I use it? Do I still use GIT in the command line? I guess if I look up some tutorials I will find an answer. Thanks though

1 Like

Good reply. Thank you.
:cowboy_hat_face: :+1: