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

This is how I git

daniel.haxx.se

Post reply on HN
Print view View original

51–60 of 140 posts

Re: This is how I git

#51

Post by jgraham »

ricardobeat wrote: post #43

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. Rebasing feature branches, and avoiding non-ff merges has been the best change I've ever made to my workflow. Makes it very easy to keep a clean, readable history that is actually useful when doing code archeology months later. Resolving conflicts is far eas…

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages:

* It's clear which states master has actually been in, without having to resort to squashing each merge into a single commit. This means that you know which commits actually passed CI and are therefore good rebase targets. People often claim that when merging multiple commits each commit should individually pass CI, but that's almost impossible to achieve in practice.

* Development can split single features into multiple commits for easier review and understanding later. This can be particuarly important if the changes depend on each other, but different people need to review different parts of the overall change. That's another thing that most tooling is really bad at.

* The history is basically linear. The merge commits are all empty, and there is one linear history for all the states of master (the first parent of each merge commit) and one linear history for all the individual commits (the second parent of each merge commit and only parent of each non-merge commit).

Of course this approach isn't well supported by mainstream tooling (e.g. GitHub) and probably requires a custom bot to do all the rebase-and-merge operations. It is pretty well supported by git itself, however.

Re: This is how I git

#53

Post by _ZeD_ »

formerly_proven wrote: post #20

> I use git almost exclusively from the command line in a terminal. Is certainly key. Most git frontends seem to be really quite bad for many reasons. Though "Push failed, want to pull, merge and push again? [Yes]" => constant "merged ssh://upstream.server/foo/bar/repo.git merged into branch master" commits being added to the history certainly irks my OCD the most. These frontends also seem to try and hide what git d…

do yourself a favour and look at the eclipse git client

Re: This is how I git

#54

Post by Cogito »

barumi wrote: post #44
Cogito wrote: post #9

Earlier quoted context omitted.

It's not git-flow, as all commits are rebased on top of master to make the history of master linear. It is one of the more standard workflows, and it's a concise overview of how the maintainer of curl does their job. For a more complex workflow, I recommend reading the notes from the maintainer of the git project [0]. 0: https://git.wiki.kernel.org/index.php/MaintNotes

> It's not git-flow, as all commits are rebased on top of master to make the history of master linear. I fail to see how that is relevant. I mean, the only possible impact that has is if individual commits within a feature branch are recorded or not, which is arguably irrelevant. You wouldn't get a different workflow if instead of reading you simply did a squashed merge. > It is one of the more standard workflows, an…

I don't know what you think git-flow is, but a linear history it is not.

Look at any post on git-flow (or even just the original [0]), and you will see a myriad of merges.

Quoting the original git-flow post:

> When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.

The examples further on all use `git merge --no-ff` (ie no fast forward).

This is very different to what is described in this post:

> When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. This makes the branch very easy to browse, understand and work with – as it is 100% linear.

So no, this is not git-flow.

[0] https://nvie.com/posts/a-successful-git-branching-model/

Re: This is how I git

#55

Post by cjfd »

berbc wrote: post #37
cjfd wrote: post #35

The ease of branching has people treat branches as if they were cookies. You cannot possibly have too many of them. But, actually, branches make refactoring more difficult. What if one person just added a parameter to a function while another person is adding new calls to that same function. The automated merge cannot fix this conflict. The KISS principle that is the corner stone of all software development would dic…

As said in one of the YouTube comments for the video you linked here, it's not so much feature branches that are the problem, but long-lived feature branches. If you want to add a complex feature to a project, you could do it via several branches, one after the other. For instance, the first branch could introduce a feature flag and the second branch implement part of the new feature, and so on.

This is more of a semantic quibble than anything else. Yes, long-lived branches are not just a problem but absolutely terrible. I have seen one that lived for some 4 years or so. They are a problem to the extend that they live long. The shorter they live the less of a problem they are. So, take this to its conclusion and conclude that the best feature branch is one that is only one small commit long. And now the feature branch is completely redundant....

Re: This is how I git

#56

Post by gwenzek »

ricardobeat wrote: post #43

The most important bit in my opinion: > When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. Rebasing feature branches, and avoiding non-ff merges has been the best change I've ever made to my workflow. Makes it very easy to keep a clean, readable history that is actually useful when doing code archeology months later. Resolving conflicts is far eas…

The issue is that Git sucks at rebasing. Every conflict you fix when rebasing will need to be fixed again next time you rebase.

Re: This is how I git

#57

Post by Cogito »

DJHenk wrote: post #38
nemetroid wrote: post #33

Earlier quoted context omitted.

Who said they were unrelated? Sometimes a single commit is the best presentation of a bug fix/feature implementation, sometimes it makes more sense to split the work into multiple commits.

I can understand that. But in my mind, if things are separate enough that I want multiple commits, then I would work on them separately. If a feature needs A, but A needs B, then I would work on B, commit that and only then work on A. Sometimes working on A will cause me to change the committed B part a little, but that's fine. At the moment in time that I committed B it was a perfectly reasonable solution that I can…

For me, I often don't know exactly how I am going to do something until I have done it.

Once it's done I will split the changes into commits that make logical sense, for someone wondering how the new code changes the behaviour of the existing code.

Re: This is how I git

#58

Post by leegraham »

boltzmannbrain wrote: post #45

+1 "Never merge with GitHub... I don’t feel that I have the proper control"

Me neither, not since I got bitten by the 'Resolve Conflicts' button on the PR page also merging the PR into the target branch.

Maybe it's PEBCAC, and to be fair it is documented[0], but the big red warning in the docs is missing from the page where you actually do the action. To make it more confusing there's also a disabled 'Merge pull request' button that implies that resolving the conflicts and merging the PR are separate actions

0: https://docs.github.com/en/free-pro-team@latest/github/colla...

Re: This is how I git

#59

Post by globular-toast »

modderation wrote: post #34
globular-toast wrote: post #12

Earlier quoted context omitted.

It's not git flow. Git flow is horrendous, completely unnecessary and designed by someone who doesn't understand git. The article describes a pretty standard git rebase workflow that is simple and works well.

Git Flow actually makes some sense if you need to track and retain history of self-contained fixes and features across concurrent release trains, where "retain history" means more than just a commit message. With that said, I don't think this need is particularly common. Most projects are happier to throw away merge history in favor of a linear history with ephemeral branches and semantic versioning, and that's perfe…

That's not git flow, that's just release/maintenance branches.

The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master. There is no point of that at all. Look at the diagram, move all tags from master to develop, delete master and rename develop to master. There, you now have the workflow you've described without redundant branches.

Re: This is how I git

#60

Post by globular-toast »

etripe wrote: post #17
globular-toast wrote: post #12

Earlier quoted context omitted.

It's not git flow. Git flow is horrendous, completely unnecessary and designed by someone who doesn't understand git. The article describes a pretty standard git rebase workflow that is simple and works well.

IMO, git flow came about when people didn't want to or couldn't abandon the idea of trunks in TFS. I've heard its benefits explained as "more security for the business", while in practice it only leads to extra complications and accomplishes nothing a git tag couldn't.

Yeah, that matches my own analysis. I think it also comes from a time when people considered the source code to be an artifact and creating a source distribution was just checkout+zip. So you'd make a release commit with a version of the source code where the version is hard coded (the git flow page uses a "bump_version" script). Nowadays most projects can build an artifact (source or binary) from any version of the source code and derive their version number from git at build time.
Post reply on HN