0

I have 2 remote server one for production and one for testing So, pushing to production is fine since I push master

    git push production

but after I created a branch , checked it out, made changes, created a new commit and pushed to testing the files didn't change it shows the progress as in 83 files changed and "Everything is now up to date" but the actual files on testing stays exactly the same I trying pushing using these two commands but none of them worked for me

    git push testing newbranch
    git push testing
Hussein Negm
  • 551
  • 5
  • 17
  • Could you include the output from `git remote -v` and `git branch -avv`? I'm having a hard time telling which are remotes and which are branches in your commands. – David Culp Jan 26 '13 at 20:10
  • testing and production are the remotes newbranch is the branch that I am trying to push to testing – Hussein Negm Jan 28 '13 at 17:01

3 Answers3

1

Pushing to a remote doesn't update any files in the sense you seem to be talking about. It only adds commits to the repo. Checked-out files are never updated by a push, which is why it's generally discouraged to push to a non-bare repository unless you know exactly what you're doing, and even moreso pushing to the currently checked-out branch, which it also sounds like you're doing.

If I'm understanding you right, what you should be doing is probably pushing to a "central" repo somewhere, and then pulling from that repo to your production and/or testing environments. A push is never the right way to update files. That's what pull is for.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • Thanks for your answer it some how inspired the solution :) My problem was solved by (on remote) git checkout newbranch I was pushing and the pushing was working but the branch wasn't checked out on the remote so changes were never reflected in files :) – Hussein Negm Jan 28 '13 at 17:08
  • Again: pushing to a checked-out branch won't cause the files to update on the remote and is strongly discouraged. The right way to update the files is to do a pull on the remote. If you absolutely must push, then a `git reset --hard` on the remote will catch you up to the tip of the branch after the push. – Ryan Stewart Jan 28 '13 at 17:25
  • Could you please tell me what could go wrong with pushing or why pushing is discouraged? I do a git reset --hard on the remote as a post-receive hook – Hussein Negm Jan 29 '13 at 08:28
  • Because it can lead to confusing situations and lost commits if you're not aware of what's going on, as detailed in [other SO answers](http://stackoverflow.com/questions/2147741/git-push-only-for-bare-repositories), a [git ready post](http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html), and [an article](http://sitaramc.github.com/concepts/bare.html) written by [sitaramc](https://github.com/sitaramc). – Ryan Stewart Jan 31 '13 at 01:41
0

Ok after some more search this solution worked for me

   git push -u origin newbranch

then I pulled the new branch from the remote server I am not sure if future push will work or not but that got me through for now

more elegant/obvious solution it turns out I was pushing and the push was done successfully as the message "Everything is now up to date" indicated but on remote server I didn't checkout the new branch I checked it out and now everything is the way it should be

Hussein Negm
  • 551
  • 5
  • 17
  • if that works, your remotes are not configured correctly. you should've included the `git remote -v` information in the question, like others have mentioned :) – eis Jan 28 '13 at 06:45
0

you can use git remote -v command to check which is your remote... it will show you the remote servers to which you are allowed to push and fetch..

mrutyunjay
  • 6,850
  • 7
  • 25
  • 35