GForge 2020 Released!

GForge 2020 Released!

We’re happy to announce the immediate availability of GForge 2020 (aka 20.0). This is a large feature release and also includes a number of bug fixes.

Highlights in GForge 2020

Zoom Integration – You can now create Zoom meetings and invite project team members to the meeting right from GForge (SaaS only).

oAuth Support – You can now log-in to GForge using your Google account (additional oAuth providers will be coming).

Auto Tagging – When users push commits, GForge will now automatically tag the user, project and ticket with any technologies identified in the commit (e.g. Java, XML, JavaScript).

Code Search – GForge now indexes Git and SVN repositories allowing you to search your codebase right from GForge.

Git LFS – GForge now supports Large File Storage (LFS) for Git repositories.

DKIM Support – For on-premises customers, GForge now supports DomainKeys Identified Mail (DKIM) which adds additional email security and SPAM protection.

The 2020 ChangeLog will help you understand the changes you can expect.

Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.

Download GForge 2020 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Big Changes Ahead for GForge in 2020

Big Changes Ahead for GForge in 2020

With 2020 well underway we are hard at work on a bunch of new features that will take your collaboration to the next level. Before we cover what’s in store, be sure to checkout a recap of the “Top 8 GForge Features from 2019” 

OAuth Support – Not only will GForge support OAuth, over time we will include support services like Google, ADFS and GitHub.

Conferencing Support – GForge will be looking to add support to conferencing solutions like Zoom.us and WebEx allowing you to launch meetings right from within GForge.

Auto Tagging – There’s a lot of information in a commit. In 2020 GForge will harvest information from commits to provide better analytics. For example, a commit including Java, Javascript and SQL changes will add tags with those technologies to both the project and the author. Similarly, GForge will tag individual tickets in the same manner.

Git Improvements – GForge will be adding Git Large File Support (LFS) this year allowing individual files of up to 2GB to be included as part of pushes.

GitHub Migration – GForge will allow you to import projects from GitHub into GForge which will migrate the Git repository and GitHub Issues.

Workflow Improvements – GForge will add webhook support to ticket workflows allowing for deeper integration. Additionally GForge will include support to lock tickets as part of the existing workflows.

Document Thumbnails – Anywhere you add documents in GForge including tickets, Docman, etc GForge will generate thumbnail images you can preview before deciding if you want to download them.

Survey of 2020 Features

Top 8 GForge Features in 2019

Top 8 GForge Features in 2019

It’s the end of February and while we are hard at work adding new collaboration features to GForge for 2020, this seems like a good time to quickly reflect on what was accomplished in 2019. To help set the stage here’s some raw numbers for you!

  • In total we added 138 new features to GForge.
  • 255 bugs were squashed
  • We pushed over 1100 commits

What’s missing in those numbers are the key accomplishments from 2019 so let’s take a moment to cover the top 8 features from last year!

  1. Dark Mode!
Screenshot of GForge in “Dark Mode”

We admit, while Dark Mode adds little in the way of true business value, those who use Dark Mode in other applications and spend a lot of time in GForge will appreciate this.

2. Sprint Retrospectives

Add a Retrospective to closed sprints.

When closing sprints in GForge you can now add a retrospective to document what went well, where problems arose and you can begin identifying the steps needed to make improvements going forward.

3. Automated Release Notes

Import Release Notes with the Click of a Button

When you close a release you can import a table of all closed tickets in the release and then edit the Release Notes before publishing them.

4. Service Desk

GForge Service Desk in Action.

We added the ability for you to add user groups to your projects. In addition to making access control easier, this means you can now use GForge as a Service Desk solution complete with email integration.

Other Key Features

In addition to the highlights above, there are a few other features from 2019 worth noting.

  • Authentication Improvements – Last year GForge added SSO support along with the ability for GForge admins to moderate new user accounts even when using LDAP or SSO.
  • Offline Installations – Need to collaborate on projects inside a protected network without outbound internet access? GForge now supports offline installs and upgrades.
  • Portfolio Management – You can now organize all your GForge projects to match your organizational structure. Not only does this improve analytics, now when you assign users to organizational units they will only have access to private projects within their organization (public projects are still accessible).
  • Subversion (SVN) Improvements – GForge now allows you to restrict access to specific paths in your SVN repository on a role-by-role basis. We also added code review support for projects using SVN.

As excited as we are about what we’ve accomplished in 2019, 2020 will bring a lot more collaboration features to the table. Whet your appetite by reading the “Big Changes Ahead for GForge in 2020”.

Use GForge Now with a Free Account!

Download GForge Now!

GForge v19.2 Released!

GForge's new Dark ModeWe’re happy to announce the immediate availability of GForge v19.2. This release includes three dozen new features and a number of bug fixes.

Download GForge v19.2 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Highlights in GForge v19.2

Dark Mode – GForge is joining the Dark Mode fray!

Project Groups – Project leads can now create groups of users and assign them a project role. Prior to this release only GForge admins could create groups.

Service Desk – With the addition of Project Groups, GForge can now be used to provide service desk functionality.

Improved Analytics – We’ve been listening and now we delivered. GForge now includes better analytics for better managing your projects and overall project portfolio.

Automated Release Notes – This version of GForge provides improved release management. Now when you complete a release you can, with the click of a button, generate release notes.

Better Navigation – While we’ve received a lot of positive feedback on getting around in GForge, we’ve answered calls to improve navigation.

The v19.2 ChangeLog will help you understand the changes you can expect.

Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.

Download GForge v19.2 Now!

Why Does Collaboration Software Suck?

Why Does Collaboration Software Suck?

Let’s face it, the collaboration space has no shortage of options. Today’s solutions come in different flavors of SaaS, on-premises or hybrid, all promising you that a few mouse clicks will have you collaborating better. The one attribute most of them have in common is they suck. In fact, many of these solutions actually make collaboration worse. To help you navigate your options, let’s lift the hood and explore many of the common problems with today’s collaboration solutions.

Collaboration software shouldn't suck. Learn about some common problems to avoid.
  1. You Get Pieces & Parts 
  2. Too Small or Too Big, Won’t Scale 
  3. Who’s Working for Whom?
  4. Comments <> Collaboration
  5. They’re Expensive
  6. Golden Handcuffs 

You Get Pieces & Parts

Let’s face it, as a business grows so do your needs. This transition happens slowly and before you know it you look down to discover you have lots of little solutions each itching a single scratch in helping you collaborate better. Worse yet, navigating between those tools is often painful. In the best case the integration features adds even more buttons to an already complicated user interface. In the worst case you will have to manage a bunch of bookmarks to get to specific features. 

On the subject of user interfaces, today’s solutions are all over the board. Geek-centric solutions might make your IT teams happy, but could alienate your project managers, product managers and upper management. Some solutions create busy-work for team members so that management can have pretty reports.  Other solutions are too enterprise-y, trying to be everything to everyone, but making everything more complicated instead of more efficient. Their lack of focus makes the user experience painful – with too many links, buttons, and tables, all competing for your attention.

Finally, the lack of a comprehensive feature set makes portfolio management difficult, if not impossible. Some solutions focus on work (tickets, issues, tasks), some focus on the process (kanbans, CI/CD integration), and others focus on people (chat).  But what about the bigger picture?

  • How many projects do we have in flight? What’s the relative health of those projects?
  • Have we spread our valued team members too thin? 
  • How do I find quickly find what I’m looking for? How about searching all the things (projects, users, tickets, documents)?  Centralized searching isn’t something you can do without… – yep, you guessed it – buying another tool. 

Next, let’s discuss the insanity of help desk solutions. It’s common for projects to deliver solutions to customers who need access to a support team. Isn’t a ticket just a ticket? Why do vendors try to upsell a separate help desk solution? Under this model, if a customer raises an issue that requires remediation by your team you end up with two tickets: one ticket in the help desk solution and another ticket in the collaboration solution. In most cases there is no inherent association between the two.

