JavaRush /Courses /Claude Code SELF /How pros keep history

How pros keep history

Claude Code SELF
Level 3, Lesson 2
Available

1. How professionals keep history: meet git

“Listen, and since I am almost in the game now,” Tommy jumps in with the next question, and there is already that careless tone in his voice, as if he is asking out of curiosity, not about himself, “how do real developers live then? They have thousands of files in projects, and tons of people, everyone edits the same thing. If they kept multiplying folders like… well, like some people do, they would kill each other in a day.”

“They would,” Alex agrees. “That is exactly why they do not do that. They have a proper tool. And it has a name — git.”

Alex does not rush into details and first gives the big picture:

“Pros do not keep a warehouse of copies. They keep one history timeline, where every project state is recorded in order, neatly, one after another. Not a pile of folders in the corner, but an orderly history. That is git.”

Version Control meme: Alex, in a hat and suit, waves away the folders 2048-final, 2048-final2, 2048-FINAL-final and approvingly points at git with a timeline of four history points

“Wait.” Tommy tries to make sense of it. “What do you mean, ‘one timeline’? I had ten folders. So what do they have, one folder, but somehow all the versions are hidden inside it?”

“Almost. Not ‘hidden somehow,’ but carefully recorded, with order and labels: this state was one thing, then another. I will show you on something you have seen a hundred times.”

2. Version history in Google Docs: git’s three abilities

“And what does that even look like?” Tommy is skeptical. “A timeline — is that folders in a row too?”

“Not folders. The clearest image is version history in Google Docs.” Alex grabs onto something Tommy has definitely seen. “You have worked in a Google Doc, right? The document is one. You edit it. But at any moment you open ‘version history’ and see: this is what it looked like in the morning, this is what it looked like an hour ago, this is what and who changed between these points. And you can roll back to any past state. Notice — the document does not split into dogovor_final2. It is one file, and all its history is stored next to it.”

Google Docs-style document version history: on the left a Tetris spec with highlighted edits, on the right a timeline of saved versions and a Restore button

Tommy plays it back in his head — and yes, he did exactly that. He used to write a shared document, somebody deleted everything, and he went into history, found the right point, and restored it as it was. No copies like document_2, dokument_norm — one file, and its whole life is recorded on the side.

“Ah, so I have already used that, just in docs,” he says. “And I never once thought you could do the same with code.”

“Exactly. Same thing, just with a different name for code. git does exactly the same for code,” Alex continues, and spells out three things. “First: it stores the project’s timeline of states — not a pile of copies, but an orderly history. Second: it lets you go back to any saved state. Third: it shows what changed between states — the very thing your folders never showed you.”

Folders or git — three abilities: storing states — folders give you a pile of copies, git gives you one timeline in order; going back — with folders you hunt for the right one by launching them one by one, git takes you back to any saved state; what changed — folders are silent and don’t show it, git shows the difference line by line; the need is the same — not to lose what worked, the way is cleaner Folders or git: three abilities Folder copies git Storing states A pile of copies One timeline, in order Going back You hunt for the right folder, launching them one by one To any saved state What changed Can’t see it — folders are silent You see the difference line by line The need is the same: don’t lose what worked. The way is cleaner

Tommy catches the idea on the fly and grins:

“Oh, so these are my final2s, only cleaned up. So I came up with the same thing serious guys spent years on — I just built my version by hand, and theirs has a name and wears a tie. The idea is the same: do not lose the good stuff. The method is just a hundred times cleaner: one history instead of a warehouse of copies.”

“Exactly.” Alex nods. “git is a professional version control system. One history, and you can always rewind while seeing what changed.”

And he seals it with the third point, the one that hits Tommy especially hard:

“And this ‘you can see what changed’ thing — that is exactly where it hurts you today. Remember how you could not understand how final was different from final2? You sat there guessing? In git you would open the history and see the difference line by line: here they added plants, here they fixed the count. Your folders never showed you that — they are mute, they just sit there. But history speaks.”

Side-by-side comparison of two versions of the clearLines function: the previous commit on the left, the current version on the right, with the removed line in red, the added scoring in green and the changed speed in blue

“And more than that. Git is such a convenient tool that literally millions of developers use it for collaborative work on public projects,” Alex adds. “The place where these projects are hosted so a whole team can work together is called GitHub. That is just another word for your mental stash for now — but you will start noticing it everywhere; let it sit in your head next to git.”

3. What to use instead of git right now

Alex continues, climbing onto his favorite hobby horse:

“And inside git there is this thing called branches; that is when the main line where the live game runs is called prod. It is the version that works, and nobody breaks it.”

Git branch diagram for Tetris: the main prod line runs through the game's steps up to game over, and a test branch with a space background and neon blocks splits off at “lines + score”

“Now imagine: you want to build a second version of Tetris, a space one, and you are scared to touch the working one. You create a branch — a separate line next to prod. From there on, all experiments happen in it: prod stays intact, and in your branch you can turn everything upside down. If it works, you merge it back; if not, you throw the branch away completely, and…”

“Stop, stop, wait.” Tommy holds up his hand like a traffic cop. “Let the nerds with mechanical keyboards polish branches and commits in the evenings; just hearing those words makes my teeth hurt. The idea itself — history, rollback points — that is totally my thing, no questions there. But now it smells like ‘real engineering discipline’; I can tell from here they are about to spend half an hour teaching me how to sort socks by color. Not my thing. I would just like a good replacement for my final2s — a button, you click it, and you are back to the previous state. As for all this serious tooling, let us not do it today. And definitely not with me.”

Alex laughs and immediately backs off:

“Fair enough. And you know what, you are even right to slow down. git is powerful, but it has its own vocabulary: branches, commits, a whole set of commands. Dumping all of that on you right now is the surest way to confuse everything and kill your motivation. So today your task is simple: remember that there is such a professional system for storing history, and its name is git. Just having the name in your head is enough for now.”

“And when is the real thing?” Tommy asks carefully.

“When you have a project that is truly scary to lose. Right now you are just messing around with Tetris — well, if it breaks, you build it again, no tragedy. But when there is something your heart actually cares about, then git will reveal itself as a serious safety net. And trust me, you will come to it on your own, without me: one day you will run into a situation where lightweight tools are not enough, and you will remember — ah, there was that pro solution. That is when you will sit down and figure it out, with a clear ‘why.’”

“Now that is more like it.” Tommy smirks and slaps the table. “I was already expecting you to sit me down like a first-grader and make me cram this git of yours line by line. And it turns out I just write the name down, nod wisely, and I am free. I love it when smart people themselves give you permission not to learn extra stuff.”

“You can. And that is normal, even correct. Write the name down, understand the idea — that is enough for today.”

“And by the way, so you do not get scared in advance,” Alex adds. “When the day comes, you will not have to install it by hand. Tell the agent ‘install git’ — it will install it and show the version. Just like any other tool.”

“You mean, just by saying it?” Tommy even looks away from the screen.

“Did you already forget where we started? You assembled half a workbench for him on day one. The agent installs tools; your job is to say which one. So all that scary professional system will one day boil down to one line in chat for you.”

“And for now, a simpler tool will be enough for your experiments,” Alex adds. “Undo buttons right inside the AI agent. Light, fast, without any branches or commits. I will show you that now — and that is no longer some vague ‘later,’ it is right now, today.”

1
Task
Claude Code SELF, level 3, lesson 2
Locked
Git installation 🧰
Git installation 🧰
1
Task
Claude Code SELF, level 3, lesson 2
Locked
Set Up a Working Dev Workbench ⚙️
Set Up a Working Dev Workbench ⚙️
Comments
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION