Put Your Project on GitHub: Remotes, push, pull and clone

Until now, your history lived only on your computer. If the laptop is lost, the work is lost, and nobody else can see or use it. A remote is another copy of your repository that lives somewhere else, usually on GitHub. You send your commits to it with git push, and you fetch other people's commits with git pull. In this lesson you connect your project to GitHub and learn the daily rhythm of pull, work, commit and push.

Create your GitHub account and a repository

1. Go to github.com and sign up for a free account. Choose a sensible username, because it appears in your profile address, and it can be seen by employers. Turn on two-step login in your security settings.
2. Click the button to create a new repository. Give it a name, such as recipes, and choose Public (anyone can see it) or Private (only people you invite).
3. If you already have a project on your computer, do not tick the options to add a README, a .gitignore or a licence. An empty remote is easiest to connect to an existing project. If you do add them, you must first pull them (see the end of this lesson).
4. GitHub then shows a page with the address of the repository, which is called the remote URL, and a few commands to copy.

Connect and push

In your project folder, add the remote and push. The name origin is the usual nickname for the main remote. Replace the address with the one GitHub shows you. It looks like https://github.com/yourname/recipes.git.

git remote add origin https://github.com/yourname/recipes.git
git push -u origin main

The -u option links your local main with origin/main, so from then on a plain git push and git pull know where to go. After this, refresh the GitHub page, and your files and commits are there. In the next session, we used a folder on the same computer as the "remote", in place of the website, because the commands are exactly the same. The only difference is the address.

$ git remote add origin ../remote.git
$ git remote -v
origin	../remote.git (fetch)
origin	../remote.git (push)
$ git push -u origin main
To ../remote.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
$ git clone remote.git friend
Cloning into 'friend'...
done.
$ git push
To ../remote.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../remote.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git pull --no-rebase --no-edit
From ../remote
   fc367a6..069b3ff  main       -> origin/main
Auto-merging app.txt
Merge made by the 'ort' strategy.
 app.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ cat app.txt
Better title
body
footer
$ git push
To ../remote.git
   069b3ff..1446436  main -> main
$ git log --oneline --graph
*   1446436 Merge branch 'main' of ../remote
|\  
| * 069b3ff Friend improves the title
* | 221c047 I add a footer
|/  
* fc367a6 First version

What happened

• git remote -v lists your remotes. push -u sent the commits and set up tracking, and git status now says the branch is up to date with origin/main.
• git clone makes a full copy of a repository, with its whole history, into a new folder. It also sets origin for you. Use it when you join a project that already exists.
• A friend pushed a change first. When we ran git push, Git rejected it: the remote has work that we do not have. This is very common in teams, and it is not an error to fear. Git protects the other person's work.
• The fix is git pull, which fetches the new commits and merges them into your branch. Here the changes did not clash, so Git merged them automatically. Then git push worked.
• The graph shows the two lines of work joined by a merge commit.

fetch and pull

git pull is really two steps in one: git fetch downloads the new commits and updates the origin/main label, and then a merge brings them into your branch. If you want to look first before changing your own files, run git fetch and then git log origin/main or git diff main origin/main. Many people also set git config --global pull.rebase false so that pull always merges, or learn rebase later when they are comfortable.

Signing in safely

When you push to GitHub, it must know that you are allowed to. GitHub does not accept your account password for Git commands over HTTPS. You have these options. Check GitHub's current help pages for the exact steps, because they change.

• Git Credential Manager (included with Git for Windows and available for macOS and Linux): when you first push, a browser window opens, you sign in, and it remembers you. This is the easiest option on a personal computer.
• A personal access token: a long generated text that you use in place of a password. Give it the smallest permissions and an expiry date, and treat it like a password.
• SSH keys: you create a pair of keys with ssh-keygen -t ed25519 -C "your email", add the public key (the file that ends with .pub) to your GitHub settings, and use the SSH address of the repository, which starts with git@github.com:. Never share the private key file.
• GitHub CLI (gh auth login) is a separate tool that handles sign-in and many GitHub tasks from the terminal.

A healthy daily rhythm

1. Start the day with git pull, so you have everyone's latest work.
2. Create a branch for your task (lesson 4).
3. Commit small steps.
4. Before you push, git pull again if others may have pushed.
5. Push your branch, and open a pull request (lesson 7).

If GitHub already has files that you do not have

Suppose you created the repository on GitHub with a README and then tried to push an existing project. Git rejects the push, because the two histories have nothing in common. Run git pull origin main --allow-unrelated-histories, resolve any conflicts and push. You can avoid the problem by creating an empty repository, or by cloning the one with the README and adding your files to it.

Your task

1. Create a free GitHub account, with two-step login, and a new empty repository.
2. Connect your recipes project with git remote add origin and push with git push -u origin main. Refresh the page and see your files.
3. Clone your repository to a second folder, change a file there and push. Then pull in the first folder.
4. Run git remote -v, git status and git log --oneline --graph and explain each line.

How to check it worked

• Your files and commits appear on the GitHub page.
• A change pushed from the second folder appears in the first after git pull.
• You can explain why a push can be rejected and how you fix it.