Now let’s think about turnover. When someone leaves your organization, how easy is it to revoke their access? Even if you’ve identified the replacement for a departing team member, reflecting that change in multiple projects can be cumbersome. And, once again, if you’ve been upsold both of those processes become harder.

The final point worth considering is discoverability. This may sound ridiculous, but many solutions don’t allow you to specify who is able to discover a project in the first place. If you are doing real portfolio management then knowledge sharing is critical, and you should be able to specify who can discover projects. Similarly, you should have a way to explicitly limit discoverability to certain projects. 

Too Small or Too Big, Won’t Scale

Not all projects are created equal. Say that again: not all projects are created equal. In a world where organizations have dozens or even hundreds of projects, in various phases of development, support and retirement,  it’s important to be able to scale up or scale down features without the headache of buying more seats or finding a new solution.

Then there’s the SaaS/Cloud versus on-premises discussion. That decision should be yours and your choice shouldn’t make deployment and management any harder. There’s no shortage of on-premises solutions, yet many require painful, complex installation and upgrade processes. Given the critical role collaboration solutions play, getting them up and running (and keeping them up-to-date) needs to easy. Many of these solutions cannot be installed at all without  an internet connection for the server. This means installing a collaboration solution on your super secure network will be difficult if not impossible.

Then, once you are up and running, how do you control access to your projects? Access control varies greatly between collaboration solutions. Large projects often have large teams, with technical, management, and stakeholder members, each playing a role in successful delivery. Believe it or not, some collaboration solutions don’t allow you to define your own roles, instead, imposing a set of roles often giving users access to either too many or too few features. Roles are a key in any real collaboration solution and are often reusable, specifying the level of access users have. And even if you can specify roles on your project, if you’ve been upsold you may well be stuck having to manage access to each upsold feature separately.

This is where the tools start to run the team. What started out as only a ticketing solution soon includes a wiki, chat, help desk and next thing you know, you are looking at a bunch of tools, held together with duct tape and web hooks, none being the authoritative source of your precious project data, and all individually imposing different ways for you to get your job done. When will this nonsense stop?

Who’s Working for Whom?

That question may sound absurd but, yes, we are asking that question with a straight face. Are your tools working for you or you having to bend to their will? To illustrate, let’s start with something as basic as ticketing. Tickets are the atomic unit of work by which things get done. All your planning, distribution and tracking of work happens through tickets. In fact, most of your collaboration will be centered on the best ways to deliver the work outlined in a ticket. So why do so many systems get the most important, fundamental needs all wrong? Let’s answer that by identifying common shortcomings of many collaboration tools:

  • Duplicate Tickets – When creating a ticket should the system let you know you may be submitting a duplicate? Furthermore, shouldn’t the system give you hints that maybe the problem or goal in a ticket has been addressed already on sites like StackOverflow?
  • Batch Updates – Updating multiple tickets in batch should be easy to do. Yet many systems either don’t allow for this or make this far more difficult than it should be.
  • Quickly Adding New Tickets – In the planning phase, it is common to create multiple tickets at once all within the same milestone or sprint. Most systems require you to rekey many of the same pieces of data instead of using sane defaults.
  • Ticket Types – While the distinction about tickets is important (e.g. user story, epic, task, bug), adding flexibility shouldn’t slow the team down or make things more complicated..
  • Imposing Workflow – Workflow can help teams stay on track and handle tasks in a consistent way.  But your ticketing solution shouldn’t force a specific workflow on your team..
  • Dependencies – Dependencies between tickets is common. Solutions should make establishing blocking/non-blocking or parent-child dependencies easy and obvious.
  • Spam – Getting notifications that a ticket, sprint, epic or milestone has been changed is great, but do you really have to get a separate email for each update? Solutions should provide the option of receiving daily digests. 
  • Ticket Previews – Because the work in tickets can be a part of any milestone, release, sprint, etc you often need to know more detail than just the ticket number and summary. Yet, surprisingly, many solutions don’t give you ticket previews everywhere and every time tickets are referenced.

