How to push work to my own private repo while still pulling updates from Github?

I'm starting by telling you I'm confused. I know what I think I want to do but I'm not even sure how to go about doing it.

What I think I want to accomplish is to clone a public repo from Github but have that repo be stored on a different machine than the one I'm sitting at.

Or maybe you tell me - ...

There is a public Github repo - a template for a web app (https://github.com/WHMCS/templates-six)

I've tried searching (here, google, github help docs, others) but I think maybe the terminology keeps messing me up and I'm not finding my scenario. Between locals and remotes and clients and repos and forks I've lost my way. Or maybe it's impossible? idk.

I'd appreciate someone explaining how to do this if it can be or, if it's really just simple/basic stuff, then just point out please the right terminology at each end and I'll go back to searching it out.

Or maybe I've really scrambled it all in which case suggest a way to approximate the end result.

Thanks

Git's default behavior already seems to cover most of your requirements. Git is a decentralized version control system, meaning that you can work and version things locally, completely detached from the remote, as you need. Then, you'd only need to periodically sync up, to keep things current.
– Tim Biegeleisen
Aug 30 at 2:08

@TimBiegeleisen Perhaps what you say is true, however getting from A to B does not seem so straightforward. I asked some specific questions. Perhaps you can provide some specific answers or at least pointers in the right direction? If I need to expand detail in the question, please point out what.
– JoelAZ
Aug 30 at 2:25

2 Answers
2

This is actually pretty straightforward with Git. There are many ways to do it; here is what I would do:

git clone git@github.com:WHMCS/templates-six.git

cd templates-six

origin

git remote rename origin github

git init --bare foobar.git

git remote add webserver ssh://joelaz@sharedhost.com:/home/joelaz/foobar.git

master

git push webserver master:master

-f

git branch -u webserver/master

git push

With this setup, whenever you want to get updates from Github, you can git fetch github and then git merge github/master, which merges github's master branch into your own local master branch. Finally, as before, git push sends it to your webserver. You'll have to maintain the code on your workstation (which is probably a good idea anyway), and you'll make changes and fix merge conflicts there before pushing the code to webserver with git push.

git fetch github

git merge github/master

github

git push

webserver

git push

To help you understand what's happening, keep in mind that each of the 3 repositories (Github, workstation, server) maintains its own copy of the code, and it's own copy of any branches. You move code between the repositories by pulling and pushing from the repository on your workstation.

Thank you so much @mkasberg. I'll come back and accept once I try but reading it like this makes good sense now. The one thing I'm still not sure of/clear on - the origin (github) is read only. The clone on my workstation is for making modifications. Therefore later when I pull changes from origin, I may (probably) never resolve all the conflicts. These are my intended changes after all. So will Git be ok with this and later let me pull again the Master branch even though I never resolve all conflicts? Or do I keep my mods on a different branch and push THAT to my web server remote?
– JoelAZ
Aug 31 at 5:00

Yeah, I was expecting that the github repository would be read-only in your case. There isn't any need for you to push your modifications back to github. Don't think of the master branch in github and the master branch on your workstation as the same branch. They are different branches. The branch on your workstation is a branch that was created from the master branch on github, and you can continue to merge github's master branch into your workstation's master branch (i.e. pull) as often as you like, with no need to ever merge your branch into github's branch.
– mkasberg
Aug 31 at 14:13

Also, be careful with the way you're using "resolve all the conflicts". I think what you mean is the code on your workstation and the code in github will permanently diverge (your changes will never be merged back to github). That's different than what it means to "resolve all conflicts". You might have merge conflicts when you pull updates from github (e.g. when you both change the same line). You'll have to resolve these merge conflicts once, and then they will be resolved and you won't have to deal with them again. In resolving the conflict, you can choose to keep your changes.
– mkasberg
Aug 31 at 14:20

If you prefer to name the branch on your workstation something different and push THAT to your web server, you can do that. And you should, if it makes it easier to you to understand. Really, it's an identical solution because branch names in Git have no special meaning (other than convention) and "master" on you workstation need not have any relation to "master" on github.
– mkasberg
Aug 31 at 14:22

Awesome @mkasberg. Thank you so much for laying that all out. It actually makes a lot of sense now. And I like the idea of renaming branches (I would not have thought of that on my own at this stage) to clarify for myself the relationships. Will probably make it easier/more sensible to follow and grok git cli commands. Much appreciated!
– JoelAZ
Sep 2 at 19:06

I suggest that you read the first three chapters of Pro Git. It is free online and covers the majority of commands you need to perform tasks like this. It isn't very long. Just read a little every day and before you know it, you'll be a Git master. Eventually, you will also need to read some in the later chapters about using git on the server.

Appreciate the sentiment though you word it as though I put no effort forth. I actually have read most of that (first 2 chapters and parts of 3rd). Clearly it didn't sink in or make sense as much as I'd wanted the first time through. Hence formulating my question. It's not as though I asked without trying to figure it out. The terminology around Git isn't the most straightforward; agree? I didn't realize that one could push to the web server and still maintain the relationship to the original origin like that. It just wasn't clear so before I bork my website I sought clarification.
– JoelAZ
Aug 31 at 5:06

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

搜尋此網誌

Dfyjkt