Not too long ago, a friend of mine said this on twitter:
I hate when I create a repo in GitHub and start a README file. Than when I work on code locally that I want to push to that repo, I can never figure out how to do it so I end up deleting the remote and starting from scratch.
I responded with:
I started thinking to back when I was starting with git and some of the struggles I had, especially when starting a new project.
My current workflow is to start whatever project I’m working on locally, commit locally, then create an empty repo on GitHub and push to it.
If I was creating a new dotnet application, here are the steps I’d take:
> mkdir MyTestApp
> cd MyTestApp
MyTestApp> dotnet new console
MyTestApp> vim README.md <- add some content
Copy a .gitignore file from another, similar project
MyTestApp> git init
MyTestApp> git add .
MyTestApp> git commit -m “initial commit”
Head to Github and create an empty repo named MyTestApp. I don’t NOT let github add a README or gitignore file since I’ve already done that locally.
MyTestApp> git remote add origin email@example.com:mjeaton/MyTestApp
MyTestapp> git push origin master
But, back to the original question–what happens if you create the empty repo with the README, but you’ve also started a README locally?
In this case, I’ll create my repo first
Head to Github and create an empty repo named MyTestApp2. This time, I will let github create a README.
> mkdir MyTestApp2
> cd MyTestApp2
MyTestApp2> dotnet new console
MyTestApp2> vim README.md <- add some content
MyTestApp> cd ..
> git clone firstname.lastname@example.org:mjeaton/MyTestApp2
Doing that should have given an error that the destination path already exists:
fatal: destination path ‘MyTestApp2’ already exists and is not an empty directory.
That makes sense, but if you find yourself with a local working copy AND a GitHub repo and you want to keep the contents of both and link your local stuff to the GitHub repo?
From your project folder, do the following:
MyTestApp2> git init
MyTestApp2> git remote add origin email@example.com:mjeaton/MyTestApp2
At this point, you have connected your local directory to github.
What happens if you try to add and push now?
MyTestApp2> git add .
MyTestApp2> git commit -m “initial commit”
MyTestApp2> git push origin master
You get a big error, right?
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to ‘firstname.lastname@example.org:mjeaton/MyTestApp2’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
This means “origin” is ahead of your local repo; GitHub has newer files than what is on the local computer. To fix it, you need to pull from GitHub.
MyTestApp2> git pull origin master
You should see an error like this:
fatal: refusing to merge unrelated histories
I have history on GitHub and history locally and somehow have to get things reconciled. Ok, so how do I get past that? Simple.
MyTestApp2> git pull origin master –allow-unrelated-histories
Running that command works, BUT now I’m told there’s a merge conflict. Since we made changes to README.md in both places, I expected this.
* branch master -> FETCH_HEAD
CONFLICT (add/add): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
All you need to do is use your merge tool/diff tool of choice and take care of the conflict.
MyTestApp2> git mergetool
As soon as I take care of the conflict, I can commit the change and push to master. Everything is now at a point where I can start my normal workflow using git.
I started by describing my process for starting a new project that uses GitHub: create the repo, clone it, start working. I find this is the most straightforward way to get a new project up and running.
After that, I talked a little bit about how to handle those times when a repo is created on GitHub AND locally, with changes in both places. I covered at least one method to handle the conflicts that arise without deleting the project and starting over, but there are others.