Some companies suggest to commit often with regulated commit message (starts with feat:, refactor:, fix: or else). My company also suggest that, but not forced, and won’t disturb the review process. By that, I developed habit to also do the same to my personal projects.
I always create a branch started with ticket number, a slash, then the purpose. (TICK-17/init-ui, TICK-17/integrate-backends, TICK-1/refactor-states). It will help with the commit messages when the branch squash&merged to main branch. I don’t do branches for my personal project unless they’re quite big, separate tasks (i.e. refactor UI or upgrade dependencies).
If I wind up doing other unrelated task, I will commit that/those files into a wip commit and then create new branch to cherry-pick the wip commit.
I push by the end of the day, always merge/rebase from master (or main) branch before doing so.
Long lived branches is different from no branches. No branches at all means either:
You push to main directly. Which limits your ability to test or easily revert to working state.
You are not pushing frequently, so you avoid to push breaking code till you finish your feature and bring your code base to stable working state.
My proposal:
Branch from default branch, work as long as you need on this new feature, commit frequently, and push.
Once done, PR to default branch, and configure your Git service to squash and delete the merging branch, so no longer long lived branches.
Benefits:
Commit and push frequently so your code is always stored somewhere.
You can even commit Work In progress and broken code.
Now you can automate workflows based on PRs to default branch, there are complete businesses around that, it’s the new trend with Git Flows, and push to deploy.
The one thing the otherwise-excellent Working Copy seems to lack is Issues support.
I mention this here in case somebody says “it’s there”. If it were then maybe I could automate creating an Issue through Working Copy and adding to OmniFocus.
(If I can’t get an Issue created in GitHub to reliably create an OmniFocus task maybe I should shift my Point Of Automation to write twice - from somewhere else.)
If I may, it’s a pull request, which usually means that someone has forked your repo, made changes, and are offering them up to be merged into the original repo.
In this context, I’m not sure why a PR would be needed, as one could just merge their branch back into main.
I didn’t intend to start a long thread. In my professional work, I help organizations figure out how to Scrum/Agile, DevOps and Continuous Delivery. I get groups of upwards of 100 people to work on main. They make small commits and each commit gets run through a large battery of automated unit and acceptance tests. In these environments branching just adds overhead to the system and so isn’t recommend. In my original comments I just sharing the same sort of advice I would provide a team I was coaching.
So as @JohnAtl mentioned, PR is Pull request, sorry for not mentioning that earlier. Pull Request is a request to pull code from one source to another. That source can be different repo/fork or same repo but different branch. The whole idea of PR is that it adds context and reference to how, why, when and by whom the new code or features were added.
I’ve never used them for projects where I am the maintainer. I just do the merges etc as required. I have incorporated pull requests from other people who are working in the code but never put a pull request in for my own code. That’s why I was confused.
Can you talk more about how you use it when you are just a single person working on the code?
Hello,
So, even if you are the sole developer, here are some benefits:
Adds structure to your process of adding new features.
Gives you the opportunity to review your full change before it gets merged into production code. Sometimes you might notice a change that was not meant for this feature.
Allows you to squash intermediate commits, that are not beneficial to the history.
Acts as an easy changelog of how your app is changing.
By pushing to non default branch, you can basically push intermediate code that is broken. Because you will squash those intermediate steps at the end. This means, you have your code backed up.
Allows you to work on separate issues/features at the same time, and you can merge each separately.
There are many other benefits, those what come to my mind as top benefits.
Branching saved my ass again on Friday.
I added lfs support, and was committng and pushing some medium-sized files to a branch. Everything was fine until I started added my EEG data files, then got into a situation where I couldn’t push because of a time-out error, and couldn’t pull because Fork didn’t want to overwrite my files. I tried some things that didn’t work, and wound up deleting the branch, creating a new one, and adding (tracking) files except for the largest EEG data files. Squash-merge and merge, and all is good now.
On my personal projects I don’t branch and haven’t since I started to code. I should have as at work I really need to branch as we’re working with another contractor to help with a couple of the projects we’re doing.
And small atomic commits is ideal but I often don’t touch a project for months at a time and when I do I get lost in what I’m doing and commit changes when there’s a few there.
In this discussion I am surprised that no one has mentioned Fossil as a viable, self-hosted alternative to Git. Developed by and for the SQLite project it is an excellent code management system with integral web UI. Does anyone else use it?