Comment by jcon321 | Hacker News Reader

Comment by jcon321 | Hacker News Reader

Idiot proof git is handled by protecting ALL branches and requiring a merge/pull request. Not a fan of aliases unless created and used personally.

I'm a tech lead for 2 large scale web projects. Rarely will I traverse git log for anything besides the last few commits. If I ever wanted to see the history of something I would just lookup the merge/pull request, or look at the blame on individual files or lines within that file. Having a non-rebased commit history at that point is much more clearer on why/what changed.

I guess anyone who would care for a pretty git-log does not have adequate tracking outside of the source code for requirements --> implementation. Guess I'm used to more stricter guidelines, because I could never see myself working on a project where something is committed that didn't derive from some type of identified requirement.

I fail to see what anything you state has to do with rebasing.

Rebasing ensures all commits from a feature branch are contiguous. Rebasing + squash ensures the main branch is not polluted with a myriad of useless intermediate commits no one is interested in. It also allows combining multiple commit message into a more coherent explanation of what changed instead of multiple tid-bits.

yea I do interactive rebase all the time on my local git to clean up my commits before I push them up.

I also started doing `git commit --fixup` when doing cr fixes so I can just autosquash the fixes - `git rebase --autosquash`

So yea I think rebase and merge commits both have their place within a workflow.

I fail to see your misunderstanding of what I stated. Rebasing is all about a pretty git-log, a pretty git-log is all about looking up why/what something changed. Everything I stated is about why you don't need a pretty git-log to know why/what something changed... Hope you don't talk to people at your day job like that.

Squashing commits of a feature branch via rebase is not the same thing as rebasing a local feature branch with the intended remote target.

Anyways, squashing is almost worse. Imagine doing a git blame on a line only to see a large commit of x amount of other changes with a summary about the global feature instead of an individualized commit referencing the line changed more closely. I am interested in those myriad of useless intermediate commits as you put it.

Reply on news.ycombinator.com