Comments <> Collaboration

Repeat after me: “Comments aren’t collaboration”. Don’t get me wrong, commenting on a ticket, wiki page, or document aids in collaboration but it isn’t true collaboration. That’s why we’re seeing all sorts of chat solutions rushed to market. Chat solutions are great and often serve as the central hub of any successful project. Here again, the upsell issue bites us but in the case of chat, it is exacerbated. Chat conversations give concise context and often include references to key project artifacts (tasks, support tickets, documents). For those exact reasons, chat should be a foundational and well-connected component of any real collaboration solution, not an upsell. For example, with an upsold chat solution, when you add a new team member you also need to manually give them access to the corresponding chat rooms or channels. And remember that problem about centralized search? Did a teammate answer your question inside of a ticket, wiki or in the chat channel? Shouldn’t a real collaboration solution answer that question for you? Why should you have to run the same search in different places?

They’re Expensive

A common problem with many collaboration solutions is that their base functionality has a high price tag. And despite that high initial cost, they have a limited scope, implementing only a few well thought out features. Make no mistake, this is on purpose – vendors use this approach to get you to spend more money. They accomplish this in one of two ways:

  1. The Vendor Upsell –  Do you want to add a chat solution to that fancy ticketing system you bought? They have an app for that. Oh, now you want some sort of documentation/wiki solution? Yep, get out your checkbook. The problem with vendor upsell is it often creates more problems. On top of having to negotiate a new contract for each product, you are now on the hook for keeping all your shiny, new tools integrated.  Now this integration may not be an issue if you are all in on cloud-only solutions but as soon as you bring any of those solutions in house you are stuck with keeping them connected. 
  2. Marketplace Ecosystem – Some collaboration solutions get around their lack of features by offering a marketplace where third parties can offer you solutions that integrate with your vendor of choice. This has all the same problems as the vendor upsell but now you are adding another vendor to the equation which, on top of the pricing issue, it means the integrations are going to be more fragile and any breaks in compatibility puts you at the mercy of both vendors.

Golden Handcuffs

With collaboration solutions playing such a key role in Getting Things Done, the more you use them the more valuable they become. So what happens when you get to a point when you want to make a shift in how you collaborate? 

For example, there are a few reasons an organization may want to move from SaaS to on-prem or vice versa and while it isn’t common, it shouldn’t be impossible, either. And if it isn’t impossible to do, the odds are the work in accomplishing that isn’t trivial. Moves like this should not only be possible but relatively easy to do.

And then there’s our friend “vendor lock-in”. You should never get into a vendor relationship that you can’t easily get out of. The upsell models makes switching out solutions even more costly, time consuming and error prone. Worse yet, if you have independent vendor solutions each itching a specific scratch, then it means those integrations will break requiring more time to keep them in sync.

What’s Irking You?

It isn’t all doom-and-gloom when it comes to collaboration software, but a solution that is right for you NOW may not be able to grow with you in the future. To that end, it’s important to understand where many of today’s systems fall short, and make choices that balance where you are today, and where you want to go. Do you have a collaboration solution driving you crazy? We’d love to hear the reason why your collaboration solution sucks.

GForge v19.1 Released!

Role-based ACLs for Git
GForge supports role-based ACLs for Git and SVN

We’re happy to announce our second GForge release for 2019 is available! v19.1 adds a number of new features and comes with a number of bug fixes.

Download GForge v19.1 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Highlights in GForge v19.1

Role-based ACLs for Subversion (SVN) and Git – GForge now supports role-based access controls for both Subversion (SVN) and Git. This means you can control what areas in your repository users have access to based on their role in the project. In SVN this means you can limit a roles access to certain paths in your SVN repository (e.g. write access to anything in /branches and read-only access to /trunk). For Git this works similarly where GForge allows you specify which specific branches a user has access to.

Code Reviews in Subversion (SVN) – Beginning with GForge v18.0, you could perform code reviews in Git just fine. GForge now supports the same functionality using SVN.

