Git and GitHub, from the beginning

What does git solve that copying the folder does not?

Everyone has seen the pre-git method: site, site-final, site-final-2, and that one folder nobody dares delete. The problem with it is not that it is ugly; it is that none of those folders says why it was made or which files changed together.

Git is a version control system: instead of holding several complete copies, it records the state of the project at points you choose. Each point is a commit, and it carries three things a copied folder never has: an exact date and time, the name of whoever recorded it, and a message saying why the change was made.

That third thing is where git's real value sits. Six months later, when you reach a line whose meaning escapes you, your question is not where the line came from; it is why somebody did that. Git answers exactly that question, provided you wrote the messages seriously. A history full of "changes" and "fix" is precisely as useless as the final-2 folder.

And one practical difference that helps you sooner than the rest: git lets you see exactly which lines differ between two points. When a site that worked yesterday is broken today, that is not a convenience feature, it is the only way to find the cause in minutes instead of hours.

Git and GitHub are not the same thing

Git is a program installed on your own computer whose job is keeping history. GitHub is a company that hosts those histories on its servers and has built other things around them: profile pages, issue tracking, code review and the rest. One is a tool, the other a service; roughly what Word is to email.

That distinction carries a property tutorials usually lose: git is distributed, meaning your computer holds a complete copy of the history rather than a pointer to a server. You can commit all day, read the history and go back in time without connecting to the internet once. push only puts a copy of that same history somewhere else as well.

So if that host becomes unreachable tomorrow, the repository on your machine does not become partial, and you can send it anywhere else: GitLab, a private server, even an external drive. What is lost with the host is the issues, the pull requests and the discussions under them, because those are not inside git at all and are the company's own product.

One practical sentence for the reader in Iran: whether foreign hosting services are reachable is something to test yourself on the day, and we do not write today's claim about it here. The right decision is independent of that anyway: keep the history somewhere that does not stop your work if one service goes away. That fits what git already is and depends on no service.

The first four commands, and what add is even for

You put a project under git with git init. That command creates a hidden folder called .git, and from then on anything happening in that folder can be recorded. Nothing has been recorded yet; the ledger has merely been opened.

git init
git add index.html
git commit -m "first page with contact form"
git push origin main

The command that confuses beginners is add, because it looks like a needless extra step. It is not. Between your files and the history sits a middle table called the staging area, and add means "put this on the table, I want it in the next snapshot". That table is what lets you record only the three files belonging to one job, out of the ten you changed today, in a single commit.

This is where the first professional habit forms: one commit should be one job. If you have to use the word "and" in the commit message, it should probably be two commits. This is not a matter of taste; you pay for it on the day you want to undo one change and that change is mixed into a commit with two other jobs.

And push is the only one of the four that needs a network. The first three work entirely on your own machine. Keep that in mind and git's error messages start making sense: an access or authentication error is almost always about push, and "nothing to commit" almost always means you forgot add.

The first thing that goes wrong: a file that should never have been committed

A file called .gitignore at the root of the project tells git what to leave alone. Three categories are always in it: the dependency folder that can be reinstalled, files produced by a build, and anything holding a real password or key.

The third category is where people get hurt. A settings file with the database password gets committed once, then somebody notices, removes the password from the file and makes a new commit. The job is not done: git keeps history, and that password still sits inside the earlier commit, visible with one simple command.

GitHub's own guide says the same: after something like that you must treat the credential as compromised and change it, and removing the file from history is not enough on its own. The correct order is also the reverse of what people expect: rotate the password first, then think about cleaning the history.

So the habit worth having from day one is this: write .gitignore before the first commit, not after it. And if the project needs a settings sample, ship a file like config.example with empty values, so the next person knows what is required without any real value being recorded anywhere.

The site this lesson was written on is not in git

rgb.ir is edited on a live server and has no git repository. We write that down because a lesson that only advises, without saying where it stands itself, is half the truth.

So what took git's place? The editor we wrote for the theme puts a copy of the file aside before every save, named by date and time, and keeps the last twenty versions of each file. It then parses the new file with token_get_all and the TOKEN_PARSE flag, because both php -l and proc_open are disabled on this server and the usual syntax check is unavailable. If the new file does not parse, that earlier copy is restored automatically so the live page does not go down.

That is roughly the minimum definition of a version system, and it does its job well. But its difference from git is exactly what this lesson has been about: none of those twenty copies says why it was saved, nothing links two files that changed together, and past the twenty first version nothing remains.

So if your project is not in git yet, this lesson is not a scolding. Just know the cost: not having git costs nothing at all on the day everything works, and collects the entire bill on the day it does not.