Go get workflow for forked repo

I am using apex and have installed it with go get github.com/apex/apex/cmd/apex. I have $GOPATH/bin/apex which works great. I wanted to make some contributions to apex, so I forked it and ran go get github.com/ajcrites/apex/cmd/apex. So far so good.

The problem comes when I want to actually test my local changes to the project. There are three issues I can see:

  • Save space when downloading Android source
  • Github commit to tag for version control
  • have composer update get latest version from git repo
  • A system for creating multilingual static websites
  • How can i copy a file from local commit on a different branch?
  • git:// through proxy
    1. Running go build locally doesn’t work because the main.go file imports directly from $GOPATH/src/github.com/apex. I need it to import from $GOPATH/src/github.com/ajcrites for the purposes of testing
    2. Changing main.go manually to import from ajcrites is wonky since I can’t/shouldn’t commit these changes. Moreover even though it does build with my files — I can tell because it lints them — the binary that is emitted doesn’t work at all.
    3. Changing $GOPATH/src/github.com/ajcrites to /apex and building that way does work, but there are two issues:
      • The file system directory doesn’t match the actual repo name which is weird
      • I still want to be able to use the actual binary from /apex without clobbering it just for the purposes of testing local changes

    Is there a recommended way to clone forked go repositories and build/test locally?

  • How are version control histories stored and calculated?
  • extra branches created by git svn clone
  • How to setup a git structure where a submodule requires an external library underneath it?
  • Gitorious branch permissions
  • Is it possible to perform a 'grep search' in all the branches of git project
  • Git pulling changes between two local repositories
  • 2 Solutions collect form web for “Go get workflow for forked repo”

    If you don’t want to change the import paths in your code, or vendor the source in your project, don’t change directory where the code lies in GOPATH. If you want to change the import path, you will need to rewrite that in all the source, or you end up importing multiple versions of the package.

    Go into the $GOPATH/src/github.com/apex/apex directory and change the origin remote to your forked repo. By convention, I also add the original repo as an upstream remote, so I can conveniently fetch and merge changes from there as well.

    Since vendoring is enabled by default since go1.6, you can put the source in a vendor/ directory under your control, and make your modifications there. Using git submodules can also allow you to keep it under separate version control, but linked to your project.

    Here’s the flow I recommend and use for managing the Gorilla organization on GitHub:

    $ go get github.com/gorilla/csrf
    $ cd $GOPATH/src/github.com/gorilla/csrf
    
    # Alternatively, you can git remote remove origin + re-add as SSH
    $ git remote add elithrar git@github.com:elithrar/csrf.git
    
    $ git checkout -b new-feature-X
    $ <do some work on it>
    
    # Install those changes.
    $ go install ./...
    

    That’s it. No need to change import paths in any existing programs. If you’re vendoring the dependencies, you can just change it in the vendored copy.

    Git Baby is a git and github fan, let's start git clone.