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
Top comments (41)
I'm a big fan of making pull requests. Just gives me another view of my changes in Bitbucket/GitHub before I merge it into the master branch. Sometimes I catch things I don't while staring at it in the editor.
I second this.
I love PRs. I use them along with the issues as a public to-do list — for every new feature I create a new issue, create a new branch locally (with the name referencing the issue e.g. i345) and then when I finished I just push the new branch, create the corresponding PR solving the issue and I merge it to master if everything is ok.
Also I'd recommend this workflow to any open-source project. By doing public issues/PRs —even if you're the only contributor— you're exposing your features and creating public roadmaps/to-do lists to anyone who wants to contribute, discuss, etc. You're even encouraging your public to be part of the project.
I usually create one branch for each fix or feature, working alone or in teams. If I'm working alone I just keep everything rebased with the remote master and when I decide to push something, I checkout master, rebase with the branch I was working on and push.
I was curious about why you sometimes push, create a PR and merge your own change by accepting your PR, but I saw that you answered in another comment that you use github actions; what kind of actions are you using?
For the project I'm thinking about right now, I have two: an action that builds and runs my Rust unit tests and another that builds, tags, and pushes a container to DockerHub.
The Rust tests are something I generally run locally anyway, but it's nice to have as a commit hook, and the Docker one is actually really one I only need when pulling changes into
master- it's not really necessary when reviewing a potential PR beyond a sanity check that the deploy will succeed. I'm not actually convinced that either of these are good enough reasons to stick with this workflow.I guess that's convenient because there's some ready-to-use actions out there and you can quickly setup them. At work I don't worry about this because there's a nice workflow using gerrit and jenkins, but if I wanted to setup something like it for my personal projects quickly I'd go for something like what you are doing, or setup some local actions for tests and deployment (I almost always use the second option in my projects)
Exactly - I spent maybe seven minutes total customizing the pre-built YAML on both these actions, which is about how much time I want to spend on CI/CD for a hobby project.
For local actions, I've always just used a Makefile, or NPM scripts when relevant - how do you manage yours?
I used to make a "scripts" folder in each project containing shell/python scripts to make my life easier, but since most of my workflow in personal projects (mostly written in c++) end up only in dealing with dependencies and running tests, I just create a conanfile for the dependencies and write tests using catch2. But github actions look cool, maybe I'll start experimenting with it as well or set some private ci workflow.
Oh wow, first I've heard of conan - definitely going to explore this as I dig deeper with C++. I think GH actions can be used in concert with something like this, yes, I'm generally impressed with the UX.
Thank you!
Personal project? Just me contributing? You better believe I'm working in
master😉I don't really care about how clean my own history is - all I do is trying to keep commits single-responsibility, and commit messages clear enough. I want to emphasize the "try".
I merge all the things. No rebase, no squash, and for sure no self-reviews.
The only thing I do is that when I start working on major features I'll start a new branch called feat-something, this way it's easier to eg. push a quick fix on master and then resume working on the feature...
I'm curious to know why you want to go through PRs?
That makes sense. To me, the benefit of pushing work branches is 1) so that my GitHub Actions will run on the uncommitted code and 2) so that I can pick up unfinished work on a different workstation. I regularly use three different machines to work on personal code, so it's convenient to be able to pull down a branch and get going.
"Self-review" isn't really happening. I just push it through, I already know what I did in the PR.
Ben GitCraken is like this and cross platform
gitkraken.com/git-client
Thank you!
A quick overview of what I found for Linux.
Working (but not the way I want):
Not working on Linux (yet):
currently working on it, not easy, might bailDoesn't support 32 bit windows, Wine and .NET 4.8 do not play nice with 64 bit)Another thing to mention is that gitkraken is made with Electron, therefore is not very performant, at least in Linux.
Arguably, it doesn't matter all that much for it's purpose. I found but kraken years back because it's electron basses and electron was new and shiny.
If performance is 2 seconds of lag and awquaurd nothingness then sure, don't use it. But also its relative to your machine, kernal and distro which is again not equal.
But yes electron takes up a decent chunk of memory on a machine with limited resources, don't run a GUI 😛. I have tested nwjs electron and other native webview based applications, electron is the worst but I still don't mind.
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 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.
It's been a bit dependent on what it is I'm pushing in. For example on my blog, my new blog posts I just push without PR because I feel a PR is a bit overkill for those at this point. But for new features (for example the redesign I'm doing right now) I create a separate branch > PR with description of the changes > squash and merge.
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 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).
I use GitHub. It allows me one final view of the changes before merging/rebasing to the production branch. I don't think of it as silly, more like following good practices.
I also like that it runs any configured actions when you create the PR, before you commit to
master, so you can catch problems one last time.If the changes are big or the commits are too much, I will do PR, if it was small, I will merge. Simple as that.
I protect my master branch, unless my ci says that changes are alright, they don't go to master
gasp