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

51–60 of 77 posts

Re: Git Workflow Basics

#51

Post by dimino »

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.

I don't know about rebasing everything, but a commit is a changeset, and a changeset should always have a distinct and succinct purpose. There is no value added in having a single feature spread out over 5 commits.

When writing a feature, I use git to save my progress, and once I'm done, I would like to present the feature as a clear and complete changeset. A commit is me saying, "These are the changes I'd like to make to the codebase", and I feel that argument is easier to make when I present one thought, rather than the dozens of thoughts I had on the way.

If I were perfect, then I would commit in a way that was one cohesive thought, but I'm not. My commits are often, "Did the thing", then "redid the thing, with better testability", and "Re-redid the thing, fixing some fundamental bug in how I did the thing at first", etc.

Re: Git Workflow Basics

#52

Post by steveklabnik »

Karunamon wrote: post #50
steveklabnik wrote: post #46

Earlier quoted context omitted.

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.

I tend to write documentation, so no, not a bug. But even then, there's lots of small code-review things that aren't always about bugs; project style, naming conventions, etc.

Furthermore, if this is a PR that's open, then the "bug" would have never even landed. So looking through history to "find what caused the bug" would have not even been a thing.

Re: Git Workflow Basics

#53

Post by _ikke_ »

dimino wrote: post #49
K0nserv wrote: post #29

Earlier quoted context omitted.

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.

When people talk about public commits it means commits other people have access too, and more specific, were able to commit on top. Authorization has nothing to do with it. In practice it means anything you have pushed.

An exception can be made for topic branches, especially in a pull-request workflow. These branches could be rebased / amended to update the final result, even after they have been pushed already.

Re: Git Workflow Basics

#54

Post by K0nserv »

dimino wrote: post #49
K0nserv wrote: post #29

Earlier quoted context omitted.

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.

Yeah maybe public isn't a good term for it, I usually use the term stable. So any pushed commits are indeed public, but they are only stable when they reach a stable branch. This means that if I am working on a branch I may remove, add, amend, reorder commits even after I've pushed them. If you constrain rebasing only to unpushed(not public) commits then you instead end up discouraging pushing code to the remote.

Re: Git Workflow Basics

#56

Post by dimino »

_ikke_ wrote: post #53
dimino wrote: post #49

Earlier quoted context omitted.

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

When people talk about public commits it means commits other people have access too, and more specific, were able to commit on top. Authorization has nothing to do with it. In practice it means anything you have pushed. An exception can be made for topic branches, especially in a pull-request workflow. These branches could be rebased / amended to update the final result, even after they have been pushed already.

"commits other people have access to"

That's authorization.

Re: Git Workflow Basics

#57

Post by _ikke_ »

dimino wrote: post #56
_ikke_ wrote: post #53

Earlier quoted context omitted.

When people talk about public commits it means commits other people have access too, and more specific, were able to commit on top. Authorization has nothing to do with it. In practice it means anything you have pushed. An exception can be made for topic branches, especially in a pull-request workflow. These branches could be rebased / amended to update the final result, even after they have been pushed already.

"commits other people have access to" That's authorization.

You said:

> anything accessible without any authorization.

Even if it does require authorization, it's considered public in regard to this discussion.

Re: Git Workflow Basics

#58

Post by weaksauce »

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…

If you are planning on doing some tricky rebase with possible problems you can just create a branch before you rebase on the old head. delete the branch when you know the rebase is successful. Then you don't have to deal with the reflog at all.

Re: Git Workflow Basics

#59

Post by alanfranzoni »

igor_marques wrote: post #3
alanfranzoni wrote: post #2

At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/

Nothing stops you to use continuous integration with this workflow. For instance, Travis-CI and Codeship support branching (they can tell you if the new build will be fine or not). I didn't mention that in the post because it's intended for beginners and adding that info there could maybe be a little too much :/

Sure, most CI systems support branching.

But what if you need to do ship a full pipeline of a branch for multi-repository project? I clarify the issue better in my post.

Re: Git Workflow Basics

#60

Post by alanfranzoni »

fredoliveira wrote: post #16
alanfranzoni wrote: post #2

At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/

Your suggestion feels a little misguided. You end your post by saying that you contest the a priori idea of branching, but seem to forget everything that is right about branching in the first place: * Want to see the history for a specific feature? Impossible in your proposal, native in a feature/topic branching model. * Want to do a code review on a specific feature? Again, impossible in your proposal, trivial in a…

Hello Fred, thanks for your interest.

about the history for a feature: most branching based workflows prefer squashing commits when merging, so most probably the history is lost whatsoever.

you're right I didn't explain how I do code reviews - and, effectively, I usually prefer pair programming when pushing, and after-the-commit code reviews - but before the feature is toggled on by default.

There's a reason for this, I usually say that a review should review the status after a merge, not just a change; many a times I've seen reviews for a PR that miss the whole point, along the lines of "the change is good, even though the resulting merged code is complete mess"; on the contrary, if you review a certain commit before toggling a feature on, you're basically declaring that the code, at the point, is basically good. Yes, it may be hard for a large codebase, and often reviews are done by looking at what changed, and not at everything.

But I've seen many, many, many stupid errors done or overlooked because people just looked at the change and not at the whole code after such change.

Post reply on HN