There are many things you can do; I suspect you are overthinking it.
My usual trick for simple stuff is to git push from the local PC to a new branch on the remote (I use the name 'incoming') ; the ssh in and use `git merge --ff-only incoming` to (the ff-only forces you to detect local changes on the remote machines) to update the working tree.
You could clone to the remote machine `git clone myrepo remote:myrepo` and then to the git pull etc all on the remote machine . I've found when running prod or stating systems it's worthwhile to have a remote bare repo that you push to , and then a separate repo which the project runs from so that's a thing you might want to think about.
You could just `scp -r myrepo remote: ` and again do pulls and merges from the new copy on the remote machine.
The things you mention should work to, but I think I'd only do them is there was a good reason that git / push /pull wouldn't work, if you've got a git repo on the remote machine you don't even need to clone the local one all the was over there if bandwidth is an issue, you can create a second
clone locally on the remote `git clone --bare live staging` and then you can `git push myrepo remote:staging` and do the usual git adjustment from there. Do the clone on the local machine should help reduce your bandwidth needs.
Using git fully, rather than creating a patch helps ensure all the hash/commit id stay the same which helps you be sure the remote code is the same that left your local computer
My usual trick for simple stuff is to git push from the local PC to a new branch on the remote (I use the name 'incoming') ; the ssh in and use `git merge --ff-only incoming` to (the ff-only forces you to detect local changes on the remote machines) to update the working tree.
You could clone to the remote machine `git clone myrepo remote:myrepo` and then to the git pull etc all on the remote machine . I've found when running prod or stating systems it's worthwhile to have a remote bare repo that you push to , and then a separate repo which the project runs from so that's a thing you might want to think about.
You could just `scp -r myrepo remote: ` and again do pulls and merges from the new copy on the remote machine.
The things you mention should work to, but I think I'd only do them is there was a good reason that git / push /pull wouldn't work, if you've got a git repo on the remote machine you don't even need to clone the local one all the was over there if bandwidth is an issue, you can create a second
clone locally on the remote `git clone --bare live staging` and then you can `git push myrepo remote:staging` and do the usual git adjustment from there. Do the clone on the local machine should help reduce your bandwidth needs.
Using git fully, rather than creating a patch helps ensure all the hash/commit id stay the same which helps you be sure the remote code is the same that left your local computer
Statistics: Posted by rgammans — Thu Sep 05, 2024 8:58 pm