Embedded Video Support – You can now embed online videos in many places in GForge including tickets, wiki entries, project homepages, etc. This support is included anywhere where the GForge WYSISYG editor is used.

Commit Integrity – When it comes to commits GForge tries to stay out of your way. One example is you can associate a commit to any ticket that is part of a project you belong to but the ticket doesn’t have to reside in the same project. While that can be handy, in some cases you need deeper control so in this release we’ve added two features ensuring commit integrity:

    1. There is a new configuration option that will tell GForge to enforce the committer is currently assigned to the ticket associated with the commit.
    2. Another new configuration option will tell GForge to enforce the repository being committed to is the same project the associated ticket is part of.

The v19.1 ChangeLog will help you understand the changes you can expect.

Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.

Download GForge v19.1 Now!

GForge v19.0 Released!

We’re happy to announce our first GForge release for 2019 is available! v19.0 adds a number of new features and comes with a number of bug fixes.

Download GForge v19.0 Now!

Take a tour of GForgeNext!

Getting Started with GForgeNext

Highlights in GForge v19.0

Sprint Retrospectives – For Agile and Scrum teams GForge already lets you create, track and manage the burndown of your sprints. In 19.0 can now assess and reflect on sprints with Sprint Retrospectives. Retrospectives include a report of key metrics and then allow you to provide a narrative to identify what worked well, what challenges you had and come up with actions and ideas going forward.

Tickets: Related Items – A challenge for all teams is reducing duplicated work. When creating new tickets, GForge will now identify related items allowing you to quickly determine if you are working on a problem that has already been identified and possibly fixed. GForge can show its own related tickets as well as possible matches on StackOverflow.

Offline Installation/Upgrades – If you need to install or upgrade GForge in a secure location in your network on a host that doesn’t have outbound internet connectivity GForge now supports offline installations and upgrades.

Moderated LDAP/SSO Accounts – You can now configure GForge to send new accounts registered via LDAP/SSO to a queue where they await formal approval by a GForge Administrator.

Organization – For customers with large project portfolios you can now organize your project into organizations. Organizations also provide the organization a place where they can collaborate across projects inside the organization.

  • The v19.0 ChangeLog will help you understand the changes you can expect.
  • The GForgeNext FAQ will answer most of your questions but don’t hesitate to send additional questions.
  • Just a reminder for customers still running GForge Advanced Server (v6.4.5 and prior) we are planning on officially dropping support in October of 2020. Please feel free to reach out to us for a free consultation on the planning and upgrade paths.

Download GForge v19.0 Now!

GForge v18.1 Released!

Just a little over a month ago we ushered a completely revamped GForge platform dubbed GForgeNext and today we are happy to announce the release of v18.1.  Please remember we have changed our version numbering to reflect the year and the number of the release. Since this is the second release of 2018 this version coincides to v18.1 which should help customers quickly know how many versions behind they may be.

Take a tour of GForgeNext!

Getting Started with GForgeNext

The biggest change in 18.1 is the addition of SVN commit hooks. This means that all customers using both Git and SVN can safely upgrade to this version. For our remaining customers still using CVS we will be adding that support in v19.0 due out the first quarter of next year.

  • The v18.1 ChangeLog will help you understand the changes you can expect.
  • The GForgeNext FAQ will answer most of your questions but don’t hesitate to send additional questions.
  • We are still encouraging customers to reach out to us for a free consultation on the planning and upgrade process. If we don’t hear form you we will be reaching out to all our customers over the coming week.

Download GForge v18.1 Now!

Signs That You’ve Outgrown Github, Part 3: Merges

This is part 3 in a series about the limitations of Github, and how they might be holding your team back from its full potential. If you want to go back and catch up, here’s Part 1 and Part 2.

Go ahead, I’ll wait right here.

Done? Okay, let’s move on.

Today’s discussion is about getting code merged. It’s one of the most fundamental things any software team has to do. If your team is anything like ours, it’s something you do many times every day. It might even be the kickoff for your Continuous Integration/Delivery process, as it is for us.

Reliable merging is the key to getting multiple things done at once

