5 ms·

Rebase has become so integral to my workflow, it's hard to imagine living without it. I intentionally avoid merge commits, including configuring git pull to reb

Rebase has become so integral to my workflow, it's hard to imagine living without it. I intentionally avoid merge commits, including configuring git pull to rebase rather than merge. I find it so much easier to commit a bunch of tiny iterations while doing local testing, rebase and squash them, then post them for review. As a bonus, I frequently push after each of those small commits to a feature branch so I don't have to worry about losing work if my drive dies.

robertlagrant 4y ago
This might be obvious, but it's worth checking out git commit --amend. Then you can be regularly committing, but to the same commit.
- shagie 4y ago
  --amend would interact with the remote system poorly if there's a push with each commit.
  - sjburt 4y ago
    You have to force push, but you have to do that when pushing a rebased branch as well. In either case it’s a history rewrite. It’s not a big deal unless other people have pulled that branch—if they have they will need to reconcile things on their end as well.
- dnsmichi 4y ago
  Depending on the workflow and collaboration in branches in teams, amending may not be ideal. Amending changes to an existing commit will generate a new sha checksum, thus resulting in a diverging history if the branch is often pushed to the remote Git server. That's one of the rare cases where "git push --force" makes sense but also requires awareness for other collaborators on the branch - they need to run "git fetch && git reset --hard origin/branchname" every time, and best "git stash" to temporarily remove any local changes, with running "git stash pop" afterwards. One reason to regularly push commits can be to trigger CI/CD, security scanning and dev/staging deployments or review apps. GitLab team member here - before joining GitLab in 2020, I was a Git/GitLab trainer. https://www.netways.de/en/blog/2018/05/24/releasing-our-git-and-gitlab-training-as-open-source/ https://www.netways.de/en/blog/2018/05/24/releasing-our-git-...
  - tspike 4y ago
    I've completely replaced my use of --force with --force-with-lease. It does the same thing, except it will abort if the upstream branch has been updated since your last pull. This pretty much prevents the concerns about clobbering others' work.
    - dnsmichi 4y ago
      After reading this comment about "git push --force-with-lease" in https://stackoverflow.com/a/53011907/1821348 https://stackoverflow.com/a/53011907/1821348 my workflows with "git fetch" first would not work with "git push --force-with-lease", behaving as if "git push --force" was run. Theoretically - I need to do some testing here. Thanks for the pointer into learning something new :)
  - robertlagrant 4y ago
    For sure, it doesn't work with every workflow. But I think it would for the OP's described workflow. And I am currently waiting for my GitLab backpack for contributing something (very small, but apparently it counted!) so thank you to the team for that!
    - dnsmichi 4y ago
      Thanks for sharing your ideas, appreciate the thoughts to learn new perspectives :-) And also thanks for contributing, every contribution counts and helps :-) Maybe see you at a future hackathon :) https://about.gitlab.com/community/contribute/ https://about.gitlab.com/community/contribute/
- usr1106 4y ago
  --amend if you have a modification to your most recent commit. --fixup if you have a modification to an earlier commits rebase --autosquash amend the fixup(s) to the commit(s) they belong too. (Of course you need to know what you doing. Otherwise you create conficts tedious to resolve in the rebase)
agumonkey 4y ago
then there's autosquash and similar honestly the commit graph as a first-class value yields a lot of ideas in my mind, we should be investigating compute at the subtree layer more often.
rrwo 4y ago
> Rebase has become so integral to my workflow, it's hard to imagine living without it. Same. I use it to reorganise branches before submitting change requests or merging: - Combing or splitting commits so that each commit contains a small unit of a logical change - Reordering commits to related changes are near each other - Reordering commits so changes that are depended on by later commits occur earlier. - Rewording commit descriptions to have a lengthy explanation, if needed - Removing small commits that fix minor typos It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change. (I had a colleague who was so used to CVS and couldn't get his head around not using version control as a time tracking device.)
- thunky 4y ago
  > It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change. This seems a bit like an unhealthy obsession. I would be curious to know if the benefits of having a perfect git history outweigh the costs. A temporal log of changes is good enough for me.
  - placatedmayhem 4y ago
    Specifically, more atomic commits make rollbacks easier when issues with a change are discovered after merge (e.g., in integration and user acceptance testing). In the very active code bases I've worked on, generating a rollback commit for a single commit is far more straightforward than having to deal with a merge commit that potentially includes other merges (e.g., with `git pull`'s default behavior). In fact, GitHub's pull request UI has it as a single button.
    - thunky 4y ago
      Wouldn't these types of changes more commonly be caught while testing against a branch? Also in many cases I would think that the fix ends up being even smaller (or bigger) than a single commit (the commit isn't actually atomic). Maybe the codebases I've worked on weren't active enough for this to be a common problem. But also, having too many cooks in the kitchen may be a part of the problem here too.
