Re: Go Branching/Merging


OK, I see. I will try this for the next feature I take on. Thanks.

Trevor Conn
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Round Rock, TX USA

From: edgex-golang-bounces@... <edgex-golang-bounces@...> on behalf of Drasko DRASKOVIC <drasko@...>
Sent: Friday, March 16, 2018 3:05 PM
To: Conn, Trevor
Cc: edgex-golang@...
Subject: Re: [Edgex-golang] Go Branching/Merging

Hi Trevor,
forkflow should be following:
- Fork the edgex-go repo (it will be then present in tsconn23/edgex-go)
- Go to the $GOPATH/src/ (my example:
- Remove official edgex-go repo, and clone your fork here: `git clone`
- Now all paths are correctly set relative to $GOPATH, and you can
work in your fork
- Wen you need to push to master, you will automatically push to your
fork. Just remember to sync it to upstream edgex-go repo previously:

Best regards,
Mainflux Author and Technical Advisor | Industrial IoT Cloud
Engineering Division | Paris, France

Twitter: @draskodraskovic

On Fri, Mar 16, 2018 at 5:03 PM, <Trevor.Conn@...> wrote:
Dell Customer Communication

There’s been a lot of talk recently around how we manage commits and commit
messages in GitHub to make the history more clean. While in Portland earlier
this week, I described to Tony and Jim a challenge in my workflow which will
prevent the desired cadence around git merge check-ins. I have attached a
diagram showing how my feature work progresses.

Note that I am following the recommended procedure of creating my own fork
from the edgexfoundry/edgex-go/master and not doing my feature work in a
branch of the master. This means that if I make a change in the following
file, for example:


In order to expose that new functionality, I then have to change the import
path in $GOROOT/src/ like

From: import “”

To: import “”

If I don’t do this, my new functionality is unavailable. Rather than manage
this on a file by file basis, my first commit always consists of a mass
find/replace of the given paths in ALL files so that my fork is internally
consistent. The same is true in the reverse, prior to commit back to master.
However since my new changes are not in


I cannot actually build locally before committing and creating a PR. I have
to rely on CI/CD to ensure the build is good.

Given the above process, and assuming everyone is working from a fork, I
don’t see how we will avoid these find/replace commits. If you see something
I’m doing incorrectly or otherwise outside of best practices, let me know.


Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech


Round Rock, TX USA

EdgeX-GoLang mailing list
EdgeX-GoLang mailing list

Join to automatically receive all group messages.