How to version control my Laravel 4.2 project with GitHub

Create a new repository with the + icon in github (usually it's top right somewhere). You can either push up some existing source code, or start a new project from scratch. Do you have any git experience? Git can be used without github, although many (including myself) prefer github's interface over others.

Yes, I've some experience with GitHub, but never tried to create a repository using an framework. How I keep laravel up-to-date? Only using composer update?

@eliaseas - Composer will keep Laravel/Framework up to date (along with any other repos brought in via composer). Normally your vendor folder is git-ignored, so those files would not be kept in your repository.

Yep using composer will keep the framework up to date because it is listed under the dependencies key in your composer.json file

Remember, laravel, the framework, is not your project, it is just a dependency you are using for your project. :)

As others have said, yes you use composer. Just make sure your vendor folder is in your .gitignore!

Here's an example of one of my .gitignore's:

/bootstrap/compiled.php
composer.phar
npm-debug.log
.env.*.php
.env.php
.DS_Store
.idea
Thumbs.db
node_modules
vendor/*
public/vendor/* 
workbench/*

Now, you may not have need to ignore all these things initially, but in general you want to always keep the folder that your package manager (or managers if you're using bower for frontend assets!) uses outside of version control.

Edit: Also something that might be confusing is the composer.lock file. You should keep this under version control. When you run composer update, the composer.lock file is generated and it's purpose is to be able to install that exact same set of dependencies again if you were to say copy the project to a live server. The idea is on the live server you would just run composer install, and it will look at that lock file and install the exact same versions so that you can be sure it works the same as your development system. If you were to do a composer update on a live system, there might be a case where it upgrades/installs a dependency which breaks some feature of your project... hopefully that makes sense!

One thing to bear in mind:

If you use Git as a deployment tool, you may prefer to include the vendor folder. Doing so means that your deployment is not dependent on the availability of your dependencies. It also simplifies the deployment process somewhat.

It seems the general recommendation is to keep vendor out of version control, as it keeps your version control tidier and faster. But there is potentially a downside too.

Mike, I've got to disagree here. If you have your deployment setup correctly, you can just have a post-receive hook that installs the dependencies for you when you deploy. This allows you to keep your vendor folder out of version control. The few minutes it would take to install composer and create a post-receive hook are hardly a downside when compared to versioning potentially thousands of unrelated dependency files.

I agree with @austenc. Storing what could possibly be a large number of files from the vendor folder is not the best practice IMHO. As stated above, it's very easy to deploy to staging/production and automatically run a post deployment composer update.

You're still ignoring the main downside: your deployment is now dependent on that stuff being available. If there's a problem with Github when you deploy to production, then your website is broken.

Then again, it's hard to know how likely that is. I guess it depends how paranoid you are about deployment.

If you actually read my post, you'd see that I'm not even advocating this. I'm just saying there is a potential issue to consider.

No need for everything to be "I agree" or "I disagree". And don't get me started on "best practices". :P

To be clear: I agree that ignoring vendor is probably the right thing to do.

Ignoring vendor is ideal, but you don't need to sacrifice your stability either.

I forget the package, but I had this happen to me a few months back when a project changed ownership and packagist hadn't updated. This killed my composer updates, and therefore my deploy to production.

Luckily I don't deploy using a GIT pull, but instead an rsync to give me some more control.

As follows :

versions/x.y.3
versions/x.y.2
versions/x.y.1
production (symlinked to versions/x.y.3)
production_previous (symlinked to versions/x.y.2)
persistent (all persistent files, e.g. cms_uploaded, symlinked into production folder)

This has some nice simple benefits, but amongst them reverting everything back to it's original state, including those .gitignored. So when composer failed, it didn't update the symlink at the end, and all was well. This may be overkill for some scenarios! But it's very nice when working with ext. deps.

Simply using composer update is not all you need to do (also a terrible idea to do on a production server as pointed out above.)

Laravel is broken into two parts. This is a really high-level overview.

https://github.com/laravel/laravel - is your application. This contains all of your configs, artisan command, bootstrap, etc... It ties the Illuminate Framework together.

https://github.com/laravel/framework This is the actual "framework". When you create a git project using the repo above, the composer installs this and it's dependencies for you.

So in order to keep Laravel updates, you will need to not only "composer update" but you will also need to make sure your app files are updated as well. These don't change much, but sometimes they do.

This seems to be a really common question that even people who have been working on Laravel for a while get tripped up on. Could potentially be a good topic for @JefferyWay to touch on.

It would be definitely a good topic for @JeffreyWay to touch on.