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

Note: If you’re looking for git support in GForge AS, up to and including 6.4.5, please contact GForge Support for assistance. Documentation for GForge AS is being retired in favor of the current product.

GForge Next 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 a project administrator. In the Project Admin tabs, select “Modules”, make sure that “Code Repository” is turned on, then select “git” as the SCM tool. Click the “Save Changes” button at the bottom of the modules list to update the project.

Screenshot from 2022-10-24 19-28-23

Note: Changing the “Code Repository” setting does not delete any existing repository. The GForge Next UI shows only the active SCM type. Also, switching from git to svn and back to git only re-connects the existing git repository. Nothing is deleted!

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

Screenshot from 2022-10-24 19-34-26

If you repository is brand new (empty), you’ll see the friendly prompt above, with no data. Let’s change that by adding data to your git repository.

git Basics

First, let’s take a small detour to talk about git as a tool. There are lots (and lots and lots) of git commands, and you should be familiar with the basics before tackling the rest of this walk-through – or have a GUI tool that handles the nuts and bolts for you.

GForge Next includes some links to helpful information about git. You’ll also notice the “Get Support” button in the screen shot – don’t hesitate to get in touch with any git-related question, whether it’s specific to GForge Next or not.

Screenshot from 2022-10-24 19-54-15

Cloning git Repositories

The first step in using your project’s git repository is to clone the repository. Every team member who wants to contribute to the repo will do this as well. The information you need is located on the Information tab, in the “Access Your Repository” section:

Screenshot from 2022-10-24 19-41-13

Depending on the site and project settings, your repository might be available via HTTPS (by default) or SSH.

Note: If you have an existing repository, it’s actually even easier to get started. Go into the directory for the existing repo, change the “origin” remote to the URL in GForge Next (with git remote set-url origin <newURL>), and do a “git push” to get everything moved in.

Copy the command from the text box and run it on your own computer (from a terminal, Command Prompt window or add the URL to your favorite git GUI tool). After this, you’ll have a new directory to work in, containing, well, nothing – yet.

Adding the initial data

At this point, the git repository is empty and is not very useful, so let’s add files, create a commit, and push that commit to your GForge Next project repository.

First, you’ll need to checkout a branch, or in this case, create one. Do git checkout -b main to create the default branch that git expects for new repositories. You can use any name you want, but almost all git repositories have a main branch, so it’s useful to observe this convention for others coming to the project.

Create or copy any file you need (e.g., README) into your local copy of the repository (the directory created by the git clone command, earlier), then use git commit -a -m 'First commit!' to create the commit.

Note: The words ‘First commit!’ are completely up to you. There’s no conventional first message for git.

When you’ve built up one or more commits like this, you can push them to the repository, using git push origin main. After a successful push, you’ll see data in the Information tab Activity chart,

Screenshot from 2022-10-24 20-11-02

the new commit(s) will be listed in the Commits tab next to Information,

Screenshot from 2022-10-24 20-11-19

and the changes you’ve pushed will now be visible when you browse the repository.

Screenshot from 2022-10-24 20-11-57

Integration with GForge trackers

You may have noticed this section in the Information page:

Screenshot from 2022-10-24 20-14-24

Using the square-bracket notation in your commit messages (or in your branch name!) allows GForge Next to connect the code changes in your repository to the tasks that caused them. This integration goes both ways – you’ll see links to Tracker Items in the SCM Commits list, and you’ll see the list of related commits in the details for each Tracker Item.

In the Project Admin SCM tab, you’ll also find settings to ignore, allow, or require references to Tracker Items, as well as some similar settings that can be helpful in managing developer workflow, security, and audit.

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 branches in the repository.

Note: This works differently in git than for Subversion, because git branches are physically separate from paths, whereas Subversion branches are paths in the repository. Subversion ACLs are path-based because all repository users will share the same directory structure.

To view or edit the ACLs for your project’s git repository, go to Project Admin, and click the “SCM” tab. You’ll see two more tabs open under it: “Settings” and “Access Control List”. You can add or remove branch names from the list, and change the access level for each role in your project. Users will get the highest access level across any roles they might have.

Screenshot from 2022-10-24 20-19-39

Conclusion

That’s enough to get you started using git in GForge Next. Of course, there are many more features, settings, and workflow options available to suit your process and team’s needs. Don’t hesitate to submit a ticket using the “Get Support” button with any git or GForge Next-related questions.

Happy git-ing!