I'm not sure if this is #help. Is there a correct, universally accepted better practice? In that case, yes, help me by telling me what I should be doing.
I kind of do both. If it's a relatively small change, I'll just (squash and) merge my local work branch into my local master branch and then push to origin/master, cleaning up my local branch locally. Nice and clean.
For larger changes, or changes that take me more than a session to implement, I push to origin/<branch-name> and then open a pull request. I then use GitHub to squash, merge, and delete the work branch.
This feels a little cleaner and more organized, but it also feels a little silly to "review" and "accept" changes where I was the only person involved.
Ben accepting his own PR, 2020
If there isn't a "one true way", please #discuss your own personal preference! Mods, feel free to de-#help me.
Photo by pine watt on Unsplash
Latest comments (41)
I do this a lot.
Additionally I have setup a ton of type-checker, Dynamic Testing Tools
This helps me judge my code
I protect my master branch, unless my ci says that changes are alright, they don't go to master
I agree it feels kind of silly at times but for me it’s part of learning and building a habit of using git in a “real” workflow. I also do my best to use GitHub issues on public personal projects, just so there is a public record of todo items / bugs on the off chance someone wants to use / fork the project or contribute.
I’m really obsessive over organization though so it might just be me.
Well, I have made it a habit that even if I work on a small change I should create a pull request.It could sound silly to create a pull request where you are the only reviewer but it helps in future. You get another chance to review your code and refactor it.
I usually just close my eyes and push to origin/master. But seriously though, if it's a big change might make a pr.
PR linked with a issue describing the change ♥️
Tools only work if you use 'em!
gasp
If my project get stable enough, I work outside
masterto prevent breaking the master branch itself; then merge online; because web UI tools do help.I use local branching very liberally. Branch, work, branch a branch, debug, merge, finish feature, merge to master, push to remote.
Most of my personal projects only have master pushed to it. Only if I'm "done for now" and haven't completed somethign will I publish the branch.
For personal projects, it's pretty rare.
I tend to make the changes in a branch and push them up to Gitlab. I tend to have some variety of testing that goes on before I can merge the results (Linting, Unit, etc), so even though I'm paranoid and will run those locally it's nice to have a record that 'when I pushed the merge request up the tests ran fine. Not sure why they messed up now.' I do it even for my personal site most time (though i will occasionally start working on something, get two commits in and realize I forgot to make a new branch).