Ask HN: What's your Git workflow like at work? What could be improved?

Posted by lifeisstillgood on Saturday February 10, 2024 @09:31AM
from the ask-hn dept.

For various reasons I am revisiting “everything I know”. One that crops up the most is handling multiple developers on the same project. We can try stand ups and designs and coffee breaks but in the end it’s the code that matters

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 ?

( 10 comments | 3 points | on HN )

Re:Ask HN: What's your Git workflow like at work? What could... by lifeisstillgood on Saturday February 10, 2024 @09:45AM (#39326475)

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

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by lifeisstillgood on Sunday February 11, 2024 @05:42AM (#39334094)

https://www.kernel.org/doc/html/latest/process/2.Process.htm...

https://git-scm.com/docs/gitworkflows

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by quickthrower2 on Saturday February 10, 2024 @09:42PM (#39332251)

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…

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by ipaddr on Saturday February 10, 2024 @10:08PM (#39332348)

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.

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by nicbou on Sunday February 11, 2024 @05:02AM (#39333904)

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.

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by kingkongjaffa on Monday February 12, 2024 @05:02AM (#39343248)

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)

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by comprev on Monday February 12, 2024 @07:32AM (#39344090)

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"

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by kesavvaranasi on Monday February 12, 2024 @12:22PM (#39347584)

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

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by revskill on Tuesday February 13, 2024 @02:20AM (#39355383)

I do git reset.

[ Parent | on HN ]

Re:Ask HN: What's your Git workflow like at work? What could... by hajmo97 on Tuesday February 13, 2024 @09:30AM (#39357922)

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"

[ Parent | on HN ]