At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome to the Advanced Claude Code session. In this session we learn a tidy, safe workflow, so Claude Code can be used for bigger projects. We start with the most important safety net: Git. With Git, every change is saved, can be viewed, and can be undone at any time.
Step 1: Why you need a change history
Raka looks after the Sunset Coffee website, built with Claude Code. Every time something needs changing, Raka copies the file first. The result: index final, index final two, and index final two real. The problem gets worse when Claude changes five files at once. If the layout breaks, Raka doesn't know exactly what changed, and copying files one by one is no longer enough. Git is a tool that records the history of changes. It's free and used by almost every programmer in the world. The first term: repository, a project folder that Git keeps track of. The second term: commit. Picture it as taking a photo of the project at one moment, then writing a caption on the back, such as add opening hours at the bottom. Third, history: the sequence of every commit from the beginning until now. From the history we can see who changed what and when, and go back to any point. Fourth, branch: an experimental path separate from the main version. It's perfect for trying a big idea without disturbing the live website.
Step 2: Starting Git and protecting secrets
Raka opens Claude Code in the website folder and asks for three things: start a Git repository, make sure secret files aren't saved, then make the first commit. Claude runs the command to start the repository. From now on, Git keeps track of that folder. Before saving anything, Claude finds a file called dot env that holds the order form's service key. A key like this is similar to a password, so it must not go into the history. Claude creates a gitignore file, a list of files Git ignores. It contains that secret file, the packages folder, log files, and the backup folder. Claude checks the status: fourteen files ready to save, and the secret file isn't included. This small check matters. Don't skip it. The permission box shows the commit command with its message: initial version of the Sunset Coffee website. Raka reads it, then approves. The first commit is saved. This is the first photo in the album of Raka's project history.
Step 3: Commit every small change
Now the everyday workflow. Raka asks for a small change: add Sunset Coffee's opening hours at the bottom of the page. Claude edits the home page file. The diff shows what changed. The green line is the addition: open daily from eight in the morning to nine at night. That's all; nothing else was touched. Raka checks the result in the browser. Only after being sure it looks good does Raka ask for a commit. The order matters: check first, then save. Claude saves the commit with a short message that explains the change. The history now holds two commits, each with a unique code and a message. Months from now, Raka will still know when the opening hours were added. The commit message decides whether the history is useful. The message update explains nothing. Compare it with add opening hours to footer. The message fix is too general as well. A clear message says what was fixed and where: the order button that can't be tapped on phones. And revised again should be replaced with what actually changed, such as the cold brew price becoming fifty-five thousand. The good news: Claude usually writes clear messages when we ask.
Step 4: Undoing changes safely
Now for the moment when Git really saves the day. After the theme color changed, the menu looks broken on phones. Raka asks Claude to put it back. Claude looks at the last three commits and finds the cause: the commit that changed the theme color to dark brown. A permission box appears with a reset hard command. Read the description: delete the last commit and all unsaved changes. That's too risky, so Raka chooses No. Raka explains what's wanted: undo it without erasing history. Declining a permission isn't failure. This is exactly where we steer Claude. Claude uses revert, which creates a new commit that reverses the earlier change. The old history stays intact. The layout is back to normal, and the brown color commit is still saved in case it's needed someday. Hold on to this rule: commands that erase history or force an overwrite are always declined, unless you fully understand the consequences. For bigger ideas, Raka uses a branch. The goal is to try a dark mode look without disturbing the main version that's live. Claude creates a new branch called try dark mode and switches to it. All the next changes happen only on this path. Claude changes three files, and Raka checks the result in the browser as usual. If the result looks good, the branch is merged into the main version. If not, just leave it, and the main version is never touched.
Step 5: Online backup and safety rules
Now the online backup. Raka has created an empty private repository on GitHub, and asks Claude to connect the project and upload the history. Claude first checks the whole history and confirms there are no secret files in any commit. It also makes clear that Raka signs in to GitHub personally, without handing a password to Claude. Claude adds the repository address as the backup destination. The permission box explains that the history will be uploaded to a private repository. Since the destination is right and the content has been checked, Raka approves. Six commits are uploaded. If Raka's laptop breaks or gets lost, the project's whole history is still safely stored. Let's sum up the safe Git rules. First, create the exclusion list before the first commit, so secrets never enter the history. Second, one small, checked change, one commit. A tidy history makes undoing easy. Third, upload the history to a service such as GitHub as an online backup. For business projects, choose a private repository. Steps and screens can change, so follow that service's official documentation. Fourth, if a secret slipped into the history, change that key or password right away. Deleting the file isn't enough, because the old version is still in the history. Fifth, never approve commands that erase history or force an overwrite without understanding the consequences. Git is useful beyond websites too. Dewi could set up Git in the scripts folder, so every change to the report rules is recorded and can be undone. Mr. Hendra could save text versions of his quizzes and modules every semester. And the most important habit when working with Claude Code: make a commit before asking for a big change. If the result isn't right, you always have a safe point to return to. The screens in this video are simulations, so your screen may look slightly different.
Done!
We set up Git through Claude Code, protected secret files, saved changes with clear messages, safely undid a damaging change, and used a branch for experiments. In the next episode we learn another key habit: asking Claude to plan before changing code, so big changes stay under control. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Ask Claude Code to start Git in one of your projects and make a list of files that must not be saved
Make three small changes, each saved as a commit with a clear message
Ask Claude to undo the last commit the safe way, then read the history
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,286 episodes
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
