I'm new to git and github and I'm struggling to figure out what's going on with git in cmd. I've just made lots of commits and I'm done working on one of my repos (locally and pushed to GitHub).
I now want to work on another repo locally for which I have a repo on GitHub, but I'm not sure how to stop the connection between my local machine and GitHub for the repo I've just finished working on. Is there a way to break the connection in cmd between the local repo and the GitHub repo? A proper way to close it?
Subsequently, if I want to move to another project, how do I do this? Would I need to break the connection then start from scratch? i.e.:
# after breaking previous link start again with:
git init
git remote add origin URL
git push -u origin master
# make changes to files then:
git add .
git commit -m "message"
git push
CodePudding user response：
Is there a way to break the connection in cmd between the local repo and the GitHub repo? A proper way to 'close' it?
You can break the connection between your local and the remote repository by using the git remote remove command, but you will not gain anything by doing that.
No, you do not need to "close" a repository if you don't work on it. You just stop working on it.
You can also just delete your local copy of the repository if you don't plan on working on it any further (assuming that you've pushed all relevant changes to the remote).
Subsequently, if I want to move to another project, how do I do this? Would I need to break the connection then start from scratch?
You don't need to do anything if you don't break the connection between the local and the remote repository. Just continue working on the other project where you left it the last time.
Yes, if you start a new other project, you could use git init to create a new Git repository for it.
I'm assuming you are using separate directories for each project. Don't use the same directory for multiple unrelated projects with their own Git repositories.
CodePudding user response：
As an addendum to mkrieger1's answer—and my addendum is too big and needs too much formatting to be a comment—let me say these things:
A remote is a short name you store in your local repository, such as
origin. Most Git repositories have no remote, or one remote namedorigin.The function of this remote is mainly twofold:
- It holds the URL for some other Git repository.
- It acts as a prefix for remote-tracking names such as
origin/main.
A remote-tracking name is simply a way for your own Git repository to remember branch names found in some other Git repository.
The point of a remote-tracking name is simple: commit hash IDs are universal; all Git commits in every Git repository always have different hash IDs unless the two commits are literally exactly the same commit. That is, whenever you make a new commit in your Git repository, your commit gets a new, totally-unique hash ID, never used before, never to be used again.1 That's true for every commit anyone ever makes. But Git repositories do get together now and then and share commits, and when they do, the shared commits share the hash IDs. In a very real sense, then, the hash ID is the commit, so if you have a commit with the right hash ID, you have the right commit. If we (humans) worked with hash IDs, we wouldn't need branch names—but we don't work with hash IDs because they're horrible.
So, our repositories have branch names, which work OK with feeble human brains. But a branch name stores one hash ID. My repository branch name xyzzy can only store my latest xyzzy-branch commit. If you and I are working together and using a second and/or third Git repository and want to call a commit xyzzy in some shared repository, I need my own xyzzy, you need your own xyzzy, and we can fiddle with a shared name as needed to synchronize our two separate repositories.
So, when I copy from your repo or from the shared repo, I don't want to call that commit xyzzy. I want to use a remote-tracking name that remembers your xyzzy as you/xyzzy, or the shared repo's xyzzy as origin/xyzzy. That way my xyzzy is mine. I can mix and match whenever I want or need to.
To make remote-tracking names work, we need remote names. So remote names provide the ability for us to have remote-tracking names, and now we're all fine!
Hence, having a remote origin in your Git repository simply gives you a way to reach out to some other Git repository. You'll share commits with that other Git repository, and those will use the same raw hash IDs. You'll not share branch names with that other Git repository—not exactly: they'll have their branch names, which you'll remember locally in your repo as remote-tracking names, and you'll have your branch names. You'll use these to coördinate if and as needed. (Depending on how you use GitHub or some other sharing site, you may never need it, but it's there if you do need it.)
Should you remove a remote?
You can run git remote remove origin, and your Git will remove the name origin. This will remove the stored URL (part (a) of point 2 above) and the remote-tracking names (part (b) of point 2 above). It has no other effect. There is no active, ongoing connection between your repository and the other repository. They only connect when you say your computer (your laptop or whatever) should reach out to GitHub (or whatever sharing site) and connect for as long as it takes to exchange some commits and/or update some remote-tracking names. Then your computer and theirs disconnect. There's no ongoing resource usage, other than the disk space used to hold the remote name and related data in your repository.2
So, in most cases, there's zero benefit from removing a remote. It may get stale, but so what? There's no carrying cost.
1The pigeonhole principle tells us that this is mathematically impossible: some doomsday will eventually come when Git will stop working. How many trillions of years that may be from now, perhaps after the heat death of the universe, is a function of the size of the hash ID and random chance and, absent deliberate malice, is not worth worrying about. At least not until the birthday problem rears its head, but never mind that.