Fix a Git Commit Message Typo

If after quickly typing in a commit you notice a typo, as such:

git commit -m "this is splet wrong"

You can quickly fix this using Git’s --amend flag, as such:

  1. Type: git commit --amend
  2. By default, the vi editor is opened. press a to enter INSERT mode and make changes
  3. Press ESC to leave INSERT mode and save by typing :wq (write and quit), if you accidently made everything 10x worse, you can cancel by typing :q! (quit, ignoring changes)
  4. Your commit now has an updated commit message and you can push as normal

No more embarrassing errors highlighting non-compliance with the absurd and illogical English (or other) written language.

Advertisements

Checkout Specific Git Branches in Composer.json

Composer allows different branches of a Git repository to be checked out for use as a third party library. To do so first add the git repository to your composer.josn file:

 "repositories": [
     {
         "type": "vcs",
         "url": "git@bitbucket.org:org/repo.git"
     }
 ]

 

Now the repository is known, add the branch to the composer.json require section:

"require": {
    "org/repo": "dev-branch1"
}

 

You can even choose a specfic commit:

"require": {
    "org/repo": "dev-branch1#ec457d0a974c48d5685a7efa03d137dc8bbde7e3"
}

 

Examples

As explained on the getcomposer.org website, login details can be provided to access private repositories. For example, using ssh:

{
    "require": {
        "org/repo": "dev-branch1"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "ssh2.sftp://bitbucket.org",
            "options": {
                "ssh2": {
                    "username": "composer",
                    "pubkey_file": "/home/username/.ssh/id_rsa.pub",
                    "privkey_file": "/home/username/.ssh/id_rsa"
                }
            }
        }
    ]
}

 

Or using an SSL certificate key:

{
    "require": {
        "org/repo": "dev-branch1"
    },
    "repositories": [
        {
            "type": "vcs",
             "url": "https://bitbucket.org:org/repo.git",
            "options": {
                "ssl": {
                    "local_cert": "/home/username/.ssl/composer.pem"
                }
            }
        }
    ]
}

 

Or using HTTP Basic authentication:

{
    "require": {
        "org/repo": "dev-branch1"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://username:password@bitbucket.org/com/repo.git"
        }
    ]
}

 

This provides fairly good SSL encrypted security, although it’s a good idea to remove the username & password credentials from the Git repository and instead place them in a file named auth.json within the COMPOSER_HOME directory, as such:

{
    "https://bitbucket.org": {
        "http-basic": {
            "bitbucket.org": {
                "username": "username",
                "password": "password"
            }
        }
    }
}

 

You can also specify HTTP headers directly, which enables our preferred method for stateless authentication, JWT (Java Web Tokens):

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://bitbucket.org/com/repo.git",
            "options":  {
                "http": {
                    "header": [
                        "authorization: authenticated.jwt.token"
                    ]
                }
            }
        }
    ]
}

 

Conclusion

As can be seen from the above examples, Composer enables a flexible range of options in regards to the selection and integration of Git repositories along with their respective branches and versions.

Git Workflow for Sprint projects

It was a surprise to find a lack of clear diagrams for using Git properly in Sprint / Agile / Scrum programming environments. Therefore we thought we would take a moment to plot how we’ve always understood the best practice Sprint git workflow:

Git Sprint Workflow diag

As usual develop is the ongoing central branch, with master being the live, most stable branch which is only merged to via release branches and (when necessary) hot-fix branches for quickly fixing critical bugs on the live system. The key difference being that a new branch is created from develop for each Sprint cycle. Features / stories / tasks (here on known as stories) dished out to team members are then created as branches from that Sprint# branch.

If any stories are not completed within the Sprint timebox (e.g. 2 weeks) their branches can be carried over to the next Sprint as necessary. It should also be noted story feature branches can be merged, for example when a story relies on code from another story in the same Sprint. To do this run from the destination branch:

> git pull origin another-feature-branch

During the Sprint, completed stories / branches are tested and if all’s good a pull-request is created, but only during the Sprint Review at the end of the Sprint are the pull-requests (branches) merged back into the Sprint branch and then at the end of the review, the Sprint branch itself is merged back into Develop.

If a release is to happen after the Sprint (and it frequently should if following agile methodology) then the develop branch is tagged and a new “release branch” created from this tag. It is this release branch which is then merged back to master in what is in effect the release of a new version of your software (along with merging back to develop to keep everything in sync). The master branch can then be tagged to create an official “released” version, this tagging should also happen after hot-fix merges.

As is the general idea with Sprint workflows, a new release can be made after every Sprint (maybe skipping the occasional one if the software isn’t ready).  We usually make these new increments of the .# numbers, so x.1, x.2 … x.25, x.26 etc. Hot-fixes from master lead to  x.x.# increments, so x.x.1, x.x.2 … etc.

Often during release candidate testing minor bugs and tweaks will arise. Major bugs might require the abandoning of the release branch and new sprint work carried out but for quick fixes, a hot-fix branch can be created off the release branch. This hot-fix branch can be merged straight back into the release branch (and shouldn’t effect the release version number once released). 

Modern source hosting environments like BitBucket and GitHub make this whole process nice and GUI based, especially with inbuilt issue-tracking systems, however this can all be done purely from the command line, perhaps tying in with a standalone issue-tracker like TracZendesk or if you want to be really old-school, a simple Excel spreadsheet ;-).

Any questions or comments, please let us know.