Re: Go Branching/Merging

Trevor.Conn@...
 

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
Trevor_Conn@...
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/github.com/edgexfoundry (my example:
/home/drasko/go/src/github.com/edgexfoundry)
- Remove official edgex-go repo, and clone your fork here: `git clone
github.com/tsconn23//edgex-go`
- 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:
https://help.github.com/articles/configuring-a-remote-for-a-fork/

Best regards,
Drasko DRASKOVIC
Mainflux Author and Technical Advisor

www.mainflux.com | Industrial IoT Cloud
-------------------------------------------------------------------
Engineering Division | Paris, France

LinkedIn: https://www.linkedin.com/in/draskodraskovic
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:



$GOROOT/src/github.com/tsconn23/edgex-go/core/data/init.go



In order to expose that new functionality, I then have to change the import
path in $GOROOT/src/github.com/tsconn23/edgex-go/cmd/core-data/main.go like
so:



From: import “github.com/edgexfoundry/edgex-go/core/data”

To: import “github.com/tsconn23/edgex-go/core/data”



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



$GOROOT/src/github.com/edgexfoundry/edgex-go



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.



Thanks.



Trevor Conn

Senior Principal Software Engineer

Dell Technologies | IoT DellTech

Trevor.Conn@...

Round Rock, TX USA




_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang
_______________________________________________
EdgeX-GoLang mailing list
EdgeX-GoLang@...
https://lists.edgexfoundry.org/mailman/listinfo/edgex-golang

Join EdgeX-GoLang@lists.edgexfoundry.org to automatically receive all group messages.