"Whenever you can, share. You never know who all will be able to see far away standing upon your shoulders!"
I write mainly on topics related to science and technology.
Sometimes, I create tools and animation.
git clone will get you the code from a repo so that you can work on it locally, and if you have the push rights, you can even push your changes using
When working on third-party public repos, if you do not intend to change the code, or do not wish to have your changes synced to github, git clone is sufficient. But if you have made changes (let's say you have added comments, if nothing else, for your reference), you'll not be able to have the online (github) version of your changed code, because
git push is disabled for others in public repos.
One way is to
fork the public repo into your personal workspace on github, and then clone it, but then github doesn't allow forks of public repos to be private. Also, if you are not going to be contributing, you may not want to fork the repo.
The next best deal is to do
mirror operations - the former from the public repo to your machine, and the latter from your machine to a newly created repo in your personal workspace. This will, at least, allow back and forth syncing of your code. Let's look at how to do this, and later we'll see how to improve this setup even further.
git clone --bare <public_repo.git>
maintare cloned locally as well, along with
master(unlike normal clone in which they remain remote and are tracked)
--mirrorwith in which all the branches are cloned.
git push --mirror <private_repo.git>
git clone <private_repo.git>This will now get the code from your own repo, with all the tracking set up so that
pushetc. will work.
And now you realize the need to have it on github as your own repo.
git clone <public_repo.git>you got a local master branch, along with remote tracking for all the other branches (since you had not used --bare). Branches keep on getting added and deleted. Before moving our local code to our personal repo, it will be a good idea to remove the references to outdated branches. Remote branches can be seen by firing
git branch -r. We remove the obsolete references by using (inside the cloned repo on your machine):
git fetch --prune
git remote prune origin# origin can be replaced by any remote path
git remote set-url origin <private_repo.git># this pushes to the new origin code from the only local branch you have - master
git push --prune <private_repo.git> +refs/remotes/origin/*:refs/heads/* +refs/tags/*:refs/tags/*
git remote set-url origin <private_repo.git>
git push. If you now go to your private repo on github, it will show no other branch than master. The local git on your machine will continue to have those other refs.
We do not need to do anything else if we don't care about what's happening in the original public repo after we have moved to our private repo. We now work with our own private repo in both github and locally.
But if you do care about the updates in the public repo, and wish to have them synced to your private repo whenever you wanted, these are the steps to be followed.
git remote add upstream <public_repo.git>
git remote set-url --push upstream DISABLE
This will add the public repo as a remote ref named upstream, and will also disable push to this remote ref (not mandatory, but good practice).
Check your remote refs by using git remote -v. You should see something like:
origin <private_repo.git> (fetch)
origin <private_repo.git> (push)
upstream <public_repo.git> (fetch)
upstream DISABLE (push)
After this, whenever needed, you can use these commands to update your local code from upstream (public repo), after resolving conflicts, if any:
git fetch upstream
git rebase upstream/master
Note that on running
git branch -r, you'll see remote refs to both origin (private repo on github) and upstream (public repo on github) branches, but there will actually be no remote origin branches if you implemented Case B above, and did not use the
git push --prune method. This can be confirmed by looking at the branches in your private repo on github.
This means that if you now checkout a remote branch using
git checkout -b <remote_branch_name> origin/<remote_branch_name>, and do a subsequent push (to origin), it will only then push the code and create an actual branch on origin. Not a problem, just something to be aware of.
Or, conversely, if (in Case B), you have not used the
git push --prune method above so that your origin does not have other branches, and now you want to have references to those branches removed from your local git as well, use
git branch -rd origin/<remote_branch_name>.
In either case, on doing
git fetch upstream, your local git will get references to all the upstream branches.