DEV Community

Cover image for Do you merge branches locally or create pull requests for personal projects?

Do you merge branches locally or create pull requests for personal projects?

Ben Lovy on February 06, 2020

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 b...
Collapse
 
lehmannsystems profile image
Mike

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.

Collapse
 
pedro profile image
Pedro M. M. • Edited

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.

Collapse
 
rogerzanoni profile image
Roger Zanoni

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?

Collapse
 
deciduously profile image
Ben Lovy

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.

Collapse
 
rogerzanoni profile image
Roger Zanoni

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)

Thread Thread
 
deciduously profile image
Ben Lovy

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?

Thread Thread
 
rogerzanoni profile image
Roger Zanoni

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.

Thread Thread
 
deciduously profile image
Ben Lovy

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!

Collapse
 
stegriff profile image
Ste Griffiths

Personal project? Just me contributing? You better believe I'm working in master 😉

Collapse
 
mjsarfatti profile image
Manuele J Sarfatti

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?

Collapse
 
deciduously profile image
Ben Lovy

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.

 
adam_cyclones profile image
Adam Crockett 🌀 • Edited

Ben GitCraken is like this and cross platform

gitkraken.com/git-client

Thread Thread
 
deciduously profile image
Ben Lovy

Thank you!

Thread Thread
 
dwilmer profile image
Daan Wilmer • Edited

A quick overview of what I found for Linux.

Working (but not the way I want):

  • GitKraken installs, but requires a paid license to use with private repositories. Since I mainly use private Bitbucket repos, this doesn't work for me.
  • GitAhead works, but has very little emphasis on branches. As I'm using feature branches, this does not work well for me.

Not working on Linux (yet):

  • SourceTree (spent several hours to get it to work with Wine, no success yet)
  • Fork (currently working on it, not easy, might bail Doesn't support 32 bit windows, Wine and .NET 4.8 do not play nice with 64 bit)
Thread Thread
 
sanchocreativo profile image
sanchocreativo

Another thing to mention is that gitkraken is made with Electron, therefore is not very performant, at least in Linux.

Thread Thread
 
adam_cyclones profile image
Adam Crockett 🌀

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.

Collapse
 
ogrotten profile image
ogrotten

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.

Collapse
 
mattmcadams profile image
Matthew McAdams

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.

Collapse
 
miteshkamat27 profile image
Mitesh Kamat

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.

Collapse
 
fossheim profile image
Sarah

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

If my project get stable enough, I work outside master to prevent breaking the master branch itself; then merge online; because web UI tools do help.

Collapse
 
jhechtf profile image
Jim Burbridge

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).

Collapse
 
ndrone profile image
Nicholas Drone

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.

Collapse
 
deciduously profile image
Ben Lovy

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.

Collapse
 
donnisnoni profile image
Don Alfons Nisnoni

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.

Collapse
 
cyberhck profile image
Nishchal Gautam

I protect my master branch, unless my ci says that changes are alright, they don't go to master

Collapse
 
deciduously profile image
Ben Lovy

gasp

Collapse
 
bhupesh profile image
Bhupesh Varshney 👾

I do this a lot.
Additionally I have setup a ton of type-checker, Dynamic Testing Tools
This helps me judge my code

Collapse
 
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

I merge locally for the convenience. If the project involves other devs, then I'll obviously open a PR.

Collapse
 
ayozebarrera profile image
Ayoze Barrera 🇮🇨

PR linked with a issue describing the change ♥️

Collapse
 
deciduously profile image
Ben Lovy

Tools only work if you use 'em!

Collapse
 
jeikabu profile image
jeikabu

I make my own PRs. Mostly just so my workflow is always the same, use pre-commit tests and builds for other platforms, etc.

Collapse
 
gablaroche profile image
Gabriel Laroche

I usually just close my eyes and push to origin/master. But seriously though, if it's a big change might make a pr.

Collapse
 
deciduously profile image
Ben Lovy

Huh, this is interesting. Thanks for the link.

Collapse
 
slimcoder profile image
Slim Coder

I don't merge instead of merging i do rebasing .

Collapse
 
deciduously profile image
Ben Lovy

I think the question still applies - do you do so locally and clean up before pushing to remote, or push your separate branches first and handle the rebase remotely?

Collapse
 
slimcoder profile image
Slim Coder

I clean up before pushing to remote .

Collapse
 
albertomontalesi profile image
AlbertoM

Usually I don't care much. If you wanna keep your master branch cleaner you can open a PR and squash merge

Collapse
 
salimmejdoub profile image
Salim Mejdoub

hello,
i prefer pull requests, it gives you the chance to view the changes again

Collapse
 
wrldwzrd89 profile image
Eric Ahnell

I only merge locally.

Collapse
 
deciduously profile image
Ben Lovy

This looks neat - do you have a Linux recommendation? Or would this work in Wine? I used to use Magit but have de-Emacs'd and never found a replacement.