6 ms·

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be

Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.

tapirl 1y ago
just when you face some unusual situations ...
killerstorm 1y ago
If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.
- km144 1y ago
  A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.
- Cthulhu_ 1y ago
  As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times. For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well. Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.
- alexjplant 1y ago
  > A lot of people are religious about rebasing Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation. When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.
  - raylu 1y ago
    wait what? bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear
amomchilov 1y ago
Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.
- Too 1y ago
  git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly and reorder the commits with interactive rebase to insert the revert first. It’s a bit hard to explain without an example, once you’ve tried it you will understand.
  - baq 1y ago
    > as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. A vcs can allow you to commit conflicts and then commit their resolutions whenever necessary. This has been pioneered by darcs (IIRC) and jj also allows that.
  - raylu 1y ago
    `git rebase -i` lets you reorder one branch of commits easily in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)
- Cthulhu_ 1y ago
  Check out the rebase.updateRefs option: https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c

tapirl 1y ago

just when you face some unusual situations ...

killerstorm 1y ago

If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.

km144 1y ago
A lot of the time, multiple devs working on a single branch can be avoided via different decisions made upstream about work that needs done. If my job included more git wrangling as one of my daily tasks I would probably hate my job.
Cthulhu_ 1y ago
As soon as you have the situation of multiple people working on the same branch, forbid force pushes at all times. But it's better to avoid that in the first place, all work should be on its own branch at all times. For larger features we often have a feature branch with merge requests for various task branches. Limits the review sizes as well. Of course, you can also then consider to use feature toggles, so there's no feature branch but just your main branch.
alexjplant 1y ago
> A lot of people are religious about rebasing Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation. When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.
- raylu 1y ago
  wait what? bitbucket will merge a PR from your feature branch onto the base branch even if it's not fast-forward from the base branch. as long as you use the "squash" or "rebase" option on the PR interface (instead of the "merge" option), the resulting history will be linear

amomchilov 1y ago

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews. Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

Too 1y ago
git rebase -i lets you reorder commits easily, as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. One cool tip to help with conflicts is the revert trick. If you have a conflict that you need resolved earlier in your commit chain, you can commit a cleanup that hides the conflict, revert it instantly and reorder the commits with interactive rebase to insert the revert first. It’s a bit hard to explain without an example, once you’ve tried it you will understand.
- baq 1y ago
  > as long as they don’t have conflicts. If they do, you’re in for a rough time. I struggle to see how a vcs could help with that, even if I’d be happy to be proven wrong. A vcs can allow you to commit conflicts and then commit their resolutions whenever necessary. This has been pioneered by darcs (IIRC) and jj also allows that.
- raylu 1y ago
  `git rebase -i` lets you reorder one branch of commits easily in a stacked PR workflow, after the bottom PR merges, you now want to rebase the whole stack atop the main branch. if that's 3 PRs, that's 3 branches, 3 rebases one thing `git rebase` doesn't let you do but `jj rebase -s source -d dest` does is move a commit from one branch to another (`git switch dest`, `git cherry-pick source`, `git switch -C source source^`, `git switch dest`)
Cthulhu_ 1y ago
Check out the rebase.updateRefs option: https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c https://dev.to/onepoint/git-update-refs-in-a-nutshell-574c