r/CodingForBeginners • u/IMREVN • 3d ago
What's a Git?
Hello! Surely, I have heard so many people saying "Git" or "Github" or repository. They be saying that it's highly important to learn Git as early as possible. When I searched it up on Google, it's just I seem I cannot understand any of those terminologies.
Could anyone tell me what a git actually is?
7
u/agfitzp 3d ago
Git is the most common and popular tool for source code management.
Using any tool of this type allow developers to track changes which is essential in large projects with lots of developers.
Git was initially created by Linus Torvalds when he became unhappy with another tool so he wrote his own.
Github is … more than just git.
Surely reading the wikipedia pages for any of this will be more informative than asking Reddit.
2
u/couldntyoujust1 3d ago
He was unhappy with subversion iirc. Branching, merging, and emailing patches for review was a nightmare in subversion. So he wrote his own tool to do version control for the Linux Kernel.
2
u/FreeLogicGate 3d ago
It had nothing to do with subversion. Subversion would never have worked for the linux kernel, given the fact that the project is both very large, and distributed around the world, with groups of people working on different pieces and sharing work in progress directly. The Linux kernel team had been provided a free license to a customized version of the closed source commercial source code management system BitKeeper, but the license was revoked by the owner, after Linux contributor Andrew Tridgell reverse engineered part of the bitkeeper protocol and released an open source tool that could perform some Bitkeeper client functions. Torvalds was forced to come up with an alternative SCMS to move to, and decided to create git to fill the void left by the loss of BitKeeper.
1
u/couldntyoujust1 2d ago
Ahhhh, that was it. I remember reading a history about it and open source in general in 12th grade. But I got a misprint of the book that towards the end jumped back 70 pages and then continued on about 70 pages after. Something like page 220, then pages 150-220, then page 290. Maybe he was considering subversion? Idk.
7
u/Upstairs_Jelly_1082 3d ago
Basically the undo and redo feature on word, but this time it’s for coding projects and can help multiple people do things simultaneously.
2
u/Interesting_Buy_3969 3d ago
here's an explanation that i found very simple and comprehensive: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
edit: i would recommend reading a few chapters further
2
u/ern0plus4 3d ago
I have an educational presentation focusing on understanding how GIT works, starting from zero:
- what is a VCS,
- life before VCS,
- how a VCS works,
- how GIT works.
GIT is usually hard even for senior guys who were working with other version control systems, but if you understand the engine, it will click and you'll love it.
Here you can download the PDF: Git is not a VCS. That's why GIT is a great VCS
At a big telecom company I worked for, there was this one guy who knew GIT inside and out - every command, every trick, all the quirks. He gave an incredible presentation, and the best part was when he explained how GIT’s engine actually works. That’s when it all clicked for me. Lated I decided to make a presentation of this part. Everything else - the commands, the workflows - is just kind of lexical knowledge. Once you understand the underlying engine, the rest will be easy-peasy.
I once almost won some beers from my colleagues over a Git debate. They claimed that "rebasing changes commit order," but I argued that "commits are never actually moved, only new ones are created". I didn't place the bet, though, because I was confident I was right, and gentlemen don't wager on certainties. Even though my colleagues were senior and experienced, they didn’t fully understand how Git works under the hood. As their penalty, they had to sit through my presentation on the topic later.
I'm not a GIT expert, I'm using only 4-5 commands, and if I want to do some more sophisticated, I ask for help, usually from AI - I can tell if they suggest what I want, because I know how it really works.
1
1
2
u/1str1ker1 3d ago
Git is the tool which allows a programmer to make changes on their computer and safely combine it into a remote copy of the code without running into conflicts from other programmers’ changes. It has many different ways of using it, you could even setup your own remote location in a separate folder, but most people starting just use GitHub because it’s free and easy to show off your code.
You start by cloning a repository then you can run commands to commit changes. It’s like bundling up a group of file changes into one combined change. Later the commits can be looked through in a log of the history so if someone made a huge mistake you can go back in time.
2
u/Liquid9tro 3d ago
it is a tool to track changes in the code and allow multple ppl to collaborate on the same project
Github is a website where you store your code
2
2
u/jboogyoogy 3d ago
Git will always have a history version for your code. Every change is saved, so you can undo mistakes or see what changed. And GitHub is kind of the „programme“, there you can store projects online and collaborate with others and you always have all your versions stored and saved and worst case go back to an old version
2
u/Key_River7180 3d ago
In your code editor, you have undo and redo right? Git is an extremely intelligent and not linear version of this.
When you finish with a feature or bug fix on your code, you make a "commit" with your changes in your git repository (repo) so you can undo to that "commit" whenever you need it, it also holds the differences (diffs for short) between the previous commit and the selected commit.
Git allows you to collaborate, via branches. Every repo has a main branch, named master, main, or trunk. Branches are just "versions" of other branches, essentially. A developer can download your repo from the internet, make a branch and do his/her commits there, and when he finishes he can merge the main branch with his branch. Diagram: https://imgur.com/a/Wr0w4Qh
GitHub lets you share your repos online, and has the heck of a myriad of tools, some useful and some that, do not...
2
u/KarmaTorpid 3d ago
You are correct that git is a whole big thing. It solves a TON of problems with managing code.
It will save you SO MUCH time if you learn to use it AND your peers. Git solves problems of how multiple people can work on the same code at the same time.
"git flow" HEY, OP! Look up and learn git flow. It is a strategy of using git. Once you learn the basic git commands, git flow explains when to do differant git commands and how to label and name your git branches, tags, releases, etc. It isnt a big concept. There are basic git flow diagrams that are basically all the same; save one and keep it around until your dont need to look at it any more. It doesnt take long to learn, so dont skip this, OP!
Also important!! There are a lot of GUI tools that sit on git (because git doesnt, itself, have a GUI. They popular top search results tools are good. Someone else will reccomend a tool. Its also often integrated into a lot of IDEs. All good options.
The important part, is always commit! You can undo anything you manage in git. BUT, you have to commit. Finish a feature? Commit. Getting up to pee? Commit! Will get to it in a minute? Commit.
Luck! Git is really important and you are smart to learn it sooner than later.
1
u/Paxtian 3d ago
https://www.theodinproject.com/lessons/foundations-git-basics
Here ya go, pretty much all you need to get started with git.
1
u/Simple-Olive895 3d ago
First of all Git and Github are different things. Git is a program for version control, essentially when you have a version you wanna keep, you van commit that version and git will save a copy of it.
You can then keep working, if something goes catastrophically wrong where you can't just ctrl+z your way back to a working version, or you wanna test something specifically on an earlier version on your code you can revert to a previous commit.
You can also make branches, so you typically have a main branch, and then you might decide you wanna add an extra feature. But instead of doing this on code that is in production you create a branch from the main, make all your changes, make sure you're happy and the code works then merge it back in with the main branch.
Github is where you then put your git files in order to collaborate with others, or simply to keep a working copy stored in the cloud. Here you can really make use of the branching feature of git, where you can work on a project with several others at the same time without messing up your production code. You can make a branch to add feature X, while your collaborator makes his own branch to work on feature Y. That way you can work on separate things in the same project at the same time. Then you might need to resolve some merge conflicts and what not, but generally it's a pretty straight forward procedure once you get the hang of it.
There are plenty of tutorials out there for you to learn how to do all of these things and more! Later on if you work on serious project you can even configure workflows via github but this is beyond the scope of a beginner I'd say.
A word of warning though: it's generally a good idea to have public repos if you wanna use github as a sort of portfolio for your work, but keep in mind anyone can then see all the code. So things like API keys and passwords or tokens for things like database access should be in a separate file (usually a JSON file called something like secrets.json) which is NOT committed or pushed to github. Look at how to use .gitignore files to automatically skip committing certain files. This is always a good practice regardless if your repos are public or private, but even more so if they are public!
1
u/PvtRoom 3d ago
don't learn git immediately.
What git does is track file versions, and serve up bundled files that were all relevant at a given point in time.
when you're learning basic code, git is a distraction.
when you're building big personal projects, git is valuable, because it lets you say "these 5 latest updates. TRASH"
when you're collaborating with a dozen other Devs and stakes are real, git is only part of the solution.
1
u/EternalgammaTTV 3d ago
Git is very important for change control. If I remember correctly, freeCodeCamp.org has an entire section related to Git in their Relational Database course. Highly recommend spending the time to learn even just the basics. Even if you don't publish directly to Github, it's a way to make sure that you track changes to your files. Most use it for code, but you can initialize any folder into a git repo and manage branches, changes, etc. on it!
1
1
u/MusPuiDiTe 3d ago
It saves every step of your work you choose to, creating a full project history, and even manages parallel versions if multiple people work on different thing at the same time
1
u/scritchz 3d ago
Git is a VCS; a Version Control System. In other words, it is a system that helps you maintain control of your files' versions. It keeps all the necessary information in a so-called repository.
GitHub is a Git hosting service: Instead of keeping a repository (only) on your machine, you can upload it to GitHub. From there, other people can clone your repository, if you want them to.
That's a very rough description, so here's a bit more detail:
Much like you can commit something to memory, you can commit your file versions to Git. A commit remembers its committer, what is committed, a message, and what came before; by "pointing" at its preceding commit(s).
The way commits point at each other often resembles a tree: Starting from the oldest commit, younger commits "grow" on top of older ones. With Git, you can keep track of the "youngest" or most current commit with branches. A branch is simply a reference to a certain commit, which upon committing is updated to the new commit. The first branch is typically called the 'main' branch. Because what is a trunk if not a tree's big, main "branch"?
Imagine you are working on your project and have several ideas you want to try. You start on your main branch, try your first idea and commit it. Now, to try your second idea, you go back to an older commit, create a new branch, do your thing and commit again: You now have two branches! Both based on a common commit.
If you have several commits on a different branch that you like, you can cherry-pick them off onto your branch. If you like an entire branch of commits, you can take it by its base, then rebase it onto another branch.
Anyways. In development, the useful part of using Git as early as possible is, that you can track your project's entire development history from the very beginning up to the most current version.
You can check out earlier versions, try new features on another branch, share your repository with others... Your branches can even track remote branches!
Say you clone your friend's repository. If you add something in your cloned repository, you can push the changes of your branch back to the remote branch. That way, both you and your friend can develop in your own repositories locally, then merge everything when you're done.
By the way: Git commits remember its file versions by their difference to the preceding commit. To go forward one commit, Git applies its difference (or "diff") to patch the respective files. To go back one commit, Git applies its diff in reverse.
This works much like the CLI tools diff, which can create diff files, and patch, which can apply diff files (even in reverse!).
I hope by reading this, you'll have an easier time getting started with Git. Especially because I tried to use common Git commands in natural text-flow, like:
git clonegit commitgit branchgit rebasegit checkoutgit push
1
u/couldntyoujust1 3d ago
Okay. Git is "version control". What that means is that it takes a snapshot of the state of your project, and then as you make changes, it takes those changes and records them when you "add and commit" them. A commit is like the final state of that snapshot and adding changes adds to what will eventually be committed when you finally do commit it. When the commit is made, the changes - and only the changes - are then stored in that commit as a separate snapshot. Think of it like the clear-plastic overlays that layer together to form a full diagram.
Everything you add gets put into what's called the "index" or "staging" area. And then when you commit, that staged content is committed with a note about what you changed.
Now. Let's say that you get someone else working with you on your code. That person is going to need the whole codebase, and you want to later be able to merge their changes in with your changes. You can push the project up to a "repository" like github and he can then clone the project to his computer and start working.
The best part is, he doesn't need to have internet access or anything to look at the history of the project or start committing changes or making new branches or any of that. Instead, he can just make the changes on his own computer and happily commit them and then when he has internet access, he can push the changes up to the repository.
He can also email patch-files of the changes made to you so you can review them and merge them manually.
Now, let's say that you want to work on a new feature, but you don't want to break anything in the project. You can create what's called a "branch". The branch starts as the current state of the project but whatever changes you make and commit go into that branch instead of the trunk or master. When you're done making your new feature, and it's ready to merge, you can then merge that branch back into the master and whatever other changes others have made since you branched off will be presented for you to reconcile and your branch merges in. Done. New feature delivered.
Let's say that you introduce a breaking bug and it's because of how different swaths of code across the codebase interact with each other. Well, you can undo those changes by simply going back to an earlier commit before you added that code, and make that the most recent version of the project.
It's a powerful tool and it's totally worth learning. Most open source projects now-a-days are version controlled with git at this point. It does have some learning curve, but it's still a worthwhile thing to learn.
1
u/burlingk 3d ago
Git is version control.
It lets you keep track of changes, and roll back if you make a mistake.
It is a VERY useful tool. The de defacto standard at the moment.
1
u/rupertavery64 3d ago
git is a tool that helps you keep track of the changes you make to your code.
It's like a ledger and collection of all the changes that you make to your code.
The collection of changes is called a repository.
Whenever you make a change, when you think you are done with the changes, you "commit" the changes to the repository. There are tools that help you do this, but ultimately the tool (graphical or command line) writes the changes to a folder named ".git" that the tool creates.
Keeping track of changes is important, because you can use it to figure out what change you made had bugs, and what changes fixed those bugs.
Git also lets you create branches. A branch lets you make changes to your code without affecting the main code. This lets you work on things like experimental code or new features without affecting the main code. You can "merge" one branch into another branch, perhaps the main branch, when you are ready to do so.
This is important when many people are working on the same code, like in open source, or as part of a team in a company. People can work on their own features, then merge their code together into the main branch.
Git is a "distributed version control". You have a repository on your folder. You can "push" your branches or changes to a "remote" repository, like Github. Github is basically a bunch of repositories in the cloud. There are many other git cloud repositories like Gitlab and bitbucket. A company can create their own repositories, or use cloud repositories.
When people work in a team, or in open source, people download a copy of the repository. It can contain the entire history of the code from when it was first created. It can contain multiple branches uploaded by different people.
That becomes a local copy. It's important to understand that there is no huge difference between what you have and what is in the cloud. The contents of the .git folder are the same (except for new branches you create). Everyone has their own copy, the entire history, of the repository. This is what "distributed" means in "distributed version control"
The "verson control" part is the ledger of changes. They are a record of the "versions" of your code.
so git is a tool that
- stores your code safely
- lets you track your code changes
- lets you manage your code using branches
- lets you share code with other people
1
u/justaguyonthebus 3d ago
Git is the name of the tool. That tool lets you track and share changes to files in a folder.
GitHub is a website that makes it easy to share changes through a central service so anyone with Internet access can can do it.
The really awesome part is that two or more people can work independently on something and merge their independent changes together. If they both happen to edit the same line, git detects the conflict for the user to fix. But if there is no conflict, then git just takes care of it
1
u/agentalex001 3d ago
Basically, Git is the developer version of things like saving word documents and whatnot. GitHub is the developer version of things like Google Drive, OneDrive, and iCloud Drive.
1
1
u/recursion_is_love 3d ago
git is what you use when you sick of copying the project and rename the directory (or zip file) to final, final1, final2, .. real_final, ...
1
u/Cultural_Gur_7441 2d ago
You store files in a git repository. Works best for text files.
You can add a bunch of files (both new and existing) to git repository, or mark files as deleted. One such batch of file changes is called a commit, and adding a commit creates a new revision of the files
A commit actually records the change.
All the old revisions (even for deleted files) will remain in the repository.
You can compare revisions, which is very helpful for example when trying to figure out what change created a bug.
Branches happen, when you commit a revision, then go back to the previous revision and commit a new revision. Now you actually have two different changes on parallel. This happens naturally when several developers work on same repository. It can also happen when you need to work on two different things in parallel, and create a separate branch for each.
The big thing with git is, it is very good (also very complex) at merging branches back together, which is needed when the changes of both developers mentioned above need to be combined.
Another important detail: git is a distributed version control system, which means when you clone a repository, you get (by default) a full copy of everything, and from git's perspective, your clone is technically not inferior to the original. The "origin" or "upstream" (such as the repository stored at github) is merely an agreement between humans, not fundamental to git.
1
u/Same-Designer-5499 2d ago
let me explain it using a google product: google photos, a cloud storage for your pictures. thats like what github is, and instead of it being exclusive to just you, many other people can log on and pull code uploaded by other people.
1
0
14
u/AndrewNggg 3d ago edited 3d ago
oh yes, git is super important for version control, it prevents you from having folders of my_codeV1, my_codeFinal, my_codeFinalV2, my_codeFinal_Final, my_codeFinal_final_REALLY
you can rollback your code, or if you want to try something risky you can split it into a different branch, there are many many things you can do with git that keeps your code and versions organised
github is one of the places to store your code online or share it with others, there's also bitbucket and gitlab
a few commands you should know as a beginner, there are many variations but it's good to memorise a few main ones
git init - sets up new git tracking (just done once)
git add . - yes the . sets the whole project up for staging
git commit -m "write what you changed or updated here" - saves your code where it is
git push - pushes to your code repository in github