Why git? Intro (with change management comparison)

[worksofliam]

The question ‘why git?’ comes up a lot in the IBM i world. My personal answer is usually

you’re an idiot if you’re not using git

But in a more serious environment that would not be acceptable. The first thing you have to realise is that there is a lot of updates to using git. It has a lot of functionality that cannot be simply replicated. Commit history, branches, tags, merges, to mention a few.

A key enhancement you get for using git is the ‘distributed’ model that comes along with it. For example, in a normal IBM i environment, the development strategy can be like this:

In the image above, this shows that developers copy out the source members that they need to change into their own development library and then (hopefully not) force merge them into the production/master development library. This is normal and is seriously bad. There is no history of changes, you could possibly overwrite code that was changed while you were working on your own copy, among over problems.

Here is another example:

Now this is another different instance where Change Management comes into play, which has the pros (barely pros) and the cons. I am basing my knowledge of change management off change management systems I have used in the past.

Pros

1. A change request (CR) cannot pull in a member that has already been checked out in another CR. This means people cannot overwrite each other.
2. Developers are sharing source-physical files, which means memebrs should be locked when they are in-use/open. This means people cannot overwrite each other.

Cons

1. A change request (CR) cannot pull in a member that has already been checked out in another CR. This is annoying, and can cause people to wait, meaning the work won’t get done as fast.
2. Developers are sharing source-physical files, which means memebrs should be locked when they are in-use/open. This is annoying, and can cause people to wait, meaning the work won’t get done as fast.

To solve these issues, we must come back to the distributed model that git provides. A git repository (a copy of a projects source code) is replicated for each developer, which means everyone can work on whatever code they like - without affecting anyone else. This means:

• Code will not be overwritten
• Code will not be locked when someone else is editing it.

It is very common to also have a centralised repo, which means that instead of people pushing and pulling from eachother, they have a central location which they only work against instead - this actually makes it a slight bit easier to maintain different repositories.

[JMARFINK]

But with a CM package like Aldon or Turnover, You can have differing levels of editing. I can perform a clean check out of source A and begin editing. When I am ready, I can promote to a new level and another developer can then checkout the same source from my new level and make their edits. Yes, it takes coordination, but that should be under control of the configuration manager.
It sounds like Git is simply adding another check layer to the process.