Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git Workflow Basics

blog.codeminer42.com

Post reply on HN
Print view View original

21–30 of 77 posts

Re: Git Workflow Basics

#21

Post by dangerlibrary »

DougWebb wrote: post #19
nhance wrote: post #5

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…

Rebase is absolutely a part of my everyday workflow, and the rest of my team's workflow as well. (Yesterday I had to show our CTO how to use it, because the rest of the team was getting annoyed by his merge commits.) Our workflow is: - locally, commit to local master or a local branch - occasionally checkout local master (if necessary) and pull using the 'rebase after fetch' option. - if we had local master commits,…

> annoyed by his merge commits

Getting rid of merge commits is literally the only benefit of your workflow over the standard branching model.

Re: Git Workflow Basics

#22

Post by rralian »

tanderson92 wrote: post #9
nhance wrote: post #5

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…

But some of us use git-rebase every day perfectly fine and never lose information. Yes, you must be careful. No, you should never use it on public commits. I wouldn't recommend it to others as I don't trust them to read the man page and understand what git-rebase does. Those of us who use git-rebase also know how to recover the refs since before they are GCed, though I've never had to do that. It's dangerous to prono…

And we use git-rebase commonly on public commits without concern. Everyone uses git differently.

Re: Git Workflow Basics

#23

Post by edbrown23 »

nhance wrote: post #5

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…

At least locally within your repo, it's actually very hard to lose work completely with git, via any combination of resets or rebases. The reflog (git reflog) stores all the movements of HEAD such that you can recover from almost any mistake as long as you realize you made it.

The fear of rebase seems to always come from its ability to "delete your work", but that fear is almost always unfounded and based on a lack of knowledge on git's internal structures. Of course, one of git's biggest and well recognized faults is that its UI makes no attempt to alleviate those fears.

Re: Git Workflow Basics

#24

Post by steveklabnik »

stormbrew wrote: post #18
steveklabnik wrote: post #17

Earlier quoted context omitted.

> A squash merge is a rebase. Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch. But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this:

    C -> D -> E
   /
  A -> B
then you "squash merge"

    S------
   /       \
  A -> B -> F
where S is C + D + E.

Whereas a rebase + (now fast-forward) merge would be

  A -> B -> C' -> D' -> E'
and, if squashed during rebase -i or by some other means

  A -> B -> S
It seems you're saying a "squash merge" is the last one, I thought it was the second one.

Re: Git Workflow Basics

#25

Post by pjc50 »

DougWebb wrote: post #19
nhance wrote: post #5

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…

Rebase is absolutely a part of my everyday workflow, and the rest of my team's workflow as well. (Yesterday I had to show our CTO how to use it, because the rest of the team was getting annoyed by his merge commits.) Our workflow is: - locally, commit to local master or a local branch - occasionally checkout local master (if necessary) and pull using the 'rebase after fetch' option. - if we had local master commits,…

Merge commits on pull are an annoying misfeature of the default workflow, but I thought you could fast-forward on pull to eliminate them?

Re: Git Workflow Basics

#26

Post by drakenot »

nhance wrote: post #5

This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…

I completely disagree with this. You can easily undo a rebase locally if you mess up by resetting to hashes you pull out of the reflog.

When I'm dealing with my own work branches -- I absolutely rebase my commits before submitting a pull request to my team. I'll either squash irrelevant commits or I'll reword poorly written git commit messages. I also almost always default to `get pull --rebase` as well, as I hate the noise of merge commits littering up my commit log.

Re: Git Workflow Basics

#27

Post by stormbrew »

steveklabnik wrote: post #24
stormbrew wrote: post #18

Earlier quoted context omitted.

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch. But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this: C -> D -> E / A -> B then you "squash merge" S------ / \ A -> B -> F where S is C + D + E. Whereas a rebase + (now fast-forward) merge would be A -> B -> C' -> D' -> E' and, if squashed during rebase -i or by some other means A -> B -> S It seems you're saying a "squash merge" is the last one, I thought it was…

I'm sure someone out there does it like that (the joy and pain of git being there's a million ways of doing things), but the name I think is derived from the idea that you're replacing a merge commit with a squash of the disjoint parent, rather than a merge of a squash.

Also it's entirely possible I'm wrong, I'm a fan of merge bubbles (sometimes rebased for clarity), and avoid large squashes in general, so maybe I just don't understand how people do it. I don't know why you'd bother to keep both a merge and squash commit around, though.

Re: Git Workflow Basics

#28

Post by tomstuart »

steveklabnik wrote: post #24
stormbrew wrote: post #18

Earlier quoted context omitted.

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch. But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this: C -> D -> E / A -> B then you "squash merge" S------ / \ A -> B -> F where S is C + D + E. Whereas a rebase + (now fast-forward) merge would be A -> B -> C' -> D' -> E' and, if squashed during rebase -i or by some other means A -> B -> S It seems you're saying a "squash merge" is the last one, I thought it was…

That’s right. `git merge --squash` doesn’t even make a commit, it just updates the working tree and index to look like the post-merge contents — it’s then up to you to actually commit. So yeah, you don’t even end up with a merge commit.

Re: Git Workflow Basics

#29

Post by K0nserv »

rralian wrote: post #22
tanderson92 wrote: post #9

Earlier quoted context omitted.

But some of us use git-rebase every day perfectly fine and never lose information. Yes, you must be careful. No, you should never use it on public commits. I wouldn't recommend it to others as I don't trust them to read the man page and understand what git-rebase does. Those of us who use git-rebase also know how to recover the refs since before they are GCed, though I've never had to do that. It's dangerous to prono…

And we use git-rebase commonly on public commits without concern. Everyone uses git differently.

I think this depends on your definition of public? For me public means "in stable branches". I sure hope you aren't rebasing master

Re: Git Workflow Basics

#30

Post by steveklabnik »

stormbrew wrote: post #27
steveklabnik wrote: post #24

Earlier quoted context omitted.

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this: C -> D -> E / A -> B then you "squash merge" S------ / \ A -> B -> F where S is C + D + E. Whereas a rebase + (now fast-forward) merge would be A -> B -> C' -> D' -> E' and, if squashed during rebase -i or by some other means A -> B -> S It seems you're saying a "squash merge" is the last one, I thought it was…

I'm sure someone out there does it like that (the joy and pain of git being there's a million ways of doing things), but the name I think is derived from the idea that you're replacing a merge commit with a squash of the disjoint parent, rather than a merge of a squash. Also it's entirely possible I'm wrong, I'm a fan of merge bubbles (sometimes rebased for clarity), and avoid large squashes in general, so maybe I ju…

No, I think you're right; take a look at the graphs on https://github.com/blog/2141-squash-your-commits for example.

I don't know why you'd want to do it that way either! But I also don't understand why you'd want to "never rebase", so when it comes to git, I assume that someone has reasons for doing all kinds of things I don't understand.

Post reply on HN