I had just implemented GIT Version Control for a Team of three people. We are managing to pull/push/fetch etc to our bitBucket repository. My only concern is how I should push live after we make an update to the repository.
On another server, I wrote a shell script to clone the repo into a directory so I would be able to test, but on the live server I cannot do the same since on some occasions I just have to push one file only.
Please note that our live server is inside a network and not accessible over the internet (thus I cannot use BitBucket's push service).
The only advise I can give is to make sure that the local repository (which concentrates changes from the developers) is up to date and in shape before pushing.
Locally you can define your workflow. Perhaps the master repo, into which only official commits are taken, branches for each developer's work once it passes local tests, and each one does as they please on their machines. Or something fancier. There are suggestions on workflows, ranging from almost centralized to completely distributed, check them out. If you adopt one way of working, git won't stand in your way if you decide later to change it.
Related
I'm part of a team of 3 (2 developers and 1 designer) who sometimes work in the office and sometimes remotely and I'm looking at a way of using GIT to develop our websites seamlessly. I've got a managed account with Rackspace and have 3 servers setup on the account - development, staging and production.
I'm looking at the best way for our team to develop daily on our websites without having to FTP the files up to the server each time we make any changes. I've used SVN in the past but i'm looking to use Git for version control. The workflow I had in mind for an example website called 'test' was the following:
Development Server would have a directory (called trunk but not sure if it should be called something else?) for each user as well as a central directory. E.g /var/www/test/jbloggs/, /var/www/test/asmith/, /var/www/test/rjohnson/ and /var/www/test/central/trunk/.
The central repository would be installed within /var/www/test/central/trunk/ and then /asmith/, /rjohnson/ and /jbloggs/ would clone the trunk which would mean they would become /var/www/test/asmith/trunk, /var/www/test/rjohnson/trunk/ and /var/www/test/jbloggs/trunk/.
Each user would then have a copy of /trunk/ which will contain all the website files, will all have a subdomain configured i.e jbloggs.test.development, rjohnson.test.development etc and will configure their IDE to automatically SFTP to the server so that they are working directly within their directory the development server. The central directory domain will be test.development. When they come to committing any changes to the central repository they will SSH into the server and commit their changes and when we want to update the central repository we will pull these changes to get the latest version which can then be viewed at test.development.
Is this the right method of doing things or should we all have a local LAMP stack installed (apart from the designer who uses Windows) and have our repositories locally? If so, should the central repo still be on the rackspace server? The developers will be using phpstorm and the designer dreamweaver.
Hope the above makes sense.
Thanks
I strongly advise you to work local and then commit on the shared server. This is what git is made for. Development will be more reactive and easier for everybody. Make sure all dev master git so they can do their internal soup as they want. If one dev destroy the database, the others can keep on working. But you'll also need a convenient way to synch databases so developers work with an up to date local database.
The rest of your chain is ok, you can still have two test step like dev server for dev team and test server for testers. This will make testers working on a more stable version and it will also make you test the upgrade process when you copy changes from dev server to test server. Lot of errors arise because of untested upgrade procedures.
You can updates changes on test and production server either by installing GIT on them or just using a simple script that will ftp changed files. I don't like having git on a production server but this is a personal opinion.
Before I begin, I know there are a lot of questions similar to this one, but I am really having difficulty finding a concise, secure, best practice since the feedback on them has been so widely varied.
What I want to do:
Complete work on my local machine on a development branch.
Push changes to git. Git posts to a webhook URL and automatically has my remote server pull the changes on a development site.
Once QA'd and confirmed to be proper on the development site, push the master branch to the production site (on the same server as the development site).
Where I am at:
I have git installed on my local machine and the remote server. I can push mods to the development branch to git. On the remote server, I can pull the updates and it works like a charm. The problem is that I cannot get the remote server to automatically update when changes are pushed from my local machine.
My questions are:
For the remote server development site directory, should I git init or git init --bare? I don't plan on having updates made on the server itself. I would like my dev team to work locally and push mods to the server. I believe I need to use git init as the working tree is needed to set-up a remote alias to the git repository, but I wanted to confirm.
I am pretty sure the webhook post from git issue is due to user privileges. How can I safely get around this? I have read many tutorials that suggest updating git hook files, but I feel as though that is more drastic of a measure than I need to take. I would love to be able to have the webhook hit a URL that safely pulls the files without adding a boatload of code (if it is possible).
I am a web developer by nature, so git and sysadmin tasks are generally the bane of my existence. Again, I know this question is similar to others, but I have yet to find a comprehensive, concise, secure, and most logical approach to resolving the issue. I am about 16 hours in and have officially hit the "going in circles with no progress" point.
You can do this quite easily with GitHub service hooks.
You ll need to create one more file that will handle the process of performing the git pull. Add a new file, called github.php (or anything you wish ), and add:
<?php `git pull`;
Save that file, and upload it to the repository directory on your server. Then, go to Services Hooks -> Post-Receive URL and copy the URL to that file, and paste it into the “Post-Receive URL” E.g. http://demo.test.com/myfolder/github.php
So, when you push, GitHub will automatically visit this URL, thus causing your server to perform a git pull.
To see this in more details to go to this tutorial
I had the same exact issue, strong in code and development skills, weak in sysadmin skills. When I was finally ready to push code I had to ask a GitHub rep what their suggested method was, and they responded with Capistrano. It's a Ruby application that runs commands (such as git pull) on remote servers, along with pretty much any other command you can imagine.
Here a few articles you can read to get more info:
GitHub - Deploy with Capistrano
How to compile the Capistrano stack on your *nix system
Another example of how to deploy code with Capistrano
Not going to lie, the learning curve was pretty steep, but once you start working with Capistrano, you will see that it works well for pushing code. I develop my applications in Symfony and I have my Capistrano set-up to pull code, clear cache and clear log files, all in one command from my local machine.
I'm trying to learn how to use Git in my daily workflow but I'm slightly confused as to how to make it work for me. As a web developer, the way I work is that I have two VPS' - one as a production and the other as a development server. On the development server, I usually create a webdav that points to the source files (located in /home/public_html/dev.domain.co.uk/) and mount it as a local folder on my mac. This way, I can open (or create) the PHP files in my IDE, do what I need to, save the file and then refresh the test link in my browser.
Now, as I say, I would like to start using Git to keep track of all amends I, and my co-workers, make to projects. So my question is how would I do this - would I create a repository on my development server in the public_html folder? And when I clone the repository on the different machines I work on, would I mount the webdav and clone the repository in there? Ideally I want to set up an online repo that myself and co-workers can access.
Any help and/or advice would be much appreciated.
Thanks :)
I have a similar workflow. I was using my IDE to edit the files over SSH, effectively using the files directly on a development server. What I ended up doing was opening a console over SSH to my dev server, and running git there. I use Bitbucket as a remote, and push/pull from there, keeping all of my changes somewhat centralized. What I need to push to my production server, I pull from Bitbucket, and then flip a symlink so that all files appear updated instantaneously.
Git is a decentralized version control system, meaning that you do not need to have a "shared" repository. However, when collaborating, especially if you do not work closely with your coworkers, it might be attractive to have a central point with an "official" repository.
Now in your case, if you want to continue working in your WebDAV exported folder on your testing machine, it depends on if you share this folder with coworkers or not. If it's your private working space, create your git repository there and work with it however you like.
To setup a central, "official" repository you push you changes to, you have several choices depending on your infrastructure:
Use a 3rd party service like GitHub or BitBucket: This is simple to setup and use, but may require subscription fees if you want to keep your repository private.
Use your development server and setup a clone of your repository in a shared place, either via SSH or WebDAV. This might require more maintenance and you don't get the fancy WebUI of GitHub and the likes.
You might also want to have a look at this article about a branching model for development.
You could use a service like http://bitbucket.org.
it's free and it allows to create private and public repositories.
Once you commit changes, simply push it to the server (they tell you how to do it), then have your partner to clone that repository and pull from it whenever necessary.
I am using the downtime over Christmas to set up an affective development environment and workflow that will serve me well as my business increases. I maily do PHP development..
At the moment:
Local Development
I have NetBeans on my Windows PC. I have Apache, MySQL, PHP, etc. all installed for local development and testing purposes. I have integrated it all with NetBeans, and I have PHPUnit and Git integrated too. It seems to be working great and I now have my own local repository on my PC.
What I plan:
"Master" Repository
I want to have the same sort of development environment on my laptop, so I can work away from the office. My plan is the have a repository on my VPS for each project (at some point, I'll start deploying dedicated repository servers), that I can upload changes at the end of each work session. In the morning, I'll just download them changes into my local repository and upload any work done at the end of the day. This will serve as a sort of "official" project history, and when I work with other developers, they will work with this too.
Production Repository
I want a repository on my VPS, in the "live" area for my applications. I would like to be able to send out approved and tested changes from the "master" repository to this one when those changes are ready, rather than FTPing files.
Am I going the right way about this? Are there any guides to setting up this sort of thing?
Why do you need a production repository at all? For you to actually utilize it, it would have to not be a bare repository, and you cannot push to the checked-out branch of a repository anyway.
I think the better solution is to have a "production" or "stable" branch in your repository that contains whatever you want to be in production. Then you checkout that branch in your production environment. Whenever you want to deploy something to production, you merge it into that branch, push it to your repository, and then in the clone you have on your server, pull.
We have a PHP project that we would like to version control. Right now there are three of us working on a development version of the project which resides in an external folder to which all of our Eclipse IDEs are linked, and thus no version control.
What is the right way and the best way to version control this?
We have an SVN set up, but we just need to find a good way to check in and out that allows us to test on the development server. Any ideas?
We were in a similar situation, and here's what we ended up doing:
Set up two branches -- the release and development branch.
For the development branch, include a post-commit hook that deploys the repository to the dev server, so you can test.
Once you're ready, you merge your changes into the release branch. I'd also suggest putting in a post-commit hook for deployment there.
You can also set up individual development servers for each of the team members, on their workstations. I find that it speeds things up a bit, although you do have some more setup time.
We had to use a single development server, because we were using a proprietary CMS and ran into licensing issues. So our post-commit hook was a simple FTP bot.
Here is what we do:
Each dev has a VM that is configured like our integration server
The integration server has space for Trunk, each user, and a few slots for branches
The production server
Hooks are in Subversion to e-mail when commits are made
At the beginning of a project, the user makes a branch and checks it out on their personal VM as well as grabs a clean copy of the database. They do their work, committing as they go.
Once they have finished everything in their own personal space they log into the integration server and check out their branch, run their tests, etc. When all that passes their branch is merged into Trunk.
Trunk is rebuilt, the full suite of tests are run, and if all is good it gets the big ol' stamp of approval, tagged in SVN, and promoted to Production at the end of the night.
If at any point a commit by someone else is made, we get an e-mail and can merge those changes into our individual branches.
Beanstalk has built-in post-commit hooks for deploying to development, staging, and production servers.
One way to use subversion for PHP development is too setup a repository for one or all three developers, and use this repository, more as a syncing tool, than true version control.
You could,
Make a repo
Add your entire PHP document structure of your project
Checkout a copy of this repo into the correct spot on your dev server
Use an svn hook, that activates on commit
This hook, will automatically update the contents of the dev sever, whenever anybody on the team checks in any code.
Hook resides in:
svn_dir/repo_name/hooks/post-commit
And could look like:
/usr/bin/svn up /path_to/webroot --username svn_user --password svn_pass
That will update your working copy on the dev server to the latest check in.
What about something distributed? You can start for example with Mercurial, try different workflows, and see which one fits you the best.
Each of you could run it locally, or on your own dev server (or even the same one with a different port...).
One possible way (there are probably better ways):
Each of you should have your own checked out version of the project.
Have a local copy of the server on your computer and test it there throughout the day. Then at the end of each day (or whenever), you merge together whatever you are ready to test, and you check it out onto the dev server and test it.
Another tool you can use for the builds is TeamCity which is free for 20 build configurations (enough for most small companies/projects.) This way you can run your tests as well as schedule builds.