12 ms·

Minimum Viable Git for Trunk-Based Development

48 points by elischleifer 4y ago

GMoromisato 4y ago
Nice! Maybe someone should create an opinionated git front-end to enforce some of these patterns on a team. The irony, IMO, is that Linus prefers C to C++ exactly because C++ gives developers too much rope.
sossunday 4y ago
> 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.
- dapirian 4y ago
  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
- mdaniel 4y ago
  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#push-options-for-gitlab-cicd 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 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 https://gitlab.com/gitlab-org/gitlab/-/issues/359268 MR: https://gitlab.com/gitlab-org/gitlab/-/issues/359269 https://gitlab.com/gitlab-org/gitlab/-/issues/359269
federicoweber 4y ago
I'm a huge fan of squash rebase, myself. really it's my default, and I find it particularly useful for long run branches.
jangofett27 4y ago
I'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.
- aleyva 4y ago
  yep, well summarized!
surf_wreck21 4y ago
I 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)
dboreham 4y ago
> 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.
- elischleifer 4y ago
  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.
  - TrickyRick 4y ago
    Sure but it goes in the repo. Forgot to add .env to the .gitignore? You probably just committed a secret. Sure you can force push to get rid of it but if you're using Github it's still saved so it needs to be rotated now.
    - alkonaut 4y ago
      What’s “the repo” here? What I commit goes into my copy of the repo. Only what I push goes into any repo anyone else sees. Before pushing I always go through what’s in the branch and clean up/rebase etc. Sure it’s easier to accidentally push a file you shouldn’t have if you have added it locally but committing alone doesn’t necessarily mean you need to rotate a secret.
      - LocalPCGuy 4y ago
        That is a case where (as you note) you'd need to do some sort of destructive fix to eliminate the file from your local repo. Whether it's a rebase or something else, a person then needs to know "the advanced parts" that the blog post is advocating aren't really needed if "git is done correctly". Better to just not commit files/hunks accidentally in the first place - I know, it's not a perfect world, yada yada - just trying to provide the counter point to the counter point.
jbergknoff 4y ago
> The easiest practice to implement for peak Git efficiency is to stick to a subset of commands This has been my experience as well. Great article, thanks! I've been using essentially this same subset of commands for many years, and it's worked extremely well for me: does everything I need/my team needs, and avoids complication. I'm glad to have this as a reference I can point people to when they ask for git advice.
itslennysfault 4y ago
I finally understand why some people are so against rebase. They're doing it wrong. I've always heard people talk about how it doesn't scale, but I use rebase like 99% of the time, and have worked on projects with hundreds of ICs. This is the first time I've seen someone explain it in a way where I get it. NO I'M NOT FORCE PUSHING TO MAIN YOU SILLY NILLY! Turns out I'm "squash rebasing." I guess I didn't know I need to specify that. I do it slightly differently tough. I use git commit --amend to build up a single commit as I go. git checkout -b blah-feature # do some work git commit -m "Main description of my feature" # do more work # no -m, and then I just add bullet points for each subsequent change in vim (example below) git commit --amend Then, once I'm ready to make a PR I do the following: # pulls from remote without merging git fetch origin main # adds my single commit to the end of the current main git rebase main # push up feature branch for code review git push # get yelled at about --set-upstream, and copy/paste that command :-) My commit messages typically look like: Add some new feature - do some sub task - do another sub task - ...
- patmcc 4y ago
  Yah, I don't think anyone minds those kind of rebases. It's when they're done on shared branches like master that they're incredibly messy and dangerous.
  - itslennysfault 4y ago
    That totally makes sense. I never really dug in. Mostly I'd tell people I always rebase in passing and get a glare or snarky comment, but never bothered to argue about it because it works for me and never caused issues.
- knff 4y ago
  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.txt-pushautoSetupRemote https://git-scm.com/docs/git-config#Documentation/git-config...
bsima 4y ago
How does this guy run a developer tools company called “trunk” and yet doesn’t understand rebase? Talk about killing credibility…
- tkiolp4 4y ago
  Trunk development is not about rebase, it’s about short-lived branches that get incorporated into the main branch soon. How they get incorporated (git merge is good enough) is not relevant.
scelerat 4y ago
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 your co-worker without much thought as soon as all the tests pass. "But my feature branch gets squashed anyway" 1. I believe that in itself is a mistake, especially as feature branches get large and, though you say you're all for small feature branches, your commit history says you do something different. 2. You don't clean up that giant merge commit message with all those "WIP" "fixed stupid mistake" comments in there. Use rebase to keep your workspace clean and main/master comprehensible to your colleagues.
- dSebastien 4y ago
  Rebase is clearly the way to go. Clean history for the win!
