GIT Remote Workflow

Hey Christoph,

The way Git works, is that you set up and develop the code locally, and then 'push' a new commit to where you are hosting the code (which is commonly github). The designer would then pull down the changes into his own git repository where he can view the updates/changes and merge them with his own changes. Either you or the designer can push the code out to the production server.

Currently, it sounds like you are making changes on the 'live' server, which is what Git is set up to avoid. On small projects it may seem to be a lot of extra work, but it's a very helpful process as well as good development practice.

To further clarify, check out some of the Ruby on Rails videos that show a bit more of the Git workflow.

Hey @Christoph,

I just want to add on to what @Rhys has said. The proper workflow is to have at least two environments:

• Production: the live environment that your users se
• Development: where you write code

(Typical software projects also have test, stage, etc., etc., but the proper workflow will have at least two.)

You write code in a development environment. You commit code and push it to the repository as often as you want. When you are comfortable that it's ready to go to production, you deploy it somehow. (A git pull is the simplest technique, but there are others.)

It sounds like your question is about how to show a designer code before you deploy it. Is that correct? There are two good approaches:

1. Local Development Environment Plus Staging Environment

In addition to development and production, you could have a third environment for staging. You write code on a local server. After you commit and push the code from development to the repository, you would then to a git pull on the staging environment. The designer could view it there.

2. Remote Development

Your development server doesn't have to be on your local computer. It could be in the cloud. The designer can view your development environment in their browser.

The second is my preferred method for small projects. Jim wrote a great blog post about this approach on the Treehouse Blog, Coding In The Cloud. He uses Vim, but you can achieve the same thing with a (S)FTP editor like Coda or Aptana. (Don't tell him I told you that. :~)

Does that help?

Thanks Rhys and Randy! Yeah at the beginning the git concept can be a little confusing and especially for small projects. Andy was right, i do not need the designer to be part of the git. It was just the purpose to show him what i have done, test it and tell about changes. That's how i have been working on the last projects, always directly on the production server.

But i guess you are right. Working locally on this JS Web App should be no problem and pushing the new stuff to the server and then show the designer the changes. Furthermore it would be great practice for upcoming bigger projects.

Additionally i will take a look at the recommended blog post.

Thanks a lot! It is great to get that good feedback!

The workflow basically works like this.

When you make changes to your site:

ST2 -- (save) --> Your testing VM -- (git push) --> Github -- (git pull) --> Production Server

When the designer wants to see your changes ...

Github -- (git pull) --> Their testing VM --> Their browser

In this tutorial from Jeffrey Way he is showing how to push from local project to github and then fromt there to the production server. He is using a php file with a shell script in order to pull the changes on the project. Is that a good approach? What i like about that is, that when i push, it is automatically on my production server too.

Another problem i am facing is, that a lot of times when i try o push changes i get this error:

± git push origin master
To git@github.com:christophrumpel/simpletimtetrack.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to     'git@github.com:christophrumpel/simpletimtetrack.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')

hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I found some comments about that, but most of the time this error belongs to bigger project where are conflicts and there i a need to merge. I have just two files, and i am the only one comitting. This is kind of strange?

Workflow: I don't think you would want to automatically push commits from the repository to production, though. You want to get the code into the repository early and often so you have the changes and the backup preserved. You wouldn't want to wait until you were ready to deploy to production to commit.

(I do have some sites set up to automatically deploy, but I'm using multiple branches in Git for that. I commit early and often to a development branch. Once I'm ready to deploy, I merge all that code into master and then master gets automatically deployed to production. But that's a bit more advanced.)

A shell script is a great idea. That's what I use for my PHP projects. I commit my code to the repository early and often, and then when I'm ready to deploy I manually execute the shell script (with a command like sh deploy.sh).

[duplicate]

Error: It seems that the code on your local environment must not have all the changes from the repository. The hint tells you what command to run.

git pull

Try that and let us know what happens.

I needed to wrtie "git pull origin master" in order to get it work. Seems like now it works. Thanks. I need to spend more time on things like branches.

No i do not want to automatically push commits, but i want when i push something to github (like a new feature i built) that it also change on my server. Isn't that the workflow? I am working locally on new features. When i think one is done, i want to push it to my server in order to show it on the web to my designer. In this case i am not working on something live. The app hasn't been released.

Automatic Deployment: I actually did mean "pushes" there. I wouldn't want pushes to origin master also pushed to production automatically also (unless I were using branches). Imagine you work on a big feature for a couple weeks. Then you finish it and commit locally, but you don't push it to origin master because you don't want to deploy it to production until tomorrow. Then your laptop gets stolen over night. :~(

I would push to origin master when I finish working. Then I would would manually deploy to production when I was ready.

Branches: I wouldn't worry too much about branches yet. That's a great feature for collaborating or for trying crazy experiments, but I'd get really comfortable with the discipline around committing, pushing, and deploying first.

I see your point. Seems like i just have to get used to this kind of workflow. I guess i will try it like you said with manually calling the php script every time i want to pull form the server to Github.

Randy thanks again for the detailed help. I really appreciate that! Cheers

I am sorry but i have another error and just cannot find the answer.

When i ssh connect to my server and then try to clone a github project i get this error:

Initialized empty Git repository in /www/htdocs/w005dcde/simpletimtetrack/.git/
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

So there is a problem with my Public Key. I have tried dozens of approaches, to copy my local public key, i have found on the web but nothing worked.

Am i right that i only need one key i can use locally and on a remote server?

Here's an article on Github about that issue and how to troubleshoot it:

https://help.github.com/articles/error-permission-denied-publickey

You will need one key per computer: it sounds like you need to create one on the server.

I have already been through that guideline. All these things work locally, but not on my server.

Do i have to create a key for the server too? As a result there should be a /.ssh folder on my server in order to create there a key?

Yes, you need to do that on the server also. The server will generate a different key.

@Christoph - Github's recommended method to clone a repository is to use the https method.

Here'e an example of how to clone the Treebook repository on github:

git clone https://github.com/jasonseifer/treebook.git