Getting things out quickly is important, but preventing outages from bad code is even more important. You probably want an easy way to review and even test code that doesn’t distract too much from the work you’re already doing.

Once again, Github has a wonderful system for promoting code from one repository or branch to another — the Pull Request (PR herein). In particular, the PR is great for open-source projects where people might want to contribute, even if they’re not members of the main project. The proposed contributions can be examined by the main project member(s) and be pulled in only if they’re helpful.

Typical Github pull request — you can see the code changes and their purpose, all in one place

But like many other Github features, you may find the PR process to be mis-aligned to your needs, in a way that creates a little extra delay and a bit of confusion every time you use it.

Pull Requests 101

For those who haven’t tried one yet, a pull request (PR) is a special kind of task, asking someone to merge a set of changes (commits) from one place to another. In more general terms, you can think of it as promoting a chunk of work from one level to another — such as from a development branch to test and then to production, or from a hotfix branch to long-term-support.

A simple example of promotion — taking a specific change from one environment to another

Because it’s a request, it doesn’t involve any access to the project repository from any non-members. The project team can review the proposed changes and take them, ask for revisions, or ignore them. It’s a great model for open-source or otherwise loosely-coupled groups to share ideas and improvements.

Keep It In One Place

But that flexibility comes at a cost. Pull Requests are opened and managed separately from individual tasks, so you’re basically creating another task to review each task’s work. The open or closed status of each task can be independent of the status of the related PR. Additionally, there’s nothing stopping someone from submitting changes for multiple tasks in one PR, which can be confusing and difficult to review.

For software teams that aren’t open-source, this loose coupling actually creates more process, more overhead, and time thinking that could be spent doing instead.

Ask yourself — wouldn’t it be a lot easier to merge the code as an integral part of the task itself?

Singularity Of Purpose

Let’s start with an assumption — that in order to change your code, there should be a defined reason for doing so.

You’re writing code because something needs to be added or fixed. There’s a use case. A story. A bug. A feature. A customer who wants something. There’s a reason to change what you already have.

You probably also want to do two things with your tasks:

  1. You want to create a plan ahead of time, for which things will be done, by whom, in what order.
  2. You want to keep track of progress as things move along.

Once you start depending on tasks for planning and tracking, you can begin to improve your overall process, reducing the number of steps and the distance between idea and working code. As you do, separate PRs may start to lose their appeal. Asking developers to open a separate kind of ticket to get code merged is a hassle. Allowing them to put multiple bug fixes into one merge is asking for confusion and mistakes.

If you’re delivering code using a well-defined workflow, PRs can actually cause problems:

  • Audit trail — It’s difficult (or impossible) to know later which code changes went with which task.
  • Larger merges — the code review itself becomes much more complicated, since there are more commits, more changes files.
  • All or nothing — If you like the changes for task #1, and for task #2, but there are problems with the tests for task #3, the whole PR is sent back for rework. This means you’re likely sitting on changes for longer.
  • More conflicts — Pretty simple math: (Larger merges) + (All or nothing) = More conflicts.

Since there’s no way in Github to limit the content of a PR, there’s no good way to prevent this kind of behavior. Creating a PR for every single bug becomes a tedious time-sink that doesn’t add value to your day.

Now, you might argue that a Github PR can act as the task itself, and it does — but not really. PRs are only retrospective, meaning that you create one after (or while) doing the work. If you don’t create tasks before doing the work, then you’ll never have any way of planning or tracking progress.

Simplify, Simplify

For most teams, the overlap between tasks and PRs is additional work that doesn’t generate any value. What you really need is a way to automatically detect code changes, review those changes and then promote them to dev, test and production, all as part of the task.

This kind of integration means that you can go back to the task later, understand the intent of the change, and also see the code changes that went with it. Your task tracking becomes a source of institutional memory, so that people can move in and out of the team, or across different features without making old mistakes over and over again.

If your tools are preventing you from improving your process, maybe it’s time to improve your tools.

Come try GForge Next for simple, comprehensive and elegant collaboration.