rubyist5eva 4y ago
Personally, I actually stopped using rebase or advocating it's use (because noobies mess up their history all the time with it). I just commit whatever, then when the code is merged to trunk/dev/master/whatever I use `merge --squash`. Reviews are very rarely happening on the commit level, so having lots of small "meaningless" commits (lint fixes, fix spec, add thing) hasn't been an issue but having squashed merge commits (effectively a rebase that squashes everything) has made release management so much easier for our team. It also has the benefit of just less cognitive overhead of micro-managing my feature branch commits that are WIP or currently in-review.
- jokab 4y ago
  Thanks. I thought it was just me.
- dabears 4y ago
  This is my workflow as well, it's great. Github is configured so merging a PR into master will automatically produce a squashed commit. My rule of thumb, always rebase unless you hit a series of merge conflict while rebasing. Then either merge, or squash your branch then re-run the rebase.
  - rubyist5eva 4y ago
    We require linear history on our shared mainline branches so the squash workflow works great for us using Github as well. Another benefit is the "show changes since last review" option when reviewing a PR - it's been a while but I'm not sure if this is possible with a rebase-based workflow.
gregmac 4y ago
> Rebase has become so integral to my workflow, it's hard to imagine living without it I'm the same. I commit frequently. A lot of those end up being `--amend`, but a lot of time I will rebase and squash/reorder/etc. In fact I'd say the majority of time I push changes I've rewritten my local history at least once. According to any git history you'd find from me on the server, you'd think I never accidentally commit syntax errors, break unit tests, and that when I do big structure changes or refactors I get it the way I want it on my first attempt. > including configuring git pull to rebase rather than merge It annoys me a bit this isn't the default -- at least for teams that work from a single centralized git repo (eg: almost all corporate dev, and the majority of open source). I've done it for years and have never had any issue with it. It doesn't rewrite anything but your local (non-pushed) history, which is totally fine. (Unless you are working with multiple remotes, in which case it causes chaos, which I think is why it isn't the default). Are there other drawbacks?

robertlagrant 4y ago

This might be obvious, but it's worth checking out git commit --amend. Then you can be regularly committing, but to the same commit.

shagie 4y ago
--amend would interact with the remote system poorly if there's a push with each commit.
- sjburt 4y ago
  You have to force push, but you have to do that when pushing a rebased branch as well. In either case it’s a history rewrite. It’s not a big deal unless other people have pulled that branch—if they have they will need to reconcile things on their end as well.
dnsmichi 4y ago
Depending on the workflow and collaboration in branches in teams, amending may not be ideal. Amending changes to an existing commit will generate a new sha checksum, thus resulting in a diverging history if the branch is often pushed to the remote Git server. That's one of the rare cases where "git push --force" makes sense but also requires awareness for other collaborators on the branch - they need to run "git fetch && git reset --hard origin/branchname" every time, and best "git stash" to temporarily remove any local changes, with running "git stash pop" afterwards. One reason to regularly push commits can be to trigger CI/CD, security scanning and dev/staging deployments or review apps. GitLab team member here - before joining GitLab in 2020, I was a Git/GitLab trainer. https://www.netways.de/en/blog/2018/05/24/releasing-our-git-and-gitlab-training-as-open-source/ https://www.netways.de/en/blog/2018/05/24/releasing-our-git-...
- tspike 4y ago
  I've completely replaced my use of --force with --force-with-lease. It does the same thing, except it will abort if the upstream branch has been updated since your last pull. This pretty much prevents the concerns about clobbering others' work.
  - dnsmichi 4y ago
    After reading this comment about "git push --force-with-lease" in https://stackoverflow.com/a/53011907/1821348 https://stackoverflow.com/a/53011907/1821348 my workflows with "git fetch" first would not work with "git push --force-with-lease", behaving as if "git push --force" was run. Theoretically - I need to do some testing here. Thanks for the pointer into learning something new :)
