Hi!

We are a small team of developers that are working on a existing Drupal 7 site. We currently don't have it under version control and would like to start using GIT for that. I don not have a lot of experience about GIT so i would need some help figuring out what to do. I have been looking around and readning a lot of threads about how to setup a GIT repo but i haven't found anything that explains the configuration i want to do.

We have a site that is running on a server (server1), we also have a development server (server2). I would like to ad the code on server1 to version control and have a development and staging branch running on server2. So i need to add the code for the live site to version control and then create a development and a staging branch on the development server.

I would really appreciate a step by step explanation of how to do it.

/ Markus

Comments

Pedja Grujić’s picture

Pedja
Drupal Geek at New Target Inc.
http://www.newtarget.com

masu0105’s picture

Hi!

I have already looked at the documentation, even though i think it is good it didn't help me figure out how to achieve the configuration i wanted.

/ Markus

Jaypan’s picture

I do the following:

1) Download the .gitignore file from a fresh D7 installation (as it's a good .gitignore for Drupal). Save this to the webroot of your server.
2) Navigate to the location in which your git repository will live. On my server, I have a folder at /git. So I would navigate to this folder.
3) Initialize a bare repository at this location. If the repository was to be called 'my_repository', I'd use the following:

mkdir my_respository
cd my_repository
git init --bare

4) Navigate to the webroot of the site on your server (where you saved the .gitignore file), and use:

git init
git add *
git commit -m "initial file commit"
git remote add origin file:///git/my_repository
git push origin master

Note that file:///git/my_repository will have to be altered to match the actual location of your bare git repository, whether that be local or remote.

Now you have set up your central repository, which can be cloned wherever you want. So I clone this to my local computer. Then as changes are pushed to the central repository, you can pull them to the live webroot (or anywhere else). In your case, you would clone the repository to your server 2, and set that up as your testing server.

masu0105’s picture

Hi, and thank you for the response!

I have been trying with different things to setup the central repository and the steps you explain is almost what i have done. One thing that is different is that instead of doing a "remote add origin" and push the changes to the repo i went to the location were i wanted my central repo and made a clone. Like this:

git clone --bare /docroot project.git

Since i will be working with the docroot of the live server i want to be sure that i don't do anything wrong so i will take exactly the steps you suggested just to be sure. But what i still don't understand is how i can make different branches for the different code bases, that is running dev on one branch, stagin on one and live on yet another. What i want is to have the possibility (when i am working on my local computer) to choose to wich branch i want to push the code and not always push to the central repository. So if it is possibly i want the changes pushed directly to whatever branch i choose, without having to go there and do a pull. I have been working on a site hosted by Acquia and there we had the possibility to do that.

Edit: Actually i think the GIT repo i have been working on hosted by Acquia has some script running that is constantly pulling changes from the central repo. Hence every branch dev, staging and live gets automatically updated when changes are pushed to the central repo. Since that is the only GIT experience i have, i thought that was the way it was suppose to work.

Jaypan’s picture

You want to look into git hooks. In particular, the post-receive hook will help you. It's fired after you have pushed files to the repository. You can choose what to do when different branches are committed - ie, check out to different directories.

masu0105’s picture

Ok, i will look into that and se if the hooks can help me. Thanks again!

chri5tia’s picture

Thank you for explaining summing this up so well! When I went to push to origin, I got the error "rejected, fetch first". My repository is on GitHub and I understand that the problem is caused because there is already one commit (automatically generated by GitHub) which doesn't match, which you didn't have to deal with in your set up. If I fetch or pull, won't I just loose all the work I am trying to start version tracking? For myself and others using GitHub as a central repository, what do we need to do between defining the remote and pushing to it? Thanks!

Jaypan’s picture

I don't use Github, so I don't know for sure. I'm assuming it's a new, empty repository on Github. If it is, then the instructions below may cause problems. But here's what I would do:

0) Back up your file system in case something goes wrong.
1) Do a git clone of the Github repository outside your webroot. In other words, into a completely unused folder.
2) Delete any unneeded files in this folder.
3) Copy your entire Drupal filesystem into the newly created folder. Make sure that the .gitignore file is also copied (this can sometimes get missed). You may also want to add your .htaccess file as well, some people like to add it to the repository, others don't.
4) Navigate to the webroot of this folder.
5) Run git add -A . (note the period at the end)
6) Run git commit -m "Initial Drupal file commit"
7) Run git push
8) Copy the .git folder and all it's contents into the webroot of your original folder
9) Delete the folder you cloned from Github in step 1

You should be able to push and pull from your original webroot now.

Nora McDougall’s picture

Thank you for taking the time to post these links!