git support in GForge

GForge provides full support for the git SCM (Source Code Management) tool, in addition to SVN and CVS.

Unlike SVN and CVS, git is a distributed tool where each user has a copy of the full repository in his or her machine. The basic workflow of git involves committing changes against the local repository and sharing the changes via pull and push operations.

Since commits in the local repositories cannot be “seen” by the GForge server, GForge sets up a global, centralized (“bare”) repository where the changes can be pushed to.

Setting up your project for git

To enable git support for your project, you need to be logged in as a project administrator. Get into the “Admin” section of the project, and select “GIT” as the SCM tool. Click the “Submit button”.

This will create a bare git repository in the GForge server. This may take up to 15 minutes, you can check if the repository was created by clicking on the “Git” section in the project. If you get the message “The SCM repository for this project hasn’t been created yet”, you need to wait a couple of minutes.

Once the repository is created, you will see the empty repository in the Git section:

Adding the initial data

At this point, the git repository is empty and is not very useful, so some data must be imported first. You will have to push an existing local git repository into the GForge repository.

For example, let’s assume you have an existing repository with source code in HOME/myrepo:

$ ls -a ~/myrepo
. .. bin conf cronjobs .git languages lib README.txt wwwlib

This is a working directory with the source code and the git repository is stored under the .git subdirectory.

Now, if you want to import this repository into the GForge project, you need to use the git push command, but first, you need to find out what’s the repository location (i.e. what’s the full URI for the repository in the GForge server). In the project, click on the Git section and then click on the Access info page. This wil give you the URI for the repository:

Note that the URI that’s used to clone the repository is the same you’ll use to push the changes.

So, with this information in hand, you can now push your repository to the GForge server:

~/myrepo$ git push ssh://<username>@<gforge_server>/gitroot/gitproject1 master
<username>@<gforge5.vm>'s password: <your GForge password here>
Counting objects: 113, done.
Compressing objects: 100% (104/104), done.
Writing objects: 100% (113/113), 86.39 KiB, done.
Total 113 (delta 51), reused 0 (delta 0)
To ssh://<username>@<gforge_server>/gitroot/gitproject1
* [new branch] master -> master

Note that this will only push the master branch to the repository.

The changes you’ve pushed will now be visible when you browse the repository:

Working with the git repository

Once the repository has some code, users can start working with it. For this, they must clone the repository from the GForge server. This is done with the git clone command as seen on the “Access info” page:


$ git clone ssh://<username>@<gforge_server>/gitroot/gitproject1
Initialized empty Git repository in /home/marcelo/gitproject1/.git/
<username>@<gforge_server>'s password: <your GForge password here>
remote: Counting objects: 113, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 113 (delta 51), reused 113 (delta 51)
Receiving objects: 100% (113/113), 85.51 KiB, done.
Resolving deltas: 100% (51/51), done.

This will create a directory with the project’s name (in this case gitproject1) with a local copy of the full repository.

The basic workflow with git involves 4 steps:

  1. Pulling changes from the GForge repository and updating the code
  2. Changing the source code
  3. Committing changes against the local repository
  4. Pushing changes to the GForge repository

For example, suppose someone has changed a files in their local repository and pushed them to the GForge server. The following describes a typical git session:


