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

31–40 of 140 posts

Re: This is how I git

#31

Post by kingosticks »

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…

The author does explain their alternative to stash (a temporary commit in the new branch that will eventually be cleaned up / removed during 'rebase -i' before pushing) and why that fits with the way they work.

Why is stash better than this? Because it avoids the rebase? Many people do this anyway, early commit messages often need rewording. Because it maintains the separate state of the current working directory and the index? Is that it? I don't think that's really a compelling enough reason to claim the author's avoidance of stash is the wrong way to work.

Re: This is how I git

#32

Post by DJHenk »

helloguillecl wrote: post #26
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…

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lines) to stage for commit, which is in my opinion much easier than with the CLI only.

> selecting which changes (hunks, files or selected lines) to stage for commit

I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.

Re: This is how I git

#33

Post by nemetroid »

DJHenk wrote: post #32
helloguillecl wrote: post #26

Earlier quoted context omitted.

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lines) to stage for commit, which is in my opinion much easier than with the CLI only.

> selecting which changes (hunks, files or selected lines) to stage for commit I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.

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.

Re: This is how I git

#34

Post by modderation »

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.

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 perfectly fine. The repository layout should be dictated by the project's needs, be it a glorified personal Undo Log, or a management tool on top of a Subversion repository.

Re: This is how I git

#35

Post by cjfd »

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 dictate that you should have the smallest number of branches possible so everyone gets the latest code as soon as possible and conflicts get minimized. For unfinished features one can have feature flags. While there are cases where one needs a feature branch I think it is best to only make feature branches if they are necessary and most development does not need to be on a feature branch. The git flow also features a development branch besides the master branch. This also seems an unneeded complication for most projects. If you have specialized testers you probably do need release branches for every release that you make but then again if you don't have specialized testers you probably don't. Here is a good talk about the harmful nature of feature branches. https://www.youtube.com/watch?v=h7LeD7VevyI

Re: This is how I git

#36

Post by scrollaway »

nickcw wrote: post #13

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…

I use the rebase and merge button when the author has clean commits. Otherwise yeah.

Re: This is how I git

#37

Post by berbc »

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.

Re: This is how I git

#38

Post by DJHenk »

nemetroid wrote: post #33
DJHenk wrote: post #32

Earlier quoted context omitted.

> selecting which changes (hunks, files or selected lines) to stage for commit I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.

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 revert back to.

You know what, typing it out I can totally see why people do it the other way. A matter of personal preference probably.

Re: This is how I git

#39

Post by BerislavLopac »

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…

You should give GitKraken a chance: https://www.gitkraken.com/
Post reply on HN