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

131–140 of 140 posts

Re: This is how I git

#131

Post by tele_ski »

ufo wrote: post #105
tele_ski wrote: post #93

Earlier quoted context omitted.

I always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?

Do you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.

"Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.

Re: This is how I git

#132

Post by globular-toast »

barumi wrote: post #125
globular-toast wrote: post #59

Earlier quoted context omitted.

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.

> The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master. This statement is simply wrong and ignorant. The reason why mainline and develop branches exist is due to the fact that production-ready code and unstable code are not the same ops-wise. Nowadays, with the dissemination of CICD practices, that difference has been shifted away from the source code…

You don't have to look hard at the git flow diagram to see the redundancy. It's plain as day. Of course I'm talking about today. Why would I be talking about 20 years ago? We have continuous integration and automated build pipelines so there's no reason to have your build artifacts living in the git repository. git is for source code. There are other solutions better suited to storing artifacts.

Re: This is how I git

#133

Post by ufo »

tele_ski wrote: post #131
ufo wrote: post #105

Earlier quoted context omitted.

Do you know can I enforce that a PR must be up to date with master before it can be merged? I don't remember seeing that option in the branch protection settings.

"Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.

Thanks! Turns out that this setting is hidden unless you first check the "Require status checks" option.

Re: This is how I git

#134

Post by tele_ski »

ufo wrote: post #133
tele_ski wrote: post #131

Earlier quoted context omitted.

"Require branches to be up to date before merging" is a check box under branch protection rules, I always turn it it. It's under the required status checks section.

Thanks! Turns out that this setting is hidden unless you first check the "Require status checks" option.

Oh good to know! I forgot it's hidden until that section is enabled. Does feel like a feature that should be top level, OSIT!

Re: This is how I git

#135

Post by ricardobeat »

gwenzek wrote: post #56
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.

True, it's one of the downsides. You have to also be in the 'short-lived branches' camp for it to work well - which you should!

Re: This is how I git

#136

Post by not_kurt_godel »

mklein994 wrote: post #69
gwenzek wrote: post #56

Earlier quoted context omitted.

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

Enter git rerere: https://git-scm.com/docs/git-rerere This will "REuse REcorded REsolutions" of conflicted merges. Once enabled, it will record how a merge conflict was resolved, and replay it back the next time it encounters it. Saves a lot of time in cases where you already solved the merge once before. https://git-scm.com/book/en/v2/Git-Tools-Rerere

rerere gives me nightmares. Much prefer some delicate merging footwork if at all possible.

Re: This is how I git

#137

Post by Cogito »

barumi wrote: post #74
Cogito wrote: post #54

Earlier quoted context omitted.

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 don…

> I don't know what you think git-flow is, but a linear history it is not. Your statement makes no sense at all. Gitflow is a workflow. What do you believe it's supposed to be? It's irrelevant how you see commit histories, because with regards to the master/mainline branch it's always linear, isn't it? What do you personally believe gitflow is? > Quoting the original git-flow post: I don't know what you expected to s…

Sorry for the late response, meant to reply hours ago!

I guess that first sentence should have been "I don't know what you think git-flow is, but it does not produce a linear history" or soemthing like that.

The history is very much not linear in git-flow, and for good reason - but it makes things more complicated and most people don't need it.

If, as you can find examples in other parts of thread, you use rebase-and-merge with git-flow you end up with something very similar to the methodology used in the article, but it is still different.

One of the main downsides to the featured method is that it's not clear which commits "go together" from the git history - you have to look at the pull requests in github. With git-flow, or rebase-and-merge, you always have a merge commit that lets you distinguish between commits that are 'releases' and commits that are part of a series.

So that is the key difference - the structure of the git log.

Re: This is how I git

#138

Post by GuB-42 »

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…

Maybe that's because I came from Mercurial but I dislike rebase workflows. You can rebase as long as it is in your repository and you didn't publish anything, you are free to do whatever you want on your PC. But as soon as it becomes public, it is history, and you don't change history.

Git is decentralized, and works kind of like a blockchain. With Bitcoin, the foundation is that everyone share the same history, no one should be able to rewrite transactions. I expect the same behavior from decentralized version control systems.

And if you make a mess, too bad, it is here to stay. It is ugly, but it is what really happened.

If it really is a huge mess, call the admin so that he can fix the thing, notify everyone that the history has changed, and have your name added to the hall of shame.

But that's a personal opinion. I know some people prefer a clean (but fake) history over a messy (but true) history. Continuous integration tools tend to like clean histories for instance. You can even have both system coexist. A messy/true history branch where developers work and a whitewashed version running in parallel for integrators.

Re: This is how I git

#139

Post by [deleted] »

smokey_circles wrote: post #3

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…

[deleted]

Re: This is how I git

#140

Post by Accacin »

dreamcompiler wrote: post #114
hibbelig wrote: post #92

Earlier quoted context omitted.

As soon as two people work on the same branch, rebasing becomes a problem. As long as you're the only one modifying the branch, rebasing works nicely.

I don't like rebase in solo code either; I want my personal history to be the truth, not some convenient fiction. In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled.

Where I work we always rebase on branches for features/bug fixes/tickets/whatever, but when we merge into master we always do `git merge --no-ff origin/branch`. We don't really care what the history of our branches are generally, and we preserve our commit history when we go into master.

We never squash when we go into master either.

Post reply on HN