- mooreds 4y ago
  Here's my favorite rebase presentation. He really emphasizes keeping history clean. https://www.youtube.com/watch?v=UWwazJ_46s0 https://www.youtube.com/watch?v=UWwazJ_46s0
gabrielgio 4y ago
> you need to re-clone from scratch — even if you did nothing wrong. I don't think you will need to reclone if did nothing wrong. You can always use `git reset --hard origin/...`, and if that does not work the you definitely did something wrong. > But in Linus’s own words, Git is “the information manager from hell.” That git is not the same git we have today, and it was handed over to another person quite early in the development. Although I agree that git ux is sometimes confusing. > Limit your Git actions ... for peak Git efficiency I pretty much disagree, if I can give my two cents, read the manual. Git have some really handy tooling that can help with non-git issue (e.g.: `git bisect`). Limiting your knowledge brings no benefit. I like some point of the text, but overall I don't like the premise. it exaggerate a lot a problem to prove a point.
alkonaut 4y ago
Without rebasing, tools for managing PRs might show the merged mainline commits in the PR. Some times they are described as such “merged master into feature” and can be avoided if you review the PR per commit. But more often I want to review the PR as a whole, and then the tool fails to show a good diff of what’s actually developed in the PR. This to me is a much larger problem than the log pollution, which can be solved by squashing. Other than that (missing the bigger reason for rebase and focusing on a lesser argument in my opinion) I quite agree with the article.
everybodyknows 4y ago
Clicking through a self-link in the article https://blog.trunk.io/git-commit-messages-are-useless-c2f3c46f678e 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 feature or bug and move on to the next one. The code speaks for itself (alongside some judiciously placed comments). > Having granular annotations of all your work is unnecessary, ... This premise underlies the particular workflow that the posted article assumes, and all the described command+option incantations are directed to it. But there is another, very different git workflow used by a project we've all heard of, and that is the Linux kernel core code. The trunk.io workflow is unsuitable for Linux due to different requirements. Some of which being: 1. Commitment to support for indefinite future. 2. Large, complex feature PRs. 3. Human review of PRs, by maintainers fully empowered to reject. 4. A low-level programming language, in which subtle bugs are easily introduced. Also different luxuries: 1. Willingness to put off merge of a "hot" new feature indefinitely. So, kernel PRs are structured as a linear series of numbered patches meeting the requirement that each step along the way compile cleanly. This is primarily to ease the task of the maintainer responsible for the subsystem involved, and who will have deal with the fallout of bugs introduced by the PR. Example: https://lore.kernel.org/rcu/ https://lore.kernel.org/rcu/ Credential: I have written code for the Linux kernel core, and it was merged, and it was buggy.
- throwaway_au_1 4y ago
  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).
LocalPCGuy 4y ago
I personally am a proponent of rebase, but not all the time and not for every workflow. It has it's place though, IMO. I like/value clean history and good commit messages (although I admit I don't always succeeding providing that all of the time). I prefer to stage my commit pieces at the hunk level at the largest. I like to rebase my branches before merging them into release or main (depending on git strategy as a whole), but it isn't always necessary. I use interactive rebase from time to time to clean up my feature branches (especially longer running ones). This is all stuff I prefer in my own workflow. That said, every time I try to really teach someone rebase, particularly a new dev, I understand why people shy away from it. I did for a very long time. So I totally understand and get why the above style workflow may terrify folks (or just seem unnecessary). It is easy to mess up and there are a lot of little gotchas if someone isn't careful. And worst of all, it can result in lost work (although even that is "usually" recoverable, but not always). I do think there are some benefits to it, and I think it is something that can be integrated into a dev's workflow a bit at a time. And it really doesn't take significantly more time, in my experience. I'm not gonna argue here for adopting that. Except for "no commit messages", I'd be pretty ok with a workflow as outlined by this post. I do think folks should understand how rebase works, what commits will be moved/changed when they run a rebase (this is vital), and how to recover when a rebase goes bad (no, not reclone, not generally even delete branch and check it out again). . Couple random thoughts I try to communicate to folks who decide to utilize rebase more in their workflow: - rebase often (if main updates often) - if worried the rebase may be messy, create a temporary branch prior to starting the rebase at the feature branch HEAD - allows for an easy way back (and prevents lost code) - don't rebase shared branches - this is a tool to use PRIOR to "sharing" (i.e. pushing) code - squash/clean up unneeded commits before rebasing on another branch (this may bring it all the way down to a single commit, but for larger features, I think there is value in seeing the main decision points along the way) - fix conflicts with the code at the specific commit you are on only, don't fix it with the eventual end result X commits down the line - this will generally avoid the dreaded "fix the same conflict over and over for each commit" problem some people encounter with rebasing - remember rebase creates new history - it doesn't rewrite history (however, old commits will eventually be garbage collected) - pro tip: understand how `rebase --onto` works, sometimes you shouldn't, or at least don't want to, take all of the commits

