Comment by MetaWhirledPeas | Hacker News Reader

Comment by MetaWhirledPeas | Hacker News Reader

MetaWhirledPeas

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?

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

Now you've piqued my interest.

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

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!

I definitely sympathise with the confusing and scary command names! "reset" is the worst in my opinion. Rebase is kind of the natural choice once you understand the data model, but it doesn't necessarily make it more approachable.

`git rebase main` will modify your currently checked out branch to make the commits on that branch now branch off of the current value of main. It won't update main or modify it in any other way, only your current branch. You can equally `git rebase 347ae9` to have them come off a specific commit.

If you know what a tree is (in the general computer science sense, not the git term of art) it's well worth taking a little time to learn the underlying data model in my opinion.

Thanks, that's useful information!

There's also `git pull --rebase`, which is just "pull like normal, then rebase onto the thing I just pulled".

Remember that it's okay to screw around and break stuff! Sometimes that's the best way to learn. Git's whole thing is tracking history, even the history of the history itself[0]. It is hard to accidentally lose something if you've committed it at least once.

If you're nervous, push your branch somewhere before starting (it's not strictly necessary, but it's the easiest way to get peace of mind).

Nothing you do locally will be pushed back to the remote unless you explicitly do `git push`. If you manage to screw up your branches so badly you don't know how to recover, you can just delete the local branch you broke and re-pull the remote one like it's a new branch, even if it's main/master.

[0] https://ohshitgit.com/, especially the first thing there

> It's like using an aircraft cockpit to control the television!

It's not a television though. It's a set of tools used to manipulate a tree-like data structure that you're using to store your versions and reconcile changes across multiple trees. Once you approach it with that in mind and can imagine the high level data structure in your head, using it becomes almost as natural as using a hammer for a nail.

Rebasing is nothing more than changing the location a pointer ("branch") points at and then moving some nodes from one tree branch to another (in exactly the same way cherry picking works). It's really simple to visualize, you just need to have that tree in your mind already.

Soft reset is a rebase too

Reply on news.ycombinator.com