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

11–20 of 140 posts

Re: This is how I git

#11

Post by sigjuice »

barumi wrote: post #7
globular-toast wrote: post #2

Seems pretty standard to me. Anything notable here?

> Seems pretty standard to me. Anything notable here? I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time. https://nvie.com/posts/a-successful-git-branching-model/ The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a ration…

I gave up on git stash because over time I would end up with too many stashes that I couldn't keep straight in my head. Now I just make temporary branches and cherry pick from them as needed.

Re: This is how I git

#12

Post by globular-toast »

barumi wrote: post #7
globular-toast wrote: post #2

Seems pretty standard to me. Anything notable here?

> Seems pretty standard to me. Anything notable here? I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time. https://nvie.com/posts/a-successful-git-branching-model/ The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a ration…

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.

Re: This is how I git

#13

Post by nickcw »

I use almost exactly this workflow with rclone.

This bit resonated particularly:

begin quote

Never merge with GitHub!

There’s a button GitHub that says “rebase and merge” that could theoretically be used for merging pull requests. I never use that (and if I could, I’d disable/hide it). The reasons are simply:

I don’t feel that I have the proper control of the commit message(s)

I can’t select to squash a subset of the commits, only all or nothing

I often want to cleanup the author parts too before push, which the UI doesn’t allow

end quote

Not being able to selectively squash and edit the multiple commit messages is a big missing feature in my workflow.

Re: This is how I git

#14

Post by teekert »

Looks like my flow. One thing I do wonder, how do people deal with the tests and the time it takes for a PR to be approved (including tests, discussion, people in different time zones)?

I often have interdependent branches (large pieces of related work chopped into small tasks) and take my previous branch along in my new one, this leads to an order in PRs sometimes when a big tasks is followed by a small/fast one. Sometimes I think, come on team, pick up my PR!

Re: This is how I git

#16

Post by brmgb »

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…

I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model.

Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual with Git, this leaks into the way it is used: if you ever lose a stash by mistake, you will have to go fish the corresponding commit in the reflog.

Re: This is how I git

#17

Post by etripe »

globular-toast wrote: post #12
barumi wrote: post #7

Earlier quoted context omitted.

> Seems pretty standard to me. Anything notable here? I agree, it's pretty vanilla git usage. I was curious to see any insightful take of whimsical twist, but it boils down to a basic take of good old git flow, which is git 101 for a long time. https://nvie.com/posts/a-successful-git-branching-model/ The only surprising thing in the article was the refusal to use git stash, which can't really be explained on a ration…

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.

Re: This is how I git

#19

Post by joombaga »

teekert wrote: post #14

Looks like my flow. One thing I do wonder, how do people deal with the tests and the time it takes for a PR to be approved (including tests, discussion, people in different time zones)? I often have interdependent branches (large pieces of related work chopped into small tasks) and take my previous branch along in my new one, this leads to an order in PRs sometimes when a big tasks is followed by a small/fast one. So…

My PRs sometimes get queued up like that too. Right now I'm waiting to merge an OS upgrade behind a single python package upgrade. I try to anticipate it in sprint planning and do reviews while I'm waiting for reviews.

Re: This is how I git

#20

Post by formerly_proven »

> 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 does, which leads to incorrect and confused mental models and much more frustration down the line than just learning to do it the git way directly. Yes, git is a "my way or the high way" tool, that's not great or something to emulate, but it is what it is. Trying to work around that only results in more pain.

Only use the git command line, use gitk for browsing history graphically if need be, and git-gui for preparing commits. git-gui seems to be the best GUI for making commits (and is probably written in Perl with Tk).

Logical conclusion from "only use the git command line": Also never make a dirty merge from your web browser.

Post reply on HN