48 points by elischleifer 4y ago

Nice! Maybe someone should create an opinionated git front-end to enforce some of these patterns on a team. The irony, IMO, is that Linus prefers C to C++ exactly because C++ gives developers too much rope.

sossunday 4y ago

> 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.

dapirian 4y ago
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
mdaniel 4y ago
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#push-options-for-gitlab-cicd 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 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 https://gitlab.com/gitlab-org/gitlab/-/issues/359268 MR: https://gitlab.com/gitlab-org/gitlab/-/issues/359269 https://gitlab.com/gitlab-org/gitlab/-/issues/359269

federicoweber 4y ago

I'm a huge fan of squash rebase, myself. really it's my default, and I find it particularly useful for long run branches.

jangofett27 4y ago

I'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.

aleyva 4y ago
yep, well summarized!

surf_wreck21 4y ago

I 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)

dboreham 4y ago

> 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.

elischleifer 4y ago
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.
- TrickyRick 4y ago
  Sure but it goes in the repo. Forgot to add .env to the .gitignore? You probably just committed a secret. Sure you can force push to get rid of it but if you're using Github it's still saved so it needs to be rotated now.
  - alkonaut 4y ago
    What’s “the repo” here? What I commit goes into my copy of the repo. Only what I push goes into any repo anyone else sees. Before pushing I always go through what’s in the branch and clean up/rebase etc. Sure it’s easier to accidentally push a file you shouldn’t have if you have added it locally but committing alone doesn’t necessarily mean you need to rotate a secret.
    - LocalPCGuy 4y ago
      That is a case where (as you note) you'd need to do some sort of destructive fix to eliminate the file from your local repo. Whether it's a rebase or something else, a person then needs to know "the advanced parts" that the blog post is advocating aren't really needed if "git is done correctly". Better to just not commit files/hunks accidentally in the first place - I know, it's not a perfect world, yada yada - just trying to provide the counter point to the counter point.

jbergknoff 4y ago

> The easiest practice to implement for peak Git efficiency is to stick to a subset of commands This has been my experience as well. Great article, thanks! I've been using essentially this same subset of commands for many years, and it's worked extremely well for me: does everything I need/my team needs, and avoids complication. I'm glad to have this as a reference I can point people to when they ask for git advice.

itslennysfault 4y ago

I finally understand why some people are so against rebase. They're doing it wrong. I've always heard people talk about how it doesn't scale, but I use rebase like 99% of the time, and have worked on projects with hundreds of ICs. This is the first time I've seen someone explain it in a way where I get it. NO I'M NOT FORCE PUSHING TO MAIN YOU SILLY NILLY! Turns out I'm "squash rebasing." I guess I didn't know I need to specify that. I do it slightly differently tough. I use git commit --amend to build up a single commit as I go. git checkout -b blah-feature # do some work git commit -m "Main description of my feature" # do more work # no -m, and then I just add bullet points for each subsequent change in vim (example below) git commit --amend Then, once I'm ready to make a PR I do the following: # pulls from remote without merging git fetch origin main # adds my single commit to the end of the current main git rebase main # push up feature branch for code review git push # get yelled at about --set-upstream, and copy/paste that command :-) My commit messages typically look like: Add some new feature - do some sub task - do another sub task - ...

patmcc 4y ago
Yah, I don't think anyone minds those kind of rebases. It's when they're done on shared branches like master that they're incredibly messy and dangerous.
- itslennysfault 4y ago
  That totally makes sense. I never really dug in. Mostly I'd tell people I always rebase in passing and get a glare or snarky comment, but never bothered to argue about it because it works for me and never caused issues.
knff 4y ago
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.txt-pushautoSetupRemote https://git-scm.com/docs/git-config#Documentation/git-config...

bsima 4y ago

How does this guy run a developer tools company called “trunk” and yet doesn’t understand rebase? Talk about killing credibility…

tkiolp4 4y ago
Trunk development is not about rebase, it’s about short-lived branches that get incorporated into the main branch soon. How they get incorporated (git merge is good enough) is not relevant.

scelerat 4y ago

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 your co-worker without much thought as soon as all the tests pass. "But my feature branch gets squashed anyway" 1. I believe that in itself is a mistake, especially as feature branches get large and, though you say you're all for small feature branches, your commit history says you do something different. 2. You don't clean up that giant merge commit message with all those "WIP" "fixed stupid mistake" comments in there. Use rebase to keep your workspace clean and main/master comprehensible to your colleagues.

dSebastien 4y ago
Rebase is clearly the way to go. Clean history for the win!
mooreds 4y ago
Here's my favorite rebase presentation. He really emphasizes keeping history clean. https://www.youtube.com/watch?v=UWwazJ_46s0 https://www.youtube.com/watch?v=UWwazJ_46s0

