You create a fork only if you don't have the possibility to push to the repo you fork.
If you can push, then create a branch and work within the same repo: this is much easier to maintain that way.
If you cannot push back (mainly to a repo on GitHub you don't own), then yes, you can:
- fork it (on GitHub)
- clone it
- push it to your GitLab server if you want.
At any point, you can add to your local repo a remote called "upstream" referring to the original GitHub repo (the one your forked) in order to fetch from it and update your own branches based on the up-to-date fetched upstream.
See "Git fork is git clone?" for more.
In your case:
So since I've already cloned this locally from GitHub, then uploaded that clone into my GitLab, I can rename "origin" to "upstream" for the GitHub remote, then use the "origin" alias for my GitLab version?
Yes:
cd /your/local/repo
git remote rename origin upstream
git remote add origin /url/to/your/GitLab/repo
With this I can then pull changes from
upstream
, which would merge them into local, then push toorigin
and I'll be up to date on mymaster
branch?
Yes.
It is important that you don't work on master
directly, since it is a branhes updated by upstream
.
Then I could merge local master into local "ratchet" or other without overwriting new local files?
Then I could merge local master into local "ratchet" or other without overwriting new local files?
I would recommend rebasing the local branch you are using to isolate your new commits on top of upstream/master
:
git checkout myBranch
git rebase upstream/master
git push --force