But beyond that I have some reservations.  At least for where Git is right now.

That hesitation is from the experience I’ve gained from performing start-to-finish installations of enterprise-class SCM tools including IBM Rational ClearCase and CA Software Change Manager.  What separates these tools from Git (and SVN) is that they address processes and workflows, security and roles.  And the enterprise world is all about that.

A standard installation of Git, on the other hand, is a blank slate.  You can do what you will with it.  Which is great for a developer who dreams of having that flexibility but gives SCM admins nightmares because they usually have to clean up whatever goes horribly wrong.

What allows Git to have a chance of making serious inroads into the enterprise world is that it’s open, relies on standard mechanisms such as ssh and has a hook system that is triggered by actions on a repository.  New functionality can be constructed around the version engine core.

So what exactly does Git need to have built around it?

My minimum set of requirements would include

1. Security and Access Control

Git punts on security and relies directly on the OS/filesystem and transport protocol (git:, http:, or ssh:) to control read and write access to repositories.  And current add-ons such as gitosis only address access at the repository level, not the level of branches, tags, etc.

Implementation of a unified security and a fine-grain access/locking mechanism is an absolute necessity before Git can be even considered as a serious enterprise tool.

2. Integration with the “typical” Development Environment

My experience with Git is with Rails and Mac OS X and Linux.  While this isn’t unusual in the startup world, it’s not the “typical” enterprise development environment.  That instead would be Visual Studio or an Eclipse-based IDE on Windows.

We need to support projects such as

• msysgit – a native Windows implementation of Git
• JGit – a Java GIT library implementation
• EGit – an Eclipse plugin based on JGit

if Git is to gain traction in the enterprise.

3. Repository Visualization

If you have development of even the slightest complexity, having a visual tool to view the branch structure and where commits are located is a necessity.  Some existing GUI interfaces include:

• git-gui (multi-platform tcl/tk)
• gitk (multi-platform tcl/tk)
• qgit (multi-platform Qt)
• GitX (Mac OS X)
• Git Extensions (Windows)

These tools, however, work on just local repositories.  Remote repository branching is only seen if you’ve fetched the information.

An enterprise tool will need to start from any “canonical” shared repository and then add branching information from local developer repositories in order to show the extended branch network.  This would provide a visualization of the development taking place across the organization.

4. Example Workflows

Git doesn’t mandate any particular development workflow.  Even the de-facto standard pull-request method of sharing updates is really a suggestion rather than an enforceable process (unless you’re working under a benevolent dictatorship).

Unfortunately you’re going to find that given n developers, you’ll likely see a minimum of n+1 ways of using a tool.

Example enforceable workflows for common practices including agile development, lifecycle management and deployment need to be created via the hook mechanism and made widely available.  An enterprise SCM team can then use these workflows as a starting point for customizing their Git installation.

5. Simplified Administration

Installing and using Git for a local repository is reasonably straightforward.  Configuring a repository for remote access is a bit more complicated:

• How do I create a bare repository from an existing one?
• Which protocol should I use? git, http, or ssh?
• How do I restrict access?
• How do I add and identify repository users?
• What happens if I need to add a new repository?

And if you have to host any appreciable number or sizeable sets of repositories, you need to start worrying about storage, load, and backups.

So is this at all possible? Can an enterprise-ready tool be built around a Git core?

Absolutely yes.

If you have any doubts, you just need to look at what GitHub has done with simplifying repository creation/forking, security and collaboration setup, and tools for visualizing the development network.  Or how Heroku has made Git a part of the application deployment process.

It’s just really a question of when someone’s going to put it all together for the enterprise.

Merge Conflicts in Git

The root cause of the conflicts is unavoidable in any kind of parallel development: Updates that are made independently may modify the same or overlapping regions of the codebase.  The longer the development remains independent, the greater the probability this will take place.  For a tool that is basically based on branching and parallelism, Git is essentially inviting this “trouble.”  (Rest assured that the benefits are still well worth it.)

As an example, in the course of Insoshi development, we’ve seen merge conflicts arise from

• Merging new edge features into contributions based on an earlier commit
• Applying fixes made against our production code to edge

And I’m sure Insoshi community developers encountered a number of conflicts when applying the new tabbed and AJAX-ified layout against code they’d developed against the original layout.

Here’s a re-creation of a recent merge conflict in the Insoshi repository:

$ git checkout -b edge_merge_example 757bf03d90be14fd393d457ec20455700a5fc751
Switched to a new branch "edge_merge_example"
$ git branch exception_fix 07097a3b5a797b4c3d0e3ba53a0ad98a8861db79
$ git merge exception_fix
Auto-merged app/controllers/people_controller.rb
CONFLICT (content): Merge conflict in app/controllers/people_controller.rb
Auto-merged app/models/person.rb
CONFLICT (content): Merge conflict in app/models/person.rb
Removed app/views/connections/show.html.erb
Auto-merged spec/models/person_spec.rb
Automatic merge failed; fix conflicts and then commit the result.

What Git presents in the event of a conflict that requires manual resolution isn’t any different than what you would see in CVS or SVN:

app/models/person.rb

371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392

      not deactivated?
    end
  end
 
  # Return the common connections with the given person.
<<<<<<< HEAD:app/models/person.rb
  def common_contacts_with(person, options = {})
    # I tried to do this in SQL for efficiency, but failed miserably.
    # Horrifyingly, MySQL lacks support for the INTERSECT keyword.
    (contacts & person.contacts).paginate(options)
=======
 
  def common_contacts_with(contact, options = {})
    # I tried to do this in SQL for efficiency, but failed miserably.
    # Horrifyingly, MySQL lacks support for the INTERSECT keyword.
    (contacts & contact.contacts).paginate(options)
>>>>>>> exception_fix:app/models/person.rb
  end
 
  protected
 
    ## Callbacks

The contents of conflicting lines from the current version and version to be merged are placed inline with the code separated by “<<<<<<<”, “>>>>>>>” and “=======” markers.  It’s ugly and depending on the extent of the conflicts, can be extremely confusing and time consuming to resolve.  Thankfully, the conflicts in this example appear to be easily manageable.  (And without delving back to far into the commit history, the conflict lines in the persons model probably were copied/cherry-picked from one branch to another and then an additional correction was made to one branch).

So for all of the things that Git does right, why doesn’t it offer a better way? The short answer is that it can’t by itself.  It needs help.

Visual Merge Tools

A manual 3-way merge is the way to resolve these conflict.  You’re using 3 versions of a file as the starting points: the version on the branch you’re on, the version on the branch you’re merging in, and their common ancestor.  The common ancestor is used as the base with updates from either of the other two are applied on top of as direct selections or edited combinations at each conflict point.

Visual merge tools provide the interface for processing the 3-way merge and reduce the time and effort required.  You’re presented with the three versions and can easily choose code from any and all of them to resolve conflicts.

If you’ve been using a VCS tool for a while, you’re probably already using a merge tool, either the one that came with it or one that you’ve picked up along the way out of necessity.  If you haven’t used one before, now’s a good time as any to start.

Merge tools that I know about include

• Open Source
  • kdiff3
  • tkdiff
  • xxdiff
• Free from a commercial vendor
  • SourceGear DiffMerge
  • FileMerge/opendiff
  • Perforce Visual Merge Tool (P4Merge)
• Commercial
  • Araxis Merge (Windows | Mac OS X)
  • Beyond Compare
  • Guiffy SureMerge

This is by no means a complete list.  Be aware that some merge tools only offer a 2-way merge or require an upgraded/pro version to perform 3-way merges.

git mergetool

The git mergetool command allows for the integration of those tools into the merge process.  Run after merge conflicts have been identified, it loops through the files that need to be resolved and provides the specified tool with the version information necessary to invoke the 3-way merge.

git mergetool already includes support for a number open source and freely available merge tools: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff.

Support for additional tools including DiffMerge and Araxis Merge can be added via custom configuration settings provided a command-line call exists:

git config --global mergetool.[tool].cmd [command-line call]
git config --global mergetool.[tool].trustExitCode [true|false]

The “–global” flag is used so the setting will apply across all of your Git repositories.

The command line needs to accept the following file variables passed in as parameters:

• $LOCAL – Current branch version
• $REMOTE – Version to be merged
• $BASE – Common ancestor
• $MERGED – File where results will be written

git mergetool will create the versions as temporary files and set the variables appropriately before the tool command-line is executed.

If the tool returns a proper exit code after a successful or unsuccessful merge, then the trustExitCode setting can be set to true.  Otherwise set it as false so you will be prompted as to whether the merge conflicts for a file were resolved.

Performing a Merge with Conflicts

The sequence of commands for a merge using mergetool would be

git merge
git mergetool -t [tool]
git add .
git commit

You can specify a default tool via the merge.tool setting

git config --global merge.tool [tool]

This will allow you to just simply call

git mergetool

Using a Supported Merge Tool

My main machine is a MacBook Pro and since I have Apple Developer Tools installed, I have opendiff/FileMerge installed.  It’s one of the supported merge tools so I can immediately start using it:

git mergetool -t opendiff

For the Insoshi conflict example you’ll see

$ git mergetool -t opendiff
Merging the files: app/controllers/people_controller.rb
app/models/person.rb
 
Normal merge conflict for 'app/controllers/people_controller.rb':
 {local}: modified
 {remote}: modified
Hit return to start merge resolution tool (opendiff):
 
Normal merge conflict for 'app/models/person.rb':
 {local}: modified
 {remote}: modified
Hit return to start merge resolution tool (opendiff):

The FileMerge window for app/models/person.rb looks like

Because FileMerge is now handling the merge for this file, it’s processing all the differences and not just the conflict area.  You can see this on the bottom status:

• status: 12 differences (12 left, 1 right, 1 conflict)

If you haven’t used FileMerge before, you’ll need to do a couple of things that aren’t immediately obvious:

• Drag up to reveal the “Ancestor” pane at the bottom of the window
• Click on the conflict section numbers located between the LOCAL and REMOTE panes in order to select an action

If you complete the merge and save it, mergetool will accept the result.

If you abort and quit out of the merge without saving, you will be prompted if the save was successful.

app/models/person.rb seems unchanged.
Was the merge successful? [y/n] n
merge of app/models/person.rb failed

If you’re in the middle of resolving conflicts in a number of files, this will exit out from the process.  You just need to re-run the mergetool command:

git mergetool -t opendiff

and it’ll pick up with the last unmerged file.

Using a Configured Merge Tool

DiffMerge is available for OS X.  The binary install is simple (the usual copy to the Application folder) and it comes with a shell script so it can be invoked from the command-line.  The minimal command to start a 3-way merge is

diffmerge --merge --result=$MERGED $LOCAL $BASE $REMOTE

The order of the files dictates which pane (left, middle or right) it be displayed in.  The middle pane is used as the editor for the merge and will need to start off with the common BASE version.  You can explicitly set the title of each pane via -t1=, -t2=, -t3= flags if you like (see the DiffMerge documentation [PDF]).

I’ve tested the return code for successful and aborted merge scenarios and found that it returns 0 if the DiffMerge application ran successfully, not if the actual merge was successful.  Git will rely on a comparison between the temporary $MERGED file to determine if any changes were saved.  It will prompt you in the event the file is unchanged.

The configuration settings will be

git config --global mergetool.diffmerge.cmd \
                    "diffmerge --merge --result=\$MERGED \$LOCAL \$BASE \$REMOTE"
git config --global mergetool.diffmerge.trustExitCode false

You need to escape the $’s in the variables otherwise the shell will try the do the substitution before command gets placed in the configuration.

The .gitconfig entries will look like

[mergetool "diffmerge"]
        cmd = diffmerge --merge --result=$MERGED $LOCAL $BASE $REMOTE
        trustExitCode = false

Running

git mergetool -t diffmerge

starts DiffMerge showing the current version in the left pane, the merge result in the middle pane and the remote version in the right pane:

This may be easier for you to use to visualize the merge process than opendiff/FileMerge.

You should see the same basic output from execution of git mergetool with DiffMerge as was seen from opendiff/FileMerge:

$ git mergetool -t diffmerge
Merging the files: app/controllers/people_controller.rb
app/models/person.rb
 
Normal merge conflict for 'app/controllers/people_controller.rb':
  {local}: modified
  {remote}: modified
Hit return to start merge resolution tool (diffmerge): 
 
Normal merge conflict for 'app/models/person.rb':
  {local}: modified
  {remote}: modified
Hit return to start merge resolution tool (diffmerge):

If you’re using Git on Windows, definitely check out these posts on configuring DiffMerge and Git:

• Setting up SourceGear DiffMerge with Git
• Setting up diff and merge tools for Git on Windows

There’s always a few extra things to be aware of on the Windows platform, especially when it comes to passing in command-line arguments in mixed UNIX shell/Windows CMD context.

A few final notes:

• git mergetool saves the merge-conflict version of the file with a “.orig” suffix.  Make sure to delete it before adding and committing the merge or add *.orig to your .gitignore
• A custom merge driver can be configured and set in order to override the built-in behavior of the git merge command.  This could be useful in order to deal with additional filetypes via an external diff/merge tool or if you wanted to invoke a visual merge tool for all merges.
• IDE integrations for handling merges will depend both on the level of integration that’s possible with Git and the merge tool.

$ git branch new_branch

That’s all that’s absolutely required (see the man page for all the options).  And with that you now have a new branch to work on whose starting point is where you just were in your Git repository.

So what can you do with it? Or more to the point, what should you do with it?

For a single developer, you can work on an experimental code path: You’ve got an idea about how a feature should be implemented and want to get started.  But you’ve also got some regular development that needs to take place at the same time (fixes, other features, etc.).  So create a branch and code away:

$ git branch feature_x dev
$ git checkout feature_x
# add/commit... add/commit... add/commit

If the feature code works out, you merge it back into your development branch.

$ git checkout dev
$ git merge feature_x


If not, you just go back to the dev branch and delete feature_x:

$ git checkout dev
$ git branch -D feature_x

Actually, you really don’t have to delete the branch.  You can leave it as is in case you want to easily go back to take a look at that work.

For a team, branches separate each developer’s individual updates.  The distributed nature of Git sets up a default branch structure: Each repository creates a new branch in the extended repository network.

For a set of repositories configured as

the extended branch structure would look like

From your local repository, you’ll be limited to seeing only the branches on the remotes you’re connected to.

For Alice who’s connected to shared and Bob, the branches that her repository knows about are

alpha:alice $ git branch -a
dev
bob/dev
shared/dev

For Bob who’s connected to shared and Alice,

beta:bob $ git branch -a
dev
alice/dev
shared/dev

And for Chris,

gamma:chris $ git branch -a
dev
shared/dev


For a project, a branch could represent a new feature set or version of an application.  Updates are pushed up to an “integration” branch by developers as they are completed.  This is similar to the use of branching by a single developer but on a more formalized, process-driven basis.

In this case, Alice has already merged her changes for Project A into the shared integration branch.  Bob and Chris are still working on their changes and will need to pull in the updates before they’ll be able to push up to shared/integration.

Branches can also be used to represent the application’s lifecycle, with separate branches for each state such as development, test, and production.

This is the ideal case where changes flow from development to test and then from test to production.

These strategies are, of course, only a starting point.  Your actual branching structure will depend on your team and where you are in your application development cycle.  And odds are it’ll evolve along the way.

