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

41–50 of 77 posts

Re: Git Workflow Basics

#41

Post by steveklabnik »

Karunamon wrote: post #40

Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical) But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.

  > more aesthetic than functional
It is easier to understand a cleaner history than a messy one.

  > haven't you lost that?
You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.

Re: Git Workflow Basics

#42

Post by Karunamon »

steveklabnik wrote: post #41
Karunamon wrote: post #40

Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical) But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.

> more aesthetic than functional It is easier to understand a cleaner history than a messy one. > haven't you lost that? You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.

Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back.

Re: Git Workflow Basics

#43

Post by K0nserv »

Matt3o12_ wrote: post #39

How do you guys approach the one branch per developer rule? For smaller changes, i do it all the time but it is very hard for bigger changes. When we write bigger features we always need at least two dev. One writing the front end (HTML templates) and one the backend (whatever populates the templates, makes sql query). We both need immediate feedback. I design the models around the templates so i need the templates a…

Do what you say and both work in the same branch. If the branch diverges from master and you need to catch synchronize and then one of you does a rebase the other does git reset --hard origin/feature-branch. Alternatively just leave any cleanup till the end of the MR and designate one person to it

Re: Git Workflow Basics

#45

Post by golergka »

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…

Why squash merge instead of simple merge?

Re: Git Workflow Basics

#46

Post by steveklabnik »

Karunamon wrote: post #42
steveklabnik wrote: post #41

Earlier quoted context omitted.

> more aesthetic than functional It is easier to understand a cleaner history than a messy one. > haven't you lost that? You've lost the ability to look through one kind of history, but not other ones. bisect still works if you've rebased.

Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back .

Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time.

You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-character diff, or one commit that's perfect, an easier to understand history? What is actually lost by "throw[ing] away history that you can never get back"?

If it had been right in the first time, that history would have never even existed in the first place. So you end up with the exact same thing.

Re: Git Workflow Basics

#49

Post by dimino »

K0nserv wrote: post #29
rralian wrote: post #22

Earlier quoted context omitted.

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

That's a weird definition of 'public'; for most folks, I imagine 'public' to mean anything accessible without any authorization.

Re: Git Workflow Basics

#50

Post by Karunamon »

steveklabnik wrote: post #46
Karunamon wrote: post #42

Earlier quoted context omitted.

Only easier to understand if the commit messages suck. If your commit messages are descriptive, and each commit is an atomic unit of work (in other words: following best practices) rebasing has thrown away history that you can never get back .

Right, but often, that's not something that happens the first time around. The idea is that you rebase in order to get that kind of history 100% of the time. You cannot get things perfect on the first try; this is part of the whole principle of code review. When my patch is perfect, except for that one little typo, what should be done? Is a history with two commits, one amazing, one saying "fix typo" with a one-chara…

Did that typo fix introduce a bug? Maybe, maybe not, but many programmer hours have been wasted on incorrect single characters :)

If I were bisecting that repo, it's a lot easier and more useful to be able to point the finger at the one commit that actually changed the line, rather than having to parse the one monster squashed commit to find the one line that introduced the bug.

Post reply on HN