4 ms·

I understand generally what Git is doing, but when you start throwing in very specific words like "rebase" my eyes start to glaze over. Not because they aren't

I understand generally what Git is doing, but when you start throwing in very specific words like "rebase" my eyes start to glaze over. Not because they aren't important concepts, but because I can't stop the nagging feeling that it shouldn't be this complicated (it probably should though). But it isn't complicated! When you use a decent UI tool. I know pretty much exactly how VSCode's UI behaves with Git, along with the Git History plugin. And now I have a perfectly usable workflow and never have to use the command line, and almost never have any merge conflicts. Maybe this is common knowledge to all of you, but it seems to me a lot of people have Git headaches, so maybe they don't know this? 1. Pull latest from remote main branch (select the branch, hit the sync button; permissions structure prevents any accidental pushes) 2. Create new branch based on pulled branch. If I have stashed work, apply it now. 3. Do work 4. Use the + icon to stage individual changes and give them their own local commit 5. Push my local branch to remote (hit that sync button again) 6. In my remote repo UI push the button to create a Pull Request (I assume all shared repos have a PR button somewhere?) 7. Go back to doing local work, but don't commit yet, and continue "not committing" for now 8. After the PR has been merged into main, stash everything including untracked (pick it from the VSCode menu) 9. Go back to step 1, repeat Steps 7 and 8 are how you avoid creating your own merge conflicts. If you keep committing while a PR is in flight, then later on Git will see your earlier changes to a file, and your later changes to the same file, and will see them as a conflict. So just do yourself a favor and never commit to a branch while anything in its history is part of an in-flight PR. Obviously you'll have to deal with merge conflicts with other people but at least you aren't creating your own headache. Git History saves me when I goof up and commit locally when I shouldn't. I just pull up the history and click the soft reset button prior to my commit and presto, I'm back where I want to be (files uncommitted, back in pending changes list). Maybe one day I'll learn the Git command line, but right now why bother?

blep_ 4y ago
Stash -> pull -> unstash is just manual rebase, though. You're already doing the thing you're claiming not to do, you're just doing it the hard way. Which is fine, if that works for you! Just know that you're using different terms for the same thing (do some work on top of A, then move it to be on top of B instead).
- chociej 4y ago
  Soft reset is a rebase too
- MetaWhirledPeas 4y ago
  Now you've piqued my interest.
  - OkayPhysicist 4y ago
    Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all your commits, you can choose to exclude some from the rebase (useful if you had to update something specifically because it gets updated between every PR/build), then commit to the rebase. It will then proceed to replay each commit you made, just like a repeated version of your stash/unstash process, on top of the new top of the master branch. Your working branch is now contains all the changes you made, but instead of working off your PR commit, it's like you were working off of the finished PR commit. If you want to make sure that your git history maintains the old branch for sentimental reasons (or you want to try out removing some commits and desire an easy way to rollback if you get lost), just make a branch off of your working branch before the rebase. That branch will be identical to the branch you were working on, before the rebase. A---B---C topic / PR Branch P---R---S \ O---L---D---E master (where commit D and E are produced as part of the PR, say, the merge commit and a version number crank or something) (checked out topic) git rebase master PR Branch P---R---S A---B---C topic \ / O---L---D---E master magic
    - MetaWhirledPeas 4y ago
      This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And "rebase" is a scary word choice regardless. Perhaps you remember when you were new to Git and can relate. I may give rebase a try at some point, to see if perhaps it might speed me up. The vast library of Git commands is a bit much for me though. It's like using an aircraft cockpit to control the television!

blep_ 4y ago

Stash -> pull -> unstash is just manual rebase, though. You're already doing the thing you're claiming not to do, you're just doing it the hard way. Which is fine, if that works for you! Just know that you're using different terms for the same thing (do some work on top of A, then move it to be on top of B instead).

chociej 4y ago
Soft reset is a rebase too
MetaWhirledPeas 4y ago
Now you've piqued my interest.
- OkayPhysicist 4y ago
  Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all your commits, you can choose to exclude some from the rebase (useful if you had to update something specifically because it gets updated between every PR/build), then commit to the rebase. It will then proceed to replay each commit you made, just like a repeated version of your stash/unstash process, on top of the new top of the master branch. Your working branch is now contains all the changes you made, but instead of working off your PR commit, it's like you were working off of the finished PR commit. If you want to make sure that your git history maintains the old branch for sentimental reasons (or you want to try out removing some commits and desire an easy way to rollback if you get lost), just make a branch off of your working branch before the rebase. That branch will be identical to the branch you were working on, before the rebase. A---B---C topic / PR Branch P---R---S \ O---L---D---E master (where commit D and E are produced as part of the PR, say, the merge commit and a version number crank or something) (checked out topic) git rebase master PR Branch P---R---S A---B---C topic \ / O---L---D---E master magic
  - MetaWhirledPeas 4y ago
    This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And "rebase" is a scary word choice regardless. Perhaps you remember when you were new to Git and can relate. I may give rebase a try at some point, to see if perhaps it might speed me up. The vast library of Git commands is a bit much for me though. It's like using an aircraft cockpit to control the television!