We’ll be going into more detail in future posts.

From the standpoint of the end result, a merge and a rebase in Git appear to do the same thing:

A + B + A’ (merge) = A + A’ + B (rebase)

Wouldn’t it be simpler to just choose one operation and stick with it?

The answer of course is no.  Otherwise you wouldn’t have the option.  (If you feel completely contrary, best of luck.  And choose merge.)

It really only becomes apparent once your development effort becomes hierarchical, either in terms of application lifecycle (such as dev, test and release versions) or in a team structure.  You’re now dealing with multiple branches, each with non-trivial changes that can and will occur independently.

Rebases are how changes should pass from the top of hierarchy downwards and merges are how they flow back upwards.

Let’s take a look in more detail at what is actually taking place in each operation for a parent branch A and a child branch B:

Merge

A + B + A’ + dA’B

where A’ are the changes being merged in and dA’B the resolution of merge conflicts from A’ and the set of commits B on the current branch

The changes introduced by A’ and dA’B are grouped together into one merge commit A” = A’ + dA’B that is added on top of the existing set of commits (A + B) and becomes the head of the current branch:

A + B + A”

Rebase

A + A’ + B + dA’B

The rebase resets the starting point the branch and reapplies the set of commits B.  Merge conflicts dA’B are combined with these commits so they become grouped together B’ = B + dA’B:

A + A’ + B’

If you stare at it, you’ll realize that the rebase guarantees that the changes being brought it in from the other branch come in exactly as-is: A + A’.  Any conflicts are resolved and contained with the associated commits B’ on the current branch.

Using merge to pull in changes from the higher-level branch mixes those changes with the resolved merge conflicts.  This means that the current branch won’t necessarily have the same state as the one it was based on (from the hierarchical structure).  And since the resolved conflicts are grouped all together in one merge commit, you’ve also made it harder to cleanly cherry-pick individual changes.

Having development lifecycle tracks and each local developer branch start from known consistent states is critical to reducing and resolving code issues.  Where a change occurs (or suddenly becomes missing) and who is responsible become easier to determine.  By using the rebase to pull in changes, you have that.

When you’re submitting changes back up the chain, you only want to add your changes on top of the existing commits of the higher-level branch.  Merge is clearly the operation for that.

Even if you’re a single developer with only a few branches, it’s worth it to get in the habit of using rebase and merge properly.  The basic work pattern will look like:

1. Create new branch B from existing branch A
2. Add/commit changes on branch B
3. Rebase updates from branch A
4. Merge changes from branch B onto branch A

That’s not a bad thing.  It simply means that it’s not any more or any less than what it claims to be: a distributed version control system.  And it’s very good at what it does.

But once you get beyond the initial repository setup and the standard add/commit cycle, you’re inevitably going to have a few questions:

• How often should I commit my changes?
• When should I create a new branch?
• What do I need to do to share my updates?

And these lead to a few more

• How do I manage all these branches?
• When should I merge the changes from my branches together?
• What’s the difference between a merge and rebase?

If you’re working in a team, you’ll probably also have

• What’s everyone working on?
• Do I have the latest updates?
• When do I submit my changes to the team?

And if you’ve been going for a while, you’ll want to know

• How do I simultaneously manage a release and a development version?
• Did that production fix get back into development?
• What did I just release?

At this point, you’re starting to slip into the realm of software configuration management (SCM).  Version control is just a small part of that.

The bad news is that Git doesn’t say anything about how you should do any of this (FYI, the pull request is more a suggestion than a formal required process even if it’s what Linus does).  It’s also the good news: You have all the technical capabilities you need but you’re not tied to a rigid one-size-fits-all process.

The key thing to remember is that Git isn’t the first VCS tool out there, even if it might be the first one you’re using.  There’s an amazing wealth of SCM knowledge to tap into.  It’s a matter of starting with what works and figuring out how Git fits into that.