This plugin allows use of GIT as a build SCM. Git 1.3.3 or newer is required.

Download latest version 0.5

Bugs

• Current open issues
• Create an issue if needed, and make sure to choose the git sub-component.  Make sure to mention the plugin version number in the issue description.

Changelog

Version 0.6 (In Development)

• [FIXED HUDSON-2931] git tag freezing job execution
• Improve log messages
• Perform simplification and improve performance of the Git plugin, as discussed in the ML: Store build commit hash in a file of the last build directory instead of listing all built tags, and branch defaults to origin/HEAD during checkout(), instead of checking all branches for changes
• Prepend branch name with origin/ to be user-friendly to fix HUDSON-2820
• Use build listener to report messages when pushing tags to origin
• [FIXED HUDSON-2762] Fail to clone a repository on Windows

Version 0.5

• Fix git plugin which was very broken when running on a remote server (magnayn)
• Fix NPE in GitChangeLogParser upon project's first build (jbq)
• Change workspace to a FilePath in GitAPI (jbq)
• Use git rev-list once instead of invoking git rev-parse indefinitely to find last build, see Issue 2469: GIT plugin very slow (jbq)
• Handle null-value of the repositories field to ensure backwards-compatibility with version 0.3,
  ie when the project configuration is missing the <repositories/> XML element (jbq)
• Improve error handling in revParse() (jbq)
• Fix handling of the "branch" configuration parameter (jbq)
• Improve tag handling, use show-ref instead of rev-parse to resolve the tag reference (jbq)
• Fix Issue 2675: Git fails on remote slaves (jbq)

Version 0.4 (never released)

• Allow multiple GIT repositories to be specified (magnayn)
• Allow submodule configurations to be generated on the fly (magnayn)
• Avoid infinite loops when git doesn't contains tags (david_calavera)
• Don't do a log of the entire branch if it's never been built (magnayn)

 Version 0.3

• Add support for pre-build branch merges

 Version 0.2

• Improve handling of git repositories (use local tags to identify up to date versions rather than the wc HEAD)
• Don't have to specify a branch, in which case all branches are examined for changes and built
• Includes a publisher which can be used to push build success/failure tags back up to the upstream repository

 Version 0.1

• Initial Release

Advanced Features

Using Git, Hudson and pre-build branch merging

Continuous Integration tools such as Hudson are useful on projects as they give users early indication that a particular codebase is 'unstable' - and that if a developer checks it out, there will be trouble ahead (they won't be able to work on their own code, because someone else has broken something).

Unfortunately, by the time the build completes, this is often too late (particularly if the build cycle time is very long), as a developer has updated their working copy to the latest, unstable code in the repository and has begun work.

This can lead to the code base remaining unstable as developers tread on each others toes steadily fixing one thing, but breaking something else.

Some environments (e.g. TeamCity) attempt to fix this by making commits into SVN only 'really' happen once they have been tested. These kinds of 'delayed-commits' are problematic, because local SCM tools assume that commits will be immediately available, which can confuse them. In many ways this mechanism is a hack to get around the fact that branch management in SVN is very heavyweight.

Fortunately, with GIT and Hudson, you can achieve the same 'stable branches' with minimal effort.

Set up your hudson project, and leave the 'branch' field in the Git SCM blank. This will cause Hudson to consider any change on any branch for building.

Next, pick a particular branch name as the integration target in the 'Advanced' section - (e.g. 'master', or 'stable'), and select 'Merge before build'.

Select 'Push GIT tags back to origin repository' from the post-build actions (this is required to update your centralised git repo with the results of the build).

Now, developers should never commit directly to your integration branch (the 'master' or 'stable'). Instead, they should either use feature branches, or create new remote branches on commit (e.g : "git push origin HEAD:refs/heads/myNewFeature"). You could also set up your GIT repository to only accept commits onto the integration branch from Hudson.

You're done. Commits should now be automatically merged with the integration branch (they will fail if they do not merge cleanly), and built. If the build succeeds, the result of the merge will be pushed back to the remote git repository.

Using Extra Repositories

Since GIT is a Distributed SCM, it is possible in the Advanced section to specify multiple repositories. You may wish to do this to, for example, pull all in-progress work from individual developers machines, and pre-test them before they are committed to a centralised repository - this way developers may get an early warning that a branch in progress may not be stable.

The GIT plugin will make reasonable attempts to try and pull submodule states from distributed repositories, with the proviso that this feature is not currently well supported within GIT itself.

Autogenerate submodule configurations

A common development pattern for many users is the use of a 'superproject' that aggregates a number of submodules. For example, ProjectA may have ComponentA, ComponentB and ComponentC. ComponentA is a shared library, and is set to use a particular revision (maybe on a branch called 'ProjectA' in case there are any changes). Usually, any changes to the project configuration require a commit to the ProjectA superproject.

However - there could be other changes happening on other branches of ComponentA (say to the development of the next version). Without someone generating commits into ProjectA to test these, any regressions or incompatibilities may be missed.

The autogenerate submodule configurations feature will create commits into ProjectA for all possible combinations of the branches present in the submodules that the project uses.