Php – Symfony2 – creating own vendor bundle – project and git strategy

bundlegitPHPsymfony

We're considering creating our own common bundle for entity mapping and services for use within few separate apps. A bundle should be easy to modify, run, include and test. I know about Best Practices for Structuring Bundles, but I don't know what git strategy to use when it comes to development.

Should we create common bundle as a whole project and commit whole repository to our git server, or is it better to start source control only for root of common bundle and push only its contents? I see this approach in bundles available on github, but I don't know easy and comfortable way to develop bundles that way.

Best Answer

Create a new empty symfony project

php composer.phar create-project symfony/framework-standard-edition demo/ 2.4.1
cd demo

Generate a new bundle

(for example src/Company/DemoBundle)

php app/console generate:bundle
cd src/Company/DemoBundle/

Init your github repository in `src/Company/DemoBundle`

git init
touch README.md
git add .
git commit -m "initial commit"
git remote add origin https://github.com/YourAccount/DemoBundle.git
git push -u origin master

Add a composer.json file

src/Company/DemoBundle/composer.json:

{
    "name" : "company/demobundle",
    "description" : "A demo bundle",
    "type" : "symfony-bundle",
    "authors" : [{
        "name" : "demo",
        "email" : "demo@company.com"
    }],
    "keywords" : [
        "demo bundle"
    ],
    "license" : [
        "MIT"
    ],
    "require" : {
    },
    "autoload" : {
        "psr-0" : {
            "Company\\DemoBundle" : ""
        }
    },
    "target-dir" : "Company/DemoBundle",
    "repositories" : [{
    }],
    "extra" : {
    "branch-alias" : {
            "dev-master" : "some_version-dev"
        }
    }
}

Now you have the base structure of your bundle

Use it in another project

composer.json:

    [...]
    "require" : {
        [...]
        "company/demobundle" : "dev-master"
    },
    "repositories" : [{
        "type" : "vcs",
        "url" : "https://github.com/Company/DemoBundle.git"
    }],
    [...]

Do:

curl -sS https://getcomposer.org/installer | php
php composer.phar update company/demobundle

app/AppKernel:

new Company\DemoBundle\CompanyDemoBundle(),

Work on it

You can clone your DemoBundle in the src/Company folder, then manually install it
You can use symlink

Conclusion

You can develop and test your bundle in your first project and use it with github and composer in your second project.

Finding the hash

If you have only just popped it and the terminal is still open, you will still have the hash value printed by git stash pop on screen (thanks, Dolda).

Otherwise, you can find it using this for Linux, Unix or Git Bash for Windows:

git fsck --no-reflog | awk '/dangling commit/ {print $3}'

...or using Powershell for Windows:

git fsck --no-reflog | select-string 'dangling commit' | foreach { $_.ToString().Split(" ")[2] }

This will show you all the commits at the tips of your commit graph which are no longer referenced from any branch or tag – every lost commit, including every stash commit you’ve ever created, will be somewhere in that graph.

The easiest way to find the stash commit you want is probably to pass that list to gitk:

gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )

...or see the answer from emragins if using Powershell for Windows.

This will launch a repository browser showing you every single commit in the repository ever, regardless of whether it is reachable or not.

You can replace gitk there with something like git log --graph --oneline --decorate if you prefer a nice graph on the console over a separate GUI app.

To spot stash commits, look for commit messages of this form:

WIP on somebranch: commithash Some old commit message

Note: The commit message will only be in this form (starting with "WIP on") if you did not supply a message when you did git stash.

Git – the difference between ‘git pull’ and ‘git fetch’

In the simplest terms, git pull does a git fetch followed by a git merge.

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads, and is safe to do without changing your working copy. I have even heard of people running git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).

A git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.

From the Git documentation for git pull:

In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.