Git Init and Clone — Start or Copy a Repo Without Losing Your Mind

This is the moment where the concept finally clicks.

You're already learning to adopt software engineering processes: estimating, planning, writing docs, and doing code reviews. Those practices assume people can actually share and synchronize code. Enter version control — specifically Git — which makes collaboration sane instead of a chaotic email attachment fiesta.

In this lesson we'll cover two fundamental commands that start most Git workflows: git init (create a repo from scratch) and git clone (copy an existing repo). You won’t get lost in theory — just practical, memorable rules and examples so you can get moving fast.

TL;DR (If you only remember two things)

• git init: Turn a directory on your machine into a local Git repository. Use it when starting a new project or converting an existing folder into version-controlled history.
• git clone : Make a local copy of a repository that already exists remotely (GitHub, GitLab, Bitbucket, another developer's machine, etc.). Use it when joining a project or starting work from a shared template.

Both are the “doors” into the Git house — init builds the house; clone copies an existing house (garage and all).

git init — Create a repository locally

What it does

• Creates a .git directory that holds all the repository metadata and object store.
• Does not create commits by itself. You still need to add files and make commits.

When to use it

• You're starting a new project (README, license, initial code).
• You have an existing folder and want to start tracking changes.
• You want a local repo to test Git features without touching a remote.

Quick example

# start a new project folder
mkdir lemonade-app
cd lemonade-app

# initialize git
git init

# create files, add, and commit
echo "# Lemonade App" > README.md
echo "node_modules/" > .gitignore

git add README.md .gitignore
git commit -m "Initial commit: README and .gitignore"

# add a remote later (e.g., GitHub)
git remote add origin git@github.com:youruser/lemonade-app.git
git push -u origin main

Subtle things to remember

• The magic is in the .git folder. If you move or delete it, you break the repo.
• If you initialize in a folder that already has content, nothing is lost — you just need to git add and commit to start tracking.
• Use .gitignore early to avoid accidentally committing large or sensitive files — this ties back to Documentation Practices and good repo hygiene.

git clone — Copy a repo from somewhere else

What it does

• Copies the repository including commit history, branches, and tags into a new directory on your machine.
• Sets up a remote named origin by default, pointing to the source you cloned from.

When to use it

• You want to start working on an existing project (open-source, team repo, or a class starter repo).
• You're joining a team and need the full history for context (useful in code reviews!).

Basic examples

# clone via HTTPS
git clone https://github.com/CS50/lemonade.git

# clone via SSH (recommended if you have SSH keys configured)
git clone git@github.com:CS50/lemonade.git

# clone a specific branch
git clone --branch develop https://github.com/CS50/lemonade.git

# shallow clone (faster, less history) — good for CI or quick experiments
git clone --depth 1 https://github.com/CS50/lemonade.git

# clone recursively if submodules are used
git clone --recurse-submodules https://github.com/CS50/lemonade.git

Why clone instead of init + remote?

Cloning gives you the repository history and default remotes in one step. If you're joining a project, cloning is the usual move. git init is for starting fresh.

Practical workflow examples (real-world context)

• New course project from a template: the instructor provides a starter repo on GitHub. Students git clone it, then create branches for features or assignments. This ties into estimating & planning because each student can track progress with commits and branches.

• Starting a project from scratch: mkdir -> git init -> add README & license -> push to remote. Document the repo (README) and add .gitignore before committing large generated files — this is where Documentation Practices help prevent trash in your history.

• Team collaboration: Alice clones the repo, creates a branch feature/A, pushes it, and opens a PR. Bob clones the same repo and reviews. This chain is exactly how Code Reviews and collaboration happen smoothly.

Troubleshooting & tips

• "fatal: destination path 'X' already exists and is not an empty directory" — either choose a new folder or remove/empty the existing one.
• "detached HEAD" — you cloned a specific commit or checked out a tag. Create a branch to resume normal workflow: git switch -c my-branch.
• Prefer SSH for authenticated pushes (set up keys) or use personal access tokens for HTTPS when required.
• Use --depth 1 for CI jobs to save time/storage when you don't need history.
• If you want a repo to be a central-only server copy (no working files), initialize a bare repo: git init --bare repo.git (mostly for server-side setups).

Best practices (because teams thank you later)

• Initialize a README and .gitignore before the first commit — document the project and avoid committing junk.
• Use descriptive initial commits like "Initial commit: project skeleton" so the history reads like a story.
• Clone with the branch you plan to work on, or create a local branch immediately for feature work.
• Keep origin pointing to the central repo. If you forked, add your fork as origin and the upstream as upstream.

Quick summary & takeaways

• git init = make this folder a Git repository.
• git clone = copy an existing repository to your machine with history and remotes set.
• Use .gitignore early and push a README — documentation and good repo hygiene connect directly to the Software Engineering Practices you've been learning (planning, docs, reviews).
• For collaboration: clone the central repo, create branches for features, push your branches, and open PRs for code reviews.

Final memory nugget: Init builds the house. Clone moves you into a house that already has furniture. Keep your history tidy, your README clear, and your branches short-lived and meaningful — future you (and your reviewers) will send you a thank-you commit.

Key commands recap

git init                    # create a new local repo
git clone <url>             # copy a remote repo locally
git clone --depth 1 <url>   # shallow clone (no deep history)
git clone --branch X <url>  # clone and checkout branch X
git remote add origin <url> # connect local repo to a remote

Good luck — clone the repo, make a branch, push your work, and let the code review fireworks begin. You've already learned the practices; Git just gives them legs.