Category Archives: Git

Using a private repo with composer and bitbucket

Setting up composer to use a private repo is pretty easy… after you’ve done it once. There are a few things that can trip you up, such as the naming of the package and the version to include. The docs for getting the configuration set up got me about 95% of the way there.

This guide assumes you already have a composer.json file created, and you’re looking to add a new private repository to that.

Part 1: Bitbucket configuration

Composer is going to need access to your Bitbucket account in order to fetch the private git repo. An OAuth consumer can be used to give composer access.
– In Bitbucket, go to your “Bitbucket Settings” page<username>/

– Click “OAuth”

– Click the “Add consumer” button

– Fill in the name, description, callback URL (this can be anything – composer won’t use it but it is required by Bitbucket), select This is a private consumer, and select Repositories: Read for the permissions.



Part 2: Composer configuration

Using the Key and Secret from the OAuth consumer you created in part 1, you will need to add an auth.json file in composer’s home directory.

 vi ~/.composer/auth.json
    "bitbucket-oauth": {
        "": {
            "consumer-key": "myKey",
            "consumer-secret": "mySecret"


Part 3: Configure composer.json

1) Add your private repository to the configuration so composer can look there for packages. The URL for the repo can be found in Bitbucket by clicking the “Clone” button in the top right of the repository view.


"repositories": [
    "type": "git",
    "url": ""

2) Require the package in composer.json. With either of these methods.
CLI: composer require aerosox/dataconverter
Edit composer.json

"require": {
    "aerosox/dataconverter": "master@dev"



1)  Ensure the package name in the require matches the name from the composer.json configuration for the package you are including.

// composer.json from aerosox/dataconvert

    // even though the git repo is configured as aerosox/dataconverter.git, this name *could* be anything. This is what composer is going to be looking for when it searches for the package to install.
    "name": "aerosox/dataconverter",
    "description": "Convert data formats",
    "type": "library",
    "authors": [
            "name": "Levi Jackson",
            "email": ""
    "autoload": {
        "psr-4": {
            "DataConverter\\": "src/"
    "require-dev": {
        "phpunit/phpunit": "^6.5"

2) I saw a lot of guides say to load the package as “aerosox/dataconverter”: “master-dev”. I initially thought that master-dev was a composer standard, but it’s not. If you want to use that, you’d want to set up an alias in the package so it can be found.

"extra": {
  "branch-alias": {
    "dev-master": "actual-branch-name"

Git Notes – Stashing and Merging

I first started using Git about 2 years ago. Since then i’ve really only ever done minor things with it, pull, add, edit, commit, push, make branches… the basic things. I’ve been spending some time reading about Git and watching Git Essential Training on to better familiarize myself with the things I don’t normally do.


In the past I had merged using ‘git merge –no-ff branch-name‘. I didn’t know what the “–no-ff” flag actually did (just that it stood for “no fast forward”) though. When you do a normal ‘git merge branch-name‘ it will attempt to merge it in as if the branch did not exist (fast-forward). So reviewing the timeline you would still see commits you made, but no reference to the branch. That being said, it only actually does this if the parent SHA value for your commit matches the commit at the HEAD of the branch being merged into.


I hate conflict (in life and coding!). Take the following for example:

<<<<<<< HEAD
if($var == 'test')
if ($var == 'test' || $var == 'test2')
>>>>>>> branch-name

I’ve always looked at this sort of merge conflict as intimidating because of how hands on it is. What the above means is that from <<<<<<< HEAD until the ======= delineator, that is the code that exists in the branch you are merging into. The code from the ======= to the >>>>>>> is the code you are attempting to merge. So you need to either decide at this point that only one is right, or to merge them together and continue onward.

Sidebar: Something that may be helpful to someone is that I was presented with a merge conflict about a whitespace character that git had on the master branch, but not in my file. I removed the whitespace character and proceeded onward. I was then presented with another whitespace character conflict. This time however I removed it and attempted to git add the file only to be told that I had not made a chance to the file. It would not add the file into the list of changes and kept telling me that the file needed a resolution. In this case knowing that the whitespace wouldn’t harm anything I skipped that merge and proceeded as normal.


Stashes are probably my favorite new thing to find out about. If i’m working on some changes, but i’m not prepared to commit them, you can stash them away until you can finish them! As you may have gathered, stashing is when you pull the modified files out of the current branch using   “git stash save “the comment about the files you are saving”.  After you stash files Git runs a git reset hard HEAD  which tosses any uncommitted changes out and resets the files to the HEAD.