Ask HN: What's your Git workflow like at work? What could be improved?
10 comments
My workflow is typical: create a feature branch from main/master, raise a PR when ticket is complete, and maintain a separate release branch for production deployments. I use rebase instead of merge so the commit history doesn't get cluttered with merge commits.
Pain points: -coming up with good commit messages -including the story ticket number in the branch name and commit message
Pain points: -coming up with good commit messages -including the story ticket number in the branch name and commit message
I always prefix commit messages with the relevant ticket number and write what the change _will_ do. I also use a few verbs: add, del, fix
e.g. "PROJ-1234 add: new dependencies section in README. fix: typo in SECURITY"Some ideas I have bouncing around:
- “architect” becomes an actual Meaningful term - they are the upstream merge maintainers. Eventually a company is one big monorepo and the CTO should probably be the “Torvalds” for that compmay.
- most lines of business are the users - but could also contribute patches and even patch their own services while they wait.
- most development would benefit a lot from a proposed updates branch - trying to go from zero to fully tested feature in one branch while keeping that JIRA uptodate is tough
- lots more feature flags. One thing I have tried but feels like it ought to work better is to slide whole modules in under feature flags
- “architect” becomes an actual Meaningful term - they are the upstream merge maintainers. Eventually a company is one big monorepo and the CTO should probably be the “Torvalds” for that compmay.
- most lines of business are the users - but could also contribute patches and even patch their own services while they wait.
- most development would benefit a lot from a proposed updates branch - trying to go from zero to fully tested feature in one branch while keeping that JIRA uptodate is tough
- lots more feature flags. One thing I have tried but feels like it ought to work better is to slide whole modules in under feature flags
Rebasing instead of having additional merge commits laying around the log.
Feature branches that usually always pass CI (so you can easily roll back to a working deployable state)
Feature branches that usually always pass CI (so you can easily roll back to a working deployable state)
Small branches off the master. Feature flags so that branches can stay small. Release branch off master for a stabilized branch for a release that QA can test.
I can’t think of a better way for teams as they can agree on Github etc. and sync up in real time. If there is little command structure and time overlap the mailing list way probably works better although Github is popular so…
I can’t think of a better way for teams as they can agree on Github etc. and sync up in real time. If there is little command structure and time overlap the mailing list way probably works better although Github is popular so…
I use that method for hotfixes.
I usually pull from staging include a number of changes from various branches merged into staging or things directly committed to the staging branch. Test everything and push a release, inform stakeholders, etc.
Any change to production will merge back to staging so everything stays in sync.
I usually pull from staging include a number of changes from various branches merged into staging or things directly committed to the staging branch. Test everything and push a release, inform stakeholders, etc.
Any change to production will merge back to staging so everything stays in sync.
I always put the ticket number in the message, at the start. I use rebase to avoid merge commits and discourage diverging too much from origin/master.
branch structure:
- master
- develop -> /feature/ticket#_short_desc -> pullrequest to develop
- create /release/next_versionnumer (year.release_month.build#)
-> after prod release -> merge back into master and develop branch
commit message structure: "ticket#: fix/add/del - short description"
- master
- develop -> /feature/ticket#_short_desc -> pullrequest to develop
- create /release/next_versionnumer (year.release_month.build#)
-> after prod release -> merge back into master and develop branch
commit message structure: "ticket#: fix/add/del - short description"
I do git reset.
Most “corporate” developers seem to have a branch master then merge, and release on a time based cycle, approach, but it seems rarer to find approaches such as the Linux kernel or git.git
I suspect there are far more pain points in the simplified approach (pulling a patch already in master is terrifying to most developers)
Any thoughts ?