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

121–130 of 140 posts

Re: This is how I git

#121

Post by wayneftw »

wildfire wrote: post #95
koonsolo wrote: post #41

Earlier quoted context omitted.

I'm an old school developer, but really hate the complexity and syntax of git. Therefore, I use the GUI that comes with Visual Studio Code and the "Git Graph" plugin. I work with juniors, which for some reason always want to do things in the command line. A lot of times I have to help them out with git issues, and can always to that using the GUI. When I see them work in the command line, it's always so slow for them…

Odd. I have had precisely the opposite. Junior Devs using the GUI ( in VSCode ) but breaking things badly. And then I have to help them out using the command-line

Where I work all the juniors try to use the git cli because the Internet has them thinking that using a GUI is looked down upon, but they don't even bother to learn the cli very deeply so they fail, break things and make messes.

One guy kept having to comb through dozens of local branches that had since been deleted from GitLab because he never pruned any of them. Fortunately, this is the most common type of breakage or mess - one that only affects the developer locally, because we protect the master branch on our server and use pull requests.

In VS Code I only have to know `Ctrl+Shift+P` to use their git "GUI" (if you can even call it that). One thing I like about it that you don't get with the cli (out of the box) is an instant overview of all the available commands without having to type much or switch views.

The juniors where I work have also been brainwashed to use Macs which they struggle with; mostly due to the bad window management, non-discoverable features and their lack of will to spend any time learning their tools deeply or customizing them. Meanwhile, I've been using Linux since the start of my career in the late 90s, I learned the basic Git flow over 10 years ago and have almost never had to use the git cli in that entire time while churning out hundreds of project.

Re: This is how I git

#122

Post by dragonwriter »

wayneftw wrote: post #121
wildfire wrote: post #95

Earlier quoted context omitted.

Odd. I have had precisely the opposite. Junior Devs using the GUI ( in VSCode ) but breaking things badly. And then I have to help them out using the command-line

Where I work all the juniors try to use the git cli because the Internet has them thinking that using a GUI is looked down upon, but they don't even bother to learn the cli very deeply so they fail, break things and make messes. One guy kept having to comb through dozens of local branches that had since been deleted from GitLab because he never pruned any of them. Fortunately, this is the most common type of breakage…

> In VS Code I only have to know `Ctrl+Shift+P` to use their git "GUI"

You don't even need to know that; the operations are available through a fairly straightforward, reasonably discoverable GUI, without using the command palette, which has a nice heiriachical structure.

OTOH, neither of those paths is much good if you don't already understand the semantics of git operations.

Re: This is how I git

#123

Post by barumi »

NateEag wrote: post #75
modderation wrote: post #34

Earlier quoted context omitted.

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…

The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides: https://www.endoflineblog.com/oneflow-a-git-branching-model-... If you can tell me something GitFlow buys you which OneFlow doesn't, I'd be very intrigued.

> The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

I see no relevant difference between that workflow and GitFlow, besides the rebranding of old concepts and some unexplained focus on merging options.

I've also revisited the author's old rant from 2015 regarding gitflow and the only tangible criticism he had was the separation of the master/mainline and development branches, which is extremely shortsighted and miopic as it fails to acknowledge the reality of non-CICD/old-fashined software release lifecycles.

GitFlow has one main concept: using feature branches to do develop work, use release-specific branches to integrate changes, establish and enforce upstream/downstream relationships between branches. The rest is just rebranding and nit-picking over semantics.

Re: This is how I git

#124

Post by karmakaze »

hibbelig wrote: post #86
brmgb wrote: post #16

Earlier quoted context omitted.

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

I use stashes via the autostash feature. For unspeakable reasons, I have to have locally modified files in my repo to run the software and the tests. (Of course, it shouldn't be like this.) So I can `git pull --rebase --autostash` and this works even with local modifications.

TIL, thanks! I've been stash; rebase; pop'ing

Re: This is how I git

#125

Post by barumi »

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

Earlier quoted context omitted.

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.

> 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 repository and into the Delivery/Deployment phase of a CICD pipeline. Yet, the overall principle is the same, and arguably its still here. Calling those differences "redundant and for no reason" is just ignorant at multiple levels, from software engineering to the fact that the sofware lifecycle process for commercial software projects, the kind that had to "go gold", had very specific requirements.

Re: This is how I git

#126

Post by karmakaze »

Possibly controversial, I like to add a "Change(s) from PR review" commit to the original set of changes of a PR then force push (with lease) amendments to that commit. That way regardless of when a reviewer last read the PR they can see changes since the original. If the changes get significant, I make a new PR and reference the old closed one.

Re: This is how I git

#127

Post by MaulingMonkey »

theamk wrote: post #88
MaulingMonkey wrote: post #48

Earlier quoted context omitted.

> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch…

stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach. I find the power of the stash in "stash pop", which applies, and drops if there were no conflicts: git stash push git checkout -b newbranch upstream/right git stash pop and yeah, if your keep your branches long-term stash is not a good solution for this.

A lot of my "short term" things end up being multi-month distractions or worse - and the verify/list/drop cycle is reflexive paranoia after one too many botched merges lost data.

Sometimes those botched mergeds have been due to my own incompetence, sometimes due to P4Merge literally corrupting my file and saving out something totally different than what I'd resolved, and sometimes due to unexpected refactoring between branches causing enough of a mess that reapplying the work by hand is easier than "resolving" the conflict.

Re: This is how I git

#128

Post by nonninz »

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.

Try git add -uip

Re: This is how I git

#129

Post by yarcob »

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 problem with rebase is that you must resolve conflicts for every commit. This can take a lot of effort versus a single merge at the end.

You end up doing a lot of conflict resolution when rebasing, increasing the chances that you make an error.

And if you do make an error during conflict resolution, there will be no record of it because you've rewritten history.

We stopped most rebases for this reason, and just do normal merges. Conflict resolution is easier, and if we do make a mistake, it's at least documented in the history, and it's easier to fix.

Re: This is how I git

#130

Post by rurban »

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…

The rational explanation is that branches are much easier to work with. You can rebase and merge branches with your standard workflow, but stashes can only be popped in order. Branches can be reordered and changed at will. As beginner I started with some stashes, but never needed them since. You already got tons of tools for branches, but none for stashes. Stashes are like submodules for me, quirky.
Post reply on HN