-1

I'm working on a project on two different computers and I want to be able to simply push from one computer and pull it on the other so that it essentially replaces the local one with the one on Github. Just a simple replace this, with that

I've tried looking it up but I don't really understand the terms, I'm new to using Github so I don't get merges, and branches. I just want to pick up where I left off on the other computer. I tried some solutions I found but then I didn't understand the Merge editor so I accidentally deleted the code in one of the files. So, I'm afraid to keep trying to use commands randomly.

if I use $ git clone again, will that replace all of my current files in my project to match the one on Github?

js1069
  • 31
  • 6

2 Answers2

1

git clone will fail with an error if you try to have it overwrite an existing directory or its contents. You should only have to clone once, and if you clone then you do not need to run git init (clone does that).

To get new work from a local computer onto GitHub (etc.),

  1. git add
  2. git commit
  3. git push

To get new work from GitHub (etc.) onto a local computer, git pull.

If you're switching between two systems and want them roughly up-to-date with each other, then you need to push when you finish - otherwise you'll get a message that tells you exactly what to do to fix it, but that few people actually read.

Jim Redmond
  • 4,139
  • 1
  • 14
  • 18
0

If anyone else had trouble with this and found answers that said to just do what the console says, they were probably right. It seemed very counterintuitive to me to "commit" and "merge" the code that I wanted to replace when I didn't care to create another branch but you really will just follow the console, EXCEPT when it tells you to push. Which is the same as Jim Redmons answer above.

If you've done what I did before trying this (fumbling around and making things worse) and now you get a warning about an unmerged file, then instead of using $git add PROJECT, you'll use $git add UNMERGED_FILE, then commit and pull.

The main thing I learned was to trust the console a little more. (Up until this point, suggestions in the console have not been helpful and sometimes actually detrimental which caused me to do more work trying to backtrack what I've done wrong.) and also that I should do a deep careful dive into how Git works.

js1069
  • 31
  • 6