~/gitproject1$ git pull
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From ssh://<username>@<gforge_server>/gitroot/gitproject1
70aa173..9450e42 master -> origin/master
Updating 70aa173..9450e42
Fast forward
wwwlib/index.php | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
~/gitproject1$ vi lib/ScmgitPlugin.php
(... edit, edit, edit...)
~/gitproject1$ git commit -a -m "Fixed bug [#16]"
Created commit d1a4acb: Fixed bug [#16]
1 files changed, 1 insertions(+), 0 deletions(-)
~/gitproject1$ vi cronjobs/create_git.php
(... edit, edit, edit...)
~/gitproject1$ git commit -a -m "Fixed another bug [#17]"
Created commit b8b281d: Fixed another bug [#17]
1 files changed, 4 insertions(+), 2 deletions(-)
~/gitproject1$ git push origin master
Counting objects: 13, done.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 777 bytes, done.
Total 8 (delta 5), reused 0 (delta 0)
To ssh://<username>@<gforge_server>/gitroot/gitproject1
9450e42..b8b281d master -> master

Note that when pushing, you usually don’t have to specify the full URI of the repository since it assigns the alias “origin” to the repository you cloned from (in this case, the GForge repository). If this was not the case, you can add an alias for the GForge repository URI with the “git remote” command:

~/gitproject1$ git remote add -m master gforge ssh://<username>@<gforge_server>/gitroot/gitproject1
~/gitproject1$ git remote -v
origin ssh://<username>@<gforge_server>/gitroot/gitproject1

In this case, “gforge” will be an alias for the remote GForge repository, and you’ll just have to specify “gforge” as the URI when pushing the changes:

~/gitproject1$ git push gforge master

Now, when you browse the git repository in the GForge project, you will be able to see the commits you’ve just pushed to the server.

Integration with GForge trackers

You may have noticed in the previous example that when we committed, the commit log included the special marker “[#16]”. GForge parses the commit logs and, whenever it finds such a string, it associates the commit with the specified item number, in this case 16.

If you take a look at the tracker item #16 (you can use the quick jump feature in GForge’s top navigation bar), you’ll see the commit information in the “Commits” tab inside the item:

You can click on the “Diff To” link and it will show you a page with the changes made to the file in that commit:

Setting up Access Control Lists

The Access Control Lists (ACLs) provide fine-grained permissions control in the source code repository, allowing you to specify read and write access for the different users in your project to different directories in the repository.

To set up an ACL for a directory, go to the Project’s git admin section by clicking on the “Git” section and then “Admin”. This will enable a new menu item “Edit repository ACLs”. Clicking on this item will take you to the ACL administration page.

To set up a new ACL, click on the “Add new ACL” button and specify the path for the ACL (it must be an absolute path in your source code tree). Once you define the path, you can edit the permissions for the path by clicking on the “Edit permissions” link for the ACL path. This will take you to a page where you can define the individual read/write permissions for each user in the project:

Whenever a user tries to push changes in a directory with read-only access, he will get an error message:

gitproject1$ git commit -a -m "Fixing stuff"
Created commit 1d32486: Fixing stuff
3 files changed, 3 insertions(+), 0 deletions(-)
gitproject1$ git push
<username>@<gforge_server>'s password: <your GForge password>
Counting objects: 13, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 690 bytes, done.
Total 7 (delta 4), reused 0 (delta 0)
User <username> doesn't have write access to /lib in the repository
error: hooks/pre-receive exited with error code 127
To ssh://<username>@<gforge_server>/gitroot/gitproject1
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://<username>@<gforge_server>/gitroot/gitproject1'

In this example, the user has write access to the repository but the access to the /lib directory is read-only, as shown on the previous screenshot.

Setting up commit filters

The commit filters are custom scripts that run when a push is done against the repository in order to do code checks and any other action you want.

To define a commit filter, you need to be a site-wide administrator. On the Admin section of GForge, click on the SCM commit filters link under the Plugins tab. This will take you to a page where you can define the filters.

To add a new filter, click on the Add new SCM commit filter button. This will ask you for three things:

  1. Filter for: Whether this filter will be available for CVS, SVN or git repositories
  2. Description: A short description on what this filter does (e.g. “Check for Windows-style line breaks”)
  3. Command: The command to execute when a push is done against the server. This needs to include the full path to the script in the server and any additional parameters.
    There are three special parameters that are defined by GForge which you can add in the command line:

    1. $PROJECT: The UNIX name of the project (e.g. gitproject)
    2. $PATH: The full path to the repository, usually /gitroot/<project_name>.
    3. $FILE: (Not used in git)

Once the script is set up, you need to enable it in your project. Go to the project’s git admin page and click on the Edit commit filters link. In there, you can use the checkboxes to select which filters will be applied in your repository.