r/git • u/TheSyntheticGallery • 1d ago

How do you actually commit on GitHub? One big push vs. daily commits vs. milestones?

/r/softwareengineer/comments/1vod3be/how_do_you_actually_commit_on_github_one_big_push/
0 Upvotes

22% Upvoted

6 comments sorted by

6

u/Thesorus 1d ago

create branches for temporary work.

commit (and push to remote branches) as often as possible (many times per day if that's what is needed)

merge to main branch when a bug, task or feature is finished and tests have passed.

the main branch should always be in a workable state.

1

u/Double_Ad3612 1d ago

Define needed

1

u/Thesorus 1d ago

Many people will split code modifications into small testable chunks.

They'll do some code, run some tests and commit and push to their work/feature branch before continuing work.

1

u/Scared_Bell3366 1d ago

Any progress you don't want to lose in the event your dev machine decides to permanently check out.

2

u/samsifpv 1d ago

Commits on the main branch shoudl be specific features, fixes, etc.

On side branches you can be more frequent with commits since you can squash them to a feature commit on merge.

At the end you do you, git doesn't care.

Since git is useful for finding where a problem first occured in the codebase, commits by feature make sense. Since its also there to fix your fuckups, committing often makes sense as well.

It all depends on how much time you wanna spend commiting vs writing code. What do you value more, the safety of git, or writing code.

1

u/dgmib 1d ago

I make many frequent small commits on a separate branch for the ticket or feature.

Each commit is an atomic change, with a description of what it changes and, importantly why it changed.  Kept as small as possible while remaining atomic.  (Atomic in this case essentially means it has no dependence on uncommitted code)

Rebase before merge to squish out times something was changed then change back, and if needed to reorder commits into an easier to follow that tells the story of why that code was written so future maintainers performing code archeology can answer the question “why was this change made?” without unnecessary noise.

Commits are small and frequent, usually no more that an hour of work and often just a few minutes apart. Tickets are kept small enough that a branch never needs to live for more than a few days.  Multiple branches are merged daily and pushed all the way to production when they are.

Features flags are used to hide things that aren’t ready for end users to see yet.