How to Start Working on an Existing Git Project

When you join a team, the path to your first contribution is the same almost everywhere: clone the repo, install its dependencies, create a branch off the main branch, make your change, push the branch, and open a pull request. You never commit straight to main, and you never start from an empty folder. The project already exists; you are joining it.

Here is the whole sequence, with the reasoning behind each step so you know why you are typing what you are typing. If you are completely new to Git, start with Git for Beginners first; this article assumes you can run a terminal command and have Git installed.

The short version

git clone git@github.com:acme/widget-api.git
cd widget-api
npm install                       # or: pip install -r requirements.txt, bundle install, etc.
git checkout -b fix-login-redirect
# ...make your change, then:
git add .
git commit -m "Fix redirect loop on expired session"
git push -u origin fix-login-redirect
# then open a pull request on GitHub

That is the entire loop. The rest of this article explains each line.

Step 1: Clone the repository

Cloning downloads the full project, including its entire history, and sets up a connection (called origin) back to the server you cloned from.

git clone git@github.com:acme/widget-api.git

That creates a widget-api folder containing the code. Use the SSH URL (git@github.com:...) if you have an SSH key set up, or the HTTPS URL (https://github.com/...) if you do not. If you have not set up a key yet, see adding an SSH key to GitHub; if you are unsure which to pick, I compared SSH vs HTTPS remotes separately.

Cloning is not the same as forking. On a team where you have write access to the shared repo, you clone. Forking makes your own server-side copy first and is the norm for open-source contributions where you do not have write access. I cover the distinction in fork vs clone.

After cloning, move into the folder:

cd widget-api

Step 2: Install dependencies and read the README

The code is on your machine, but it will not run yet. Almost every project depends on packages that are not committed to the repo. The README tells you which command installs them and how to run the project locally.

npm install          # Node.js
# pip install -r requirements.txt   # Python
# bundle install                    # Ruby
# composer install                  # PHP

Why are these packages not in the repo? Because they are listed in a manifest (package.json, requirements.txt) and reinstalled on demand, and the actual files are excluded by .gitignore. Open the .gitignore early; it tells you a lot about what the project considers generated or local-only. If a node_modules folder or a .env file shows up as untracked, that is expected: those are ignored on purpose.

Run whatever the README lists as the test or dev command to confirm the project actually works on your machine before you change anything. Diagnosing a failing build is much easier when you know it failed because of your change, not because the project never ran in the first place.

Step 3: Make sure your main branch is current

Before you branch, make sure your local copy of the main branch matches the server. A fresh clone is current by definition, but if you cloned days ago, sync first:

git checkout main
git pull

git pull fetches the latest commits from origin and merges them into your local main. On a recent Git, that first pull can throw the reconcile-branches prompt the first pull can throw if your local and remote histories have diverged, so do not be alarmed when it asks you to pick a strategy. If you want to inspect what changed before merging, fetch first and look; I explain the difference in git pull vs git fetch.

If you already made edits before syncing, the pull can also stop with a complaint that your local edits would be overwritten. The cleanest fix is to stash them out of the way, pull to get main current, then continue.

Some teams call the main branch master instead of main. Check with git branch -a, which lists every local and remote branch.

Step 4: Create a branch for your work

You do your work on a branch, never directly on main. A branch is a cheap, isolated line of development. It lets you commit freely without touching the shared branch, and it is what a pull request is built on.

git checkout -b fix-login-redirect

git checkout -b creates a new branch and switches to it in one step. The name should describe the work: fix-login-redirect, add-csv-export, bump-node-20. Many teams have a naming convention (feature/..., fix/...); the README or a CONTRIBUTING file will say. If branching itself is still fuzzy, I walk through it in Git branching explained.

Newer Git also offers git switch -c fix-login-redirect, which does the same thing with a clearer name. Both work; use whichever your team uses.

Step 5: Make your change, then stage and commit

Edit the files. When you are ready to record a snapshot, you stage the changes and then commit them. Staging is the step where you choose exactly what goes into the next commit, and it trips up a lot of newcomers, so it is worth understanding the staging area properly.

git status                # see what changed
git add src/auth.js       # stage specific files
git commit -m "Fix redirect loop on expired session"

git add . stages everything that changed, which is fine for a focused branch. For a clean history, prefer staging only the files that belong to this change so unrelated edits do not sneak in. Run git status first, every time, so you know what you are about to commit.

Write a real commit message. "Fix redirect loop on expired session" tells a reviewer what happened; "stuff" and "fix" do not. A good message has a short summary line in the imperative mood. There is more nuance to it, which I cover in commit message conventions.

Made a typo in the message or staged the wrong file? It is recoverable. You can undo the last commit before you push, and if you have already deleted work, the reflog can recover lost commits.

Step 6: Push your branch

Your commits live only on your machine until you push them. The first push of a new branch needs -u to link your local branch to a new branch on origin:

git push -u origin fix-login-redirect

The -u (short for --set-upstream) tells Git that this local branch tracks origin/fix-login-redirect. After that first push, every later push and pull on this branch is just git push and git pull with no arguments. If you skip the -u and Git complains about a missing upstream, that exact situation is covered in the current branch has no upstream branch.

Step 7: Open a pull request

Pushing the branch does not merge it. It just makes the branch visible on the server. To get your change into main, you open a pull request (PR): a request to merge your branch, which your teammates review before it lands.

Right after a push, GitHub usually prints a URL in the terminal that opens the PR form directly. Otherwise, go to the repo on GitHub and you will see a banner offering to open a PR for your freshly pushed branch. Write a clear title and description explaining what changed and why, link any related issue, and submit. The full walkthrough is in how to create a pull request.

From there, a reviewer reads the diff, leaves comments, and either approves it or asks for changes. If they ask for changes, you make more commits on the same branch and push again; the PR updates automatically. Once approved, someone merges it into main. Most teams protect the main branch so a PR with a passing review and green CI is the only way in.

clone vs fork: which one applies to you

The first decision when joining a project is whether you clone the shared repo or fork it. It comes down to write access.

If you forked, your branches push to your fork and your PR goes from your fork into the upstream project. You will also need to keep your fork synced with upstream as the original project moves on. On a team where you clone the shared repo, none of that applies; you push straight to origin.

Common things that go wrong on your first day

A few errors are near-universal for newcomers. None of them mean you broke anything.

• Please tell me who you are on your first commit means Git does not have your name and email configured yet. The fix is two git config commands, covered in Git: 'Please tell me who you are'.
• Permission denied (publickey) when cloning over SSH means your SSH key is not set up or not added to GitHub. See Permission denied (publickey).
• Support for password authentication was removed over HTTPS means GitHub wants a personal access token, not your account password. The fix is in password authentication was removed.
• failed to push some refs usually means the remote has commits you do not, so you need to pull first. See failed to push some refs.

When your branch falls behind main while your PR is open, you will eventually have to integrate the latest changes, which can produce a merge conflict. Conflicts are normal and resolvable; they are not a sign you did something wrong.

Where to go next

That loop, clone to PR, is the daily rhythm of working on a team. Once it is muscle memory, the next things worth learning are how your team integrates branches (merge vs rebase) and which overall branching model you are following (GitHub Flow vs Git Flow vs trunk-based). The full map of beginner Git topics lives on the Git for Beginners hub.