Minimum Viable Git for Trunk-Based Development
blog.trunk.io
Minimum Viable Git for Trunk-Based Development
1–10 of 45 posts
Re: Minimum Viable Git for Trunk-Based Development
#2> git push origin
> Push my code to the remote; likely spinning up lots of machines in CI to check my work.
That's a good callout; something that I have noticed I frequently miss when iterating on my code is the cost of the CI/CD systems already set up. It's something to consider especially when iterating using a system like Sapling for Stacked PRs; each individual PR push may update a chain which causes a lot of wasted CI/CD time.
Re: Minimum Viable Git for Trunk-Based Development
#3> git push origin > Push my code to the remote; likely spinning up lots of machines in CI to check my work. That's a good callout; something that I have noticed I frequently miss when iterating on my code is the cost of the CI/CD systems already set up. It's something to consider especially when iterating using a system like Sapling for Stacked PRs; each individual PR push may update a chain which causes a lot of was…
Especially if you're using a finite pool of CI runners. Lots of companies do run their own CI runners either for added security, or to get persistent CI machines with a hot local cache so builds/tests are much faster. Then everyone's PRs are blocked waiting for CI machines just because of people's weird push workflows or micro stacked PRs
Re: Minimum Viable Git for Trunk-Based Development
#4I'm a huge fan of squash rebase, myself. really it's my default, and I find it particularly useful for long run branches.
Re: Minimum Viable Git for Trunk-Based Development
#5I'll always be a rebase diehard, but the core message here is great. If you have to do more than a little bit of git surgery, you're probably doing something else wrong.
Re: Minimum Viable Git for Trunk-Based Development
#6I agree; maybe when git was new and actually being used in a decentralized fashion some of the more advanced operations were necessary. But with the typical checkout/branch/PR/merge flow from GitHub and others, I rarely need anything but git merge (with squash merging when merging a pr)
Re: Minimum Viable Git for Trunk-Based Development
#7> git add -A .
> Add everything I’m working on (new and edited files).
Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.
Re: Minimum Viable Git for Trunk-Based Development
#8> git add -A . > Add everything I’m working on (new and edited files). Bad idea. Extraneous cruft that isn't caught by .gitignore will leak into the repo. Always run git diff and git status first to see what you are about to add.
I hear you. But nothing goes directly into main. The working branch is not sacrosanct you know what I mean? I'd rather clean up anything that leaks in before merging and a good .gitignore can protect against most noise.
Re: Minimum Viable Git for Trunk-Based Development
#9I'll always be a rebase diehard, but the core message here is great. If you have to do more than a little bit of git surgery, you're probably doing something else wrong.
yep, well summarized!
Re: Minimum Viable Git for Trunk-Based Development
#10> git push origin > Push my code to the remote; likely spinning up lots of machines in CI to check my work. That's a good callout; something that I have noticed I frequently miss when iterating on my code is the cost of the CI/CD systems already set up. It's something to consider especially when iterating using a system like Sapling for Stacked PRs; each individual PR push may update a chain which causes a lot of was…
I feel that a lot of my colleagues use "git push" as a backup mechanism, but GitLab actually supports that workflow via `git push -o ci.skip` to distinguish between "yes, just back up my commits" versus "ok, I'm really ready to test them". I'm aware of the commit-message hack used by other CI systems, but I much prefer that out-of-band mechanic
They have a ton of other handy toys, even if the syntax is ... Very Git :-( https://docs.gitlab.com/ee/user/project/push_options.html#pu... I suggested a feature-request to add `git push -o gitlab.help`: https://gitlab.com/gitlab-org/gitlab/-/issues/359267 as well as showing the CLI equivalent for the web workflow:
CI variables: https://gitlab.com/gitlab-org/gitlab/-/issues/359268