Organization of work with git submodules

    Starting to work with git, I almost immediately had a question - how to work with a project if some of its components are updated frequently. A striking example is development using Symfony2 . The framework is updated almost every day, you need to constantly “tighten” the code so that it works with the latest version of Symfony2.

    Under a cat a little workflow on working with a project on Symfony2.

    A couple of days ago, Symfony2 entered the PR3 stage . In this regard, I immediately wanted to play with the latest version of symfony-sandbox , sharpened for PR3. I would like to get a working sandbox with a link to the framework symfony2 and keep it up to date by updating the framework separately.

    To get started, download the current version of symfony-sandbox (you need the PR3 branch):
    git clone -b PR3 github.com/symfony/symfony-sandbox.git symfony2sandbox
    Next, we want the framework to connect as a link. That is, so that it can be updated independently. There are many advantages in this - the main one is that the project can be divided into independent bundles that are developed and tested independently of the projects that use them. Developing with the help of sub-modules ( submodules ) can be made so that different projects will use different versions of the bundles. Simply put - projects become small, as if consisting of large bricks, they are easier to maintain.

    In order to see how this development will look something like this: miam project - in the vendors folder there are plug-in frameworks that live independently of the current project, so they are connected as submodules.

    We do according to the principlesubmodule guide on github .

    That's all - now we have a competently executed project, in which the code of independent components is clearly separated from the code of this project. Now a couple of tricks to work with our project.

    1) Let's say we have free time and we want our project to work with the latest version of the submodule:

    Go to the submodule’s directory
    cd src/vendor/symfony/
    Updating the submodule
    git checkout -f
    After that, we run unit tests, and ensure that they are all “green”.

    2) Let's say someone wants to deploy your project in their local directory:

    First, clone the project
    git clone ... [your_project.git]
    If now go to the submodule directory - we find that they are empty. To restore a complete project, you need to clone the necessary versions of submodules. Go to the root of the project and run the team
    git submodule update --init

    That's all, a pleasant development. A lot of obvious things, but also a little small.

    Also popular now: