Git and Jira a branch made in heaven

A Short History of Git

As with many great things in life, Git began with a bit of creative destruction and fiery controversy.

The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.

In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:

  • Speed
  • Simple design
  • Strong support for non-linear development (thousands of parallel branches)
  • Fully distributed
  • Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s amazingly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development

Snapshots, Not Differences

The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as delta-based version control).

Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more as a stream of snapshots.

This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.

Nearly Every Operation Is Local

Most operations in Git need only local files and resources to operate — generally, no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.

For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you — it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.

This also means that there’s very little you can’t do if you’re offline or off VPN. If you get on an aeroplane or a train and want to do a little work, you can commit happily (to your local copy, remember?) until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.

Create a branch for each of your stories

If you’re using Agile for your projects you’ll be familiar with ‘Stories’.

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >.

The title of a story in Atlassian JIRA could be something like this:

WELL-129 DEV - Create Foods, Cosmetics, Medicines GSON Type Adapter Factory

‘WELL’ is the four character abbreviation JIRA gives for the project I created, 129 is the story (auto-incremented) number and the text after the hyphen is my title for the story.

So we clone the Git master (the latest working version that has been committed & pushed to our remote Git repository)

$ git clone https://github.com/NOTiFY/MyProject

and create a branch called:

WELL-129 DEV – Create Foods, Cosmetics, Medicines GSON Type Adapter Factory

$ git checkout -b 'WELL-129 DEV - Create Foods, Cosmetics, Medicines GSON Type Adapter Factory'

You will now be working on your new branch ‘WELL-129 DEV – Create Foods, Cosmetics, Medicines GSON Type Adapter Factory’.

Where you can create the class which implements the ‘TypeAdapterFactory’

public abstract class CustomizedTypeAdapterFactory<C> implements TypeAdapterFactory {
    // Code .....
}

Once you’ve tested the CustomizedTypeAdapterFactory class you can add it to Git, commit it and push it to your remote master. Merging the changes and resolving any conflicts.

Once all the tests have completed successfully on the hosting server you can delete the branch ‘WELL-129 DEV – Create Foods, Cosmetics, Medicines GSON Type Adapter Factory’.

$ git branch -d 'WELL-129 DEV - Create Foods, Cosmetics, Medicines GSON Type Adapter Factory'
Conclusion

IMO – Using this method to clone the remote master and create a branch just for the story you’re working on ensures you’ve always got the most recent master or at least a very recent one. It will minimise the number of merge conflicts when you come to push your changes. Also, it will ensure that you are focussed just on the story you’re working on.

References

Pro Git 2: Amazon

Git: local-branching-on-the-cheap

GitHub: https://github.com/

Agile: Mountain Goat Software

Leave a Reply

Your e-mail address will not be published. Required fields are marked *