gabrielgio 4y ago

> you need to re-clone from scratch — even if you did nothing wrong. I don't think you will need to reclone if did nothing wrong. You can always use `git reset --hard origin/...`, and if that does not work the you definitely did something wrong. > But in Linus’s own words, Git is “the information manager from hell.” That git is not the same git we have today, and it was handed over to another person quite early in the development. Although I agree that git ux is sometimes confusing. > Limit your Git actions ... for peak Git efficiency I pretty much disagree, if I can give my two cents, read the manual. Git have some really handy tooling that can help with non-git issue (e.g.: `git bisect`). Limiting your knowledge brings no benefit. I like some point of the text, but overall I don't like the premise. it exaggerate a lot a problem to prove a point.

alkonaut 4y ago

Without rebasing, tools for managing PRs might show the merged mainline commits in the PR. Some times they are described as such “merged master into feature” and can be avoided if you review the PR per commit. But more often I want to review the PR as a whole, and then the tool fails to show a good diff of what’s actually developed in the PR. This to me is a much larger problem than the log pollution, which can be solved by squashing. Other than that (missing the bigger reason for rebase and focusing on a lesser argument in my opinion) I quite agree with the article.

everybodyknows 4y ago

Clicking through a self-link in the article https://blog.trunk.io/git-commit-messages-are-useless-c2f3c46f678e 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 feature or bug and move on to the next one. The code speaks for itself (alongside some judiciously placed comments). > Having granular annotations of all your work is unnecessary, ... This premise underlies the particular workflow that the posted article assumes, and all the described command+option incantations are directed to it. But there is another, very different git workflow used by a project we've all heard of, and that is the Linux kernel core code. The trunk.io workflow is unsuitable for Linux due to different requirements. Some of which being: 1. Commitment to support for indefinite future. 2. Large, complex feature PRs. 3. Human review of PRs, by maintainers fully empowered to reject. 4. A low-level programming language, in which subtle bugs are easily introduced. Also different luxuries: 1. Willingness to put off merge of a "hot" new feature indefinitely. So, kernel PRs are structured as a linear series of numbered patches meeting the requirement that each step along the way compile cleanly. This is primarily to ease the task of the maintainer responsible for the subsystem involved, and who will have deal with the fallout of bugs introduced by the PR. Example: https://lore.kernel.org/rcu/ https://lore.kernel.org/rcu/ Credential: I have written code for the Linux kernel core, and it was merged, and it was buggy.

throwaway_au_1 4y ago
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).

LocalPCGuy 4y ago

I personally am a proponent of rebase, but not all the time and not for every workflow. It has it's place though, IMO. I like/value clean history and good commit messages (although I admit I don't always succeeding providing that all of the time). I prefer to stage my commit pieces at the hunk level at the largest. I like to rebase my branches before merging them into release or main (depending on git strategy as a whole), but it isn't always necessary. I use interactive rebase from time to time to clean up my feature branches (especially longer running ones). This is all stuff I prefer in my own workflow. That said, every time I try to really teach someone rebase, particularly a new dev, I understand why people shy away from it. I did for a very long time. So I totally understand and get why the above style workflow may terrify folks (or just seem unnecessary). It is easy to mess up and there are a lot of little gotchas if someone isn't careful. And worst of all, it can result in lost work (although even that is "usually" recoverable, but not always). I do think there are some benefits to it, and I think it is something that can be integrated into a dev's workflow a bit at a time. And it really doesn't take significantly more time, in my experience. I'm not gonna argue here for adopting that. Except for "no commit messages", I'd be pretty ok with a workflow as outlined by this post. I do think folks should understand how rebase works, what commits will be moved/changed when they run a rebase (this is vital), and how to recover when a rebase goes bad (no, not reclone, not generally even delete branch and check it out again). . Couple random thoughts I try to communicate to folks who decide to utilize rebase more in their workflow: - rebase often (if main updates often) - if worried the rebase may be messy, create a temporary branch prior to starting the rebase at the feature branch HEAD - allows for an easy way back (and prevents lost code) - don't rebase shared branches - this is a tool to use PRIOR to "sharing" (i.e. pushing) code - squash/clean up unneeded commits before rebasing on another branch (this may bring it all the way down to a single commit, but for larger features, I think there is value in seeing the main decision points along the way) - fix conflicts with the code at the specific commit you are on only, don't fix it with the eventual end result X commits down the line - this will generally avoid the dreaded "fix the same conflict over and over for each commit" problem some people encounter with rebasing - remember rebase creates new history - it doesn't rewrite history (however, old commits will eventually be garbage collected) - pro tip: understand how `rebase --onto` works, sometimes you shouldn't, or at least don't want to, take all of the commits