0

I have git cloned my git remote repository from my web server onto my local machine. After making changes on my local machine I have committed and pushed changes to the web server with the git remote repository, and see that there are changes when I run git status. But the only way I can think of implementing the change is to run git stash. I am sure this is the incorrect way. I have tried git fetch and git merge, but this is the remote repository that I attempting to update with changes from others for production.

git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   test.txt
#

git stash
Saved working directory and index state WIP on master: eb8230d Changes
HEAD is now at eb8230d Changes
imparante
  • 470
  • 7
  • 16
  • what do u mean by accepting changes? do u mean `git pull` ? git `stash` stands for temporary detaching the current state, for example if you have some work in progress and must switch branches – MorKadosh Apr 02 '15 at 15:07
  • Implement changes that were pushed to the remote repository. If I cat test.txt, it is still the old, original file. I don't know if that answers your question. – imparante Apr 02 '15 at 15:08
  • possible duplicate of [Git Post-Receive Hook for Website Staging](http://stackoverflow.com/questions/3838727/git-post-receive-hook-for-website-staging) – Charlie Apr 02 '15 at 15:13

4 Answers4

1

Looks like I needed to run 

git checkout -f

to update the web server to the head of the branch or changes.

imparante
  • 470
  • 7
  • 16
1

I'm guessing what you mean is that the remote repository has a working directory that is a live web site. You want to deploy changes to your web site by pushing those changes to the remote repository and have the changes automatically applied to the working directory, i.e. the live web site.

What you want to do is set up the remote repository with a post-receive hook that will checkout the new files.

Git's defaults are set up assuming that changes in a working directory are important and should not be easily blown away. This is because the defaults are designed for the working directory to be an actual directory where the user is working, making changes, etc. For a repository acting as a live web site this assumption doesn't hold and so the default behavior doesn't work very well.

In particular, pushing to a remote repository will update branches and the git index on that repository but will not make any changes to the working directory. This makes it appear as though there are changes in your working directory which simply undo whatever work was just pushed.

You can take the command you've already found, git checkout --force and put this in a post-receive hook, and any time you push changes the repository will checkout the new files. This blows away any changes you have in the working directory, but presumably those 'changes' will never be anything but the fake changes that just undo the pushed changes. If you ever manually edit anything in the remote repository's working directory you risk losing those edits.

Another option is to have the repository on your web server be a --bare repository, as remote repositories normally should be. Instead of having a working directory that also serves as the live web site, have the post-receive hook script run commands to deploy the web site to another location.

http://krisjordan.com/essays/setting-up-push-to-deploy-with-git

bames53
  • 79,748
  • 13
  • 162
  • 229
  • This is exactly what I was getting at. Did not realize that command blows changes on the web server. Developers are pushes changes to the remote repository, which is the web server. I probably should have done a git init --bare, since the plan was to only accept changes from developers. Was not too familiar with bare repositories, until I read that link. Thanks! We're still in the process of getting everyone on board with using git and not developing on the production website, but so far so good! – imparante Apr 04 '15 at 21:23
1

If you want to manually update the live server through SSH and git commands, you would use 

git checkout -f

If you want your local push to automatically update the remote repository, run the below command on the live server. 

git config receive.denyCurrentBranch updateInstead
rcadby
  • 11
  • 4
0

You will need to have your remote webserver pull the latest commits from the branch it is tracking. this is manually done with git checkout (branchname) and git pull (once on the correct branch).

You can write a cronjob to periodically attempt a git pull, or set up hooks for your repository. This would send a message to your remote webserver every time a commit was pushed up to the repo.

I solved this problem by using a Jenkins server and the ssh-command plugin to SSH in and do a git pull.

The other solution is to add your webserver as another remote. You could do this by typing:

git remote add webserver ssh://<your user name>@<FQDN>:22/path/to/repo.git
git push webserver <branch>
Andrew Meyer
  • 116
  • 1
  • I am not sure if it incorrect, but I have not been making a branch and making changes directly to the file and doing a git commit and git push. – imparante Apr 02 '15 at 15:33
  • 1
    That is a correct way of doing things, provided you merge your new branch back into your master branch. you can do this with git merge . Alternatively you can use a git frontend such as SourceTree fro Atlassian – Andrew Meyer Apr 02 '15 at 15:37