Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Forking With Go

DZone's Guide to

Forking With Go

Forking and pulling changes into Go projects works a little differently than in languages like JavaScript. Here's how to do it.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

Making contributions to the open source community is fairly easy, as least when it comes to most programming languages. Sadly (or not?), Go is an unusual language and it has to be handled specifically here. Let's take a look on forking and pulling changes into Go projects.

Why Is It Different?

Go stands out from the field in terms of defining relations between packages (called modules in some languages). Unlike, for example, Java Script, all paths to the imports are absolute and not relative. How does it make any difference?

Imagine having a couple of files:

// packageA/fileA.js
module.exports = {
    shout: function() {
        console.log('Aaaaaaaa!');
    }
};

// packageB/fileB.js
var a = require('../packageA/fileA');
a.shout();

Wherever you check such repo out, you can make a change to fileA and see its effect immediately in the other one. With Go, the code is stored in an arbitrary location in your operating system ($GOPATH) and we cannot (easily) have the same project checked out twice. Another problem is that all paths in Go imports are absolute:

// packageA/fileA.go
package packageA

import "fmt"

func Shout() {
  fmt.Println("Aaaaaaaa!")
}


// packageB/fileB.go
package packageB

import "github.com/userZ/projectX/packageA"

packageA.Shout()

If you want to fork the project from GitHub (userZ/projectX) to your own account (eg. myself/projectX), this will mess up all imports. Do we have to change them back and forth between pull requests? Not at all!

Smart Workaround

Unfortunately, Go requires us to do a small trick in order to work on a forked repository. We can use neither

cd $GOPATH/src/github.com/myself
git clone https://github.com/myself/projectX.git

nor

go get github.com/myself/projectX

Instead, we have to trick Go into believing that our newly forked repo is under an original path. First, we need to remove the original one ($GOPATH/src/github.com/userZ/projectX) and clone the fork right in that place:

cd $GOPATH/src/github.com/userZ
git clone https://github.com/myself/projectX.git

How does it work? You now can edit the repository as you like, and whenever you import an original path in one of the source files, Go will actually look on your fork.

Might sound a bit confusing at first, but it is really not that hard. Give it a try!

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
golang ,github ,forking workflow

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}