Creating a repository, rebase, and secrets

This article brings together three topics that come up once you've got the basic Git cycle down: how to create a repository (with git init and from the IDE), how rebase differs from merge, and how to properly get rid of a secret that accidentally made it into the history. All three come in handy when you work with Claude Code too - it runs these operations as commands, and you'll want to know what's actually behind them.

The examples and screenshots are from JetBrains IDEs; action names and where they live may differ in your version. Use a separate practice repository for the exercises. In a work project, follow its rules for branches, commits, and pushing changes.

Creating a repository - git init and from the IDE

If the project is already on GitHub, you can clone it. The other case is when you have a local folder with code. git init creates Git's internal data in it, but not the first commit. The example below assumes README.md and .gitignore have already been created and reviewed; any other files you need are added separately.

git init
git status
# after reviewing the README and the ignore rules
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

For a local repository in the IDE, use the action that creates a Git repository or enables version control. Share Project on GitHub is a separate scenario: it also creates a remote repository and offers to push. Before you push, check the selected files, the history, and the visibility.

Public or private

When you create a repository, there's one choice you can't skip - its visibility:

• public - the repository is visible to everyone on the internet, and anyone can look at the code. Good for a portfolio and open source;
• private - only you and the people you've invited have access. This is the default choice for work and practice code that shouldn't be shown around.

Visibility isn't set in stone, by the way - you can change it later in the repository settings on GitHub.

rebase vs merge - what's the difference

Both merge and rebase solve the same problem: bringing work from one branch into another. But they go about it differently, and that decides what the project history will look like.

merge combines histories. If they have diverged, you usually get a merge commit with two parents. If the current branch is an ancestor of the other one, Git can do a fast-forward without a new commit. The diagram below shows the diverged case.

merge keeps both lines and adds a merge commit, so the history honestly shows there was a separate feature branch.

rebase moves your commits as if you had started the work from the latest tip of the target branch. The history becomes linear, one straight chain. but there's a price: rebase rewrites your commits - the old ones are replaced by new ones with different hashes.

After the rebase, commits C and D look as if they were made on top of E: the history is linear, but these are now new commits (C2, D2) with different hashes.

So which one do you pick? Roughly speaking:

• merge - when it matters to keep the real history and when the branch is shared. The safe default;
• rebase - to tidy up your own personal branch before a pull request: a linear history is easier to read.

Removing secrets from a repository

Deleting a file in a new commit doesn't remove the secret from earlier commits. If a password or token has become accessible to others, first revoke or rotate it with the service that issued it. Cleaning up the history doesn't undo copies that have already been made.

For the cleanup itself, GitHub describes a procedure using git-filter-repo. The exact commands depend on whether you're removing a whole file or replacing a secret string, where it appeared, and where the history has ended up. Follow the official guide to removing sensitive data, including making a fresh clone, checking the result, updating the remote refs, and what your teammates need to do.

Cleaning up your local copy doesn't change the server by itself. Force-pushing the rewritten history is a separate step, and one you agree on first. There's no one-size-fits-all command to run on every branch here. Copies in other people's clones and forks are out of your control; for refs and caches that GitHub still serves, the same guide describes the conditions for contacting GitHub Support.

To lower the risk of it happening again:

• keep secret values out of the code, e.g. in environment variables;
• add local files like .env to .gitignore before they get tracked;
• check the selected files and git diff --cached before you commit;
• if secret scanning and push protection are available for the repository, turn them on as an extra check: they don't catch every possible secret.

How this works with Claude Code

All three topics come up when Claude Code works with your repository. Here's what's worth keeping an eye on:

• it can initialize a repository (git init) and prepare the first commit - but public or private is your call when you create it on GitHub;
• it suggests how to combine branches based on the project's rules; you check what merge or rebase will do before it runs;
• it sees the files going into a commit, but making sure no secret slips in is still on you.

Previous article: Undoing and recovering changes in Git