- robertlagrant 4y ago
  For sure, it doesn't work with every workflow. But I think it would for the OP's described workflow. And I am currently waiting for my GitLab backpack for contributing something (very small, but apparently it counted!) so thank you to the team for that!
  - dnsmichi 4y ago
    Thanks for sharing your ideas, appreciate the thoughts to learn new perspectives :-) And also thanks for contributing, every contribution counts and helps :-) Maybe see you at a future hackathon :) https://about.gitlab.com/community/contribute/ https://about.gitlab.com/community/contribute/
usr1106 4y ago
--amend if you have a modification to your most recent commit. --fixup if you have a modification to an earlier commits rebase --autosquash amend the fixup(s) to the commit(s) they belong too. (Of course you need to know what you doing. Otherwise you create conficts tedious to resolve in the rebase)

agumonkey 4y ago

then there's autosquash and similar honestly the commit graph as a first-class value yields a lot of ideas in my mind, we should be investigating compute at the subtree layer more often.

rrwo 4y ago

> Rebase has become so integral to my workflow, it's hard to imagine living without it. Same. I use it to reorganise branches before submitting change requests or merging: - Combing or splitting commits so that each commit contains a small unit of a logical change - Reordering commits to related changes are near each other - Reordering commits so changes that are depended on by later commits occur earlier. - Rewording commit descriptions to have a lengthy explanation, if needed - Removing small commits that fix minor typos It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change. (I had a colleague who was so used to CVS and couldn't get his head around not using version control as a time tracking device.)

thunky 4y ago
> It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change. This seems a bit like an unhealthy obsession. I would be curious to know if the benefits of having a perfect git history outweigh the costs. A temporal log of changes is good enough for me.
- placatedmayhem 4y ago
  Specifically, more atomic commits make rollbacks easier when issues with a change are discovered after merge (e.g., in integration and user acceptance testing). In the very active code bases I've worked on, generating a rollback commit for a single commit is far more straightforward than having to deal with a merge commit that potentially includes other merges (e.g., with `git pull`'s default behavior). In fact, GitHub's pull request UI has it as a single button.
  - thunky 4y ago
    Wouldn't these types of changes more commonly be caught while testing against a branch? Also in many cases I would think that the fix ends up being even smaller (or bigger) than a single commit (the commit isn't actually atomic). Maybe the codebases I've worked on weren't active enough for this to be a common problem. But also, having too many cooks in the kitchen may be a part of the problem here too.

rubyist5eva 4y ago

Personally, I actually stopped using rebase or advocating it's use (because noobies mess up their history all the time with it). I just commit whatever, then when the code is merged to trunk/dev/master/whatever I use `merge --squash`. Reviews are very rarely happening on the commit level, so having lots of small "meaningless" commits (lint fixes, fix spec, add thing) hasn't been an issue but having squashed merge commits (effectively a rebase that squashes everything) has made release management so much easier for our team. It also has the benefit of just less cognitive overhead of micro-managing my feature branch commits that are WIP or currently in-review.

jokab 4y ago
Thanks. I thought it was just me.
dabears 4y ago
This is my workflow as well, it's great. Github is configured so merging a PR into master will automatically produce a squashed commit. My rule of thumb, always rebase unless you hit a series of merge conflict while rebasing. Then either merge, or squash your branch then re-run the rebase.
- rubyist5eva 4y ago
  We require linear history on our shared mainline branches so the squash workflow works great for us using Github as well. Another benefit is the "show changes since last review" option when reviewing a PR - it's been a while but I'm not sure if this is possible with a rebase-based workflow.

gregmac 4y ago

> Rebase has become so integral to my workflow, it's hard to imagine living without it I'm the same. I commit frequently. A lot of those end up being `--amend`, but a lot of time I will rebase and squash/reorder/etc. In fact I'd say the majority of time I push changes I've rewritten my local history at least once. According to any git history you'd find from me on the server, you'd think I never accidentally commit syntax errors, break unit tests, and that when I do big structure changes or refactors I get it the way I want it on my first attempt. > including configuring git pull to rebase rather than merge It annoys me a bit this isn't the default -- at least for teams that work from a single centralized git repo (eg: almost all corporate dev, and the majority of open source). I've done it for years and have never had any issue with it. It doesn't rewrite anything but your local (non-pushed) history, which is totally fine. (Unless you are working with multiple remotes, in which case it causes chaos, which I think is why it isn't the default). Are there other drawbacks?