Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

201–210 of 435 posts

Re: Idiot Proof Git

#201

Post by hardolaf »

cube2222 wrote: post #169
cnity wrote: post #155

Earlier quoted context omitted.

> commit crafting is overrated. For you, in your use case. When I look at my neat history and use git bisect, I get plenty of value out of it. People keep telling me to stop rebasing. I keep ignoring them; nothing new here.

This is basically solved by squashing each PR on merge and having a good PR title + description.

This is exactly what we do at my job. The only time it ever causes issues with some things is when we're ramping up a new project and the PR and ticket titles don't necessarily match the work we've done. But that's more of a problem where we could make everything bite-sized, or we can deliver complete packages in terms of a feature plus all of the miscellaneous changes that we needed to make along the way to make it work. Now, is this the best way to do things? No, you should ideally make those changes separately and push each one separately. But that slows down progress.

Re: Idiot Proof Git

#202

Post by aulin »

cube2222 wrote: post #169
cnity wrote: post #155

Earlier quoted context omitted.

> commit crafting is overrated. For you, in your use case. When I look at my neat history and use git bisect, I get plenty of value out of it. People keep telling me to stop rebasing. I keep ignoring them; nothing new here.

This is basically solved by squashing each PR on merge and having a good PR title + description.

why would you squash multiple informative commits with their commit messages and their informative context about your thought process into a single big squashed commit? git can merge branches and keep track of it, there is no need to squash unless you split trivial changes that belong together and want to group them before sharing them

Re: Idiot Proof Git

#203

Post by matkoniecz »

ccity88 wrote: post #90
stblack wrote: post #38

I might be mistaken but this post is basically describing git-friendly which I've used for years, is 100% flawless, and you'd need to pry from my cold, dead hands. https://github.com/git-friendly/git-friendly

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use…

> It has all the bells and whistles of the CLI

Somehow I strongly doubt it. Does it have at least access to cherry picking, reflog and rebasing?

Re: Idiot Proof Git

#204

Post by mook »

willio58 wrote: post #150
aulin wrote: post #137

Earlier quoted context omitted.

If you keep merge commits you can get the full diff at once and see all the context you need, if you don't you can still write meaningful commit messages that identify the feature you're working on so that in the future you can still do a diff between the first and the last commit and see it all at once.

Yeah if you just use commits as they are intended then the complexity of git drops off massively. I’ve used got for a decade and want to know how many times I’ve rebased? Zero

Isn't commits as they are intended a patch queue in email with a cover letter (0/n commit)? At least, that seemed to be how the Linux kernel works.

Re: Idiot Proof Git

#205

Post by tylerscott »

ezfe wrote: post #121
ccity88 wrote: post #90

Earlier quoted context omitted.

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use…

Sublime Merge here, love it and won't go near the CLI anymore

Seconding Sublime Merge. I've been using it since it was launched and it has been a solid tool.

Re: Idiot Proof Git

#206

Post by afefers »

user3939382 wrote: post #113

.gitconfig: [alias] add-commit = !git add -A && git commit .bash_profile: function save () { git add-commit -m "$*" && git push } Use like: $ save This is a commit message This adds changed files to a commit with this message and pushes it to remote. Also: alias mkpr='git push && gh pr create -d -f -B develop | grep https | xargs printf -- '%s/files' | xargs open' Open a PR from current branch based on develop and op…

Those are really good! Thanks for sharing. Curious to see the others. Are they available somewhere?

Re: Idiot Proof Git

#207

Post by Izkata »

dljsjr wrote: post #21
distcs wrote: post #5

How is push origin HEAD --force-with-lease different from normal git push? Can someone please explain this to me?

When you work with a rebase-oriented workflow, it's very common to submit a PR for review and then address incoming review comments as fixup commits: https://blog.sebastian-daschner.com/entries/git-commit-fixup... This necessitates force-pushing to your feature branch after all the fixup commits have been approved and then squashed. At that point you can merge the cleaned up feature branch in to your develop or trunk…

This is the kind of workflow that makes me headdesk. Those fixup commits weren't obvious, and will be useful context if a future maintainer ever has to go back to these - they shouldn't be squashed.

Re: Idiot Proof Git

#209

Post by daneel_w »

Shacklz wrote: post #151
daneel_w wrote: post #16

I'm incredibly thankful that 99% of my Git usage at work gets away with just PULL, CHECKOUT [-b], COMMIT [--amend] and PUSH. Rarely do I need to rebase, for any reason.

I understand the sentiment, but since git is probably one of the longer-lasting constants in our industry (if not the longest-lasting constant), I personally think it's really worth to have a bit of a look into it. Something I wish someone suggested to me years ago: Instead of trying to understand the commands, try to understand the datamodel. A branch is just a pointer to a commit, a commit is just a pointer (with m…

You have misunderstood. It's not a case of not knowing more about Git and its toolset. It's about our underlying workflow, letting us do version control of our software with simple means instead of throwing everything at it. It's easy to throw a hammer, mallet, pein and a club all at once on a nail, but that doesn't mean it's necessary or helpful.
Post reply on HN