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/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
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.
Senior Principal Software Engineer
Dell Technologies | IoT DellTech
Round Rock, TX USA