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

Minimum Viable Git for Trunk-Based Development

blog.trunk.io

Post reply on HN
Print view View original

41–45 of 45 posts

Re: Minimum Viable Git for Trunk-Based Development

#41

Post by Nullabillity »

LocalPCGuy wrote: post #35
tkiolp4 wrote: post #30

Earlier quoted context omitted.

Why not just ‘git merge main’ instead of ‘git rebase main’?

Because they do different things. It's right there in his post: > # adds my single commit to the end of the current main The biggest benefit to this IMO is that you can resolve conflicts in YOUR branch, get it all cleaned up, and then when you merge there are no conflicts. This allows you to test any changes made during conflict resolution in your feature branch still.

No, if you want to update your local branch first then the correct way to do that would be to run:

    $ git checkout feature-branch
    $ git merge main
    # test stuff, make sure everything looks good
    $ git checkout main
    $ git merge feature-branch --no-ff
No rebasing or other history rewrites required.

Re: Minimum Viable Git for Trunk-Based Development

#42

Post by LadyCailin »

JamesSwift wrote: post #23
knff wrote: post #21

Earlier quoted context omitted.

Slightly off topic > get yelled at about --set-upstream, and copy/paste that command :-) But you might like this https://git-scm.com/docs/git-config#Documentation/git-config...

I just added an alias alias gpush='git push --set-upstream origin $( git branch --show-current )'

`git push -u origin HEAD` also works!

Re: Minimum Viable Git for Trunk-Based Development

#43

Post by throwaway_au_1 »

everybodyknows wrote: post #28

Clicking through a self-link in the article https://blog.trunk.io/git-commit-messages-are-useless-c2f3c4... we read: > This isn’t grade school, you don’t have to show your work As you become an efficient engineer, the path you took to get to the final state of a pull request becomes far less important — and is academically interesting at best. You shouldn’t have to show your work like you did in school. Land the feat…

I think I need to adopt a practice where if I open an article, like the one you linked, and the title is some alternative take presented as a universal truth without qualification ("Git commits are useless"), I immediately stop reading. Not because I think they are always wrong, though that is usually how they read to me, but because they seemingly fail to demonstrate any humility - a characteristic I think is probably necessary for a balanced take landing closer to truth. (I did read the intro paragraph under the assumption the title was just clickbait but things don't improve).

Re: Minimum Viable Git for Trunk-Based Development

#44

Post by simplotek »

elischleifer wrote: post #37
simplotek wrote: post #29

Earlier quoted context omitted.

> But nothing goes directly into main. That's not a reasonable argument. The problem is pushing confidential info into a repository. It matters nothing what the branch you push it is called.

FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.

> FWIW - we run secret detection in our trunk check precommit action - so we make sure that secrets are never committed into local or remote branches.

Irrelevant. You're describing a failsafe. It's like claiming that you don't need to care about speed limits because a road has guardrails. The whole process is broken if it fails to address the main reason confidential info can be pushed into repositories.

Re: Minimum Viable Git for Trunk-Based Development

#45

Post by dSebastien »

scelerat wrote: post #20

This guy doesn't understand rebase. Rebase is an organizational tool. it's housekeeping for keeping your commits clean. One reason to learn how to do rebase is so that your feature branch is tidy so when you merge it to main, main itself is tidy. Another is that as you perform the exercise of cleaning up your commits you are performing code review, something that, up until this point, you've just been throwing at you…

Rebase is clearly the way to go. Clean history for the win!
Post reply on HN