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

41–50 of 140 posts

Re: This is how I git

#41

Post by koonsolo »

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…

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 to type in things.

Want to switch branches? Click lower left and select your branch. Want to sync with server? Click lower left on the sync icon Want to commit? Just type your commit message and CTRL-Enter. Stop wasting time adding files on the command line. Want to prune your origin branches? Click on the Git menu and prune pull.

For this last one, I always need to look up the syntax when doing it on the command line.

Git is already complex enough (compared to SVN), so if you're junior, for god sake use the GUI menu!

Re: This is how I git

#42

Post by ricardobeat »

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…

    git add .
    git commit -m "wip"
when you're back

    git reset HEAD^
Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes.

Also, god help you when a stash fails to apply.

Re: This is how I git

#43

Post by ricardobeat »

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 easier than via merging too.

Re: This is how I git

#44

Post by barumi »

Cogito wrote: post #9
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, 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, and it's a concise overview of how the maintainer of curl does their job.

It's gitflow, and leaving out feature branch commits doesn't make a difference.

Re: This is how I git

#46

Post by helloguillecl »

BerislavLopac wrote: post #39
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/

I just did a week ago! And I still find Sourcetree's interface a lot clearer and cleaner for this specific purpose.

Re: This is how I git

#47

Post by helloguillecl »

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.

For example I might be working on a specific feature and discover that my dev environment is missing something (For example replacing node by nodemon). I will make the change on the build script but I will not commit before testing the process for a couple of days, and certainly not before finishing the feature/bug I'm working on.

Re: This is how I git

#48

Post by MaulingMonkey »

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…

> 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 2. I've made no commits 3. The right branch has changes to files I've modified

    git stash push
    git checkout -b newbranch upstream/right
    git stash apply
    ...verify...
    git stash list
    git stash drop [id]
Careful and safe, but not actually much faster than my old workflow, and I haven't the foggiest idea how to fix things up with stash if I've made several commits, if that's even a thing.

    git checkout -b dead/wrong
    git add -A .
    git commit -m "WIP"
    git checkout -b newbranch
    git rebase --onto upstream/right upstream/wrong
    ...verify...
    # optional
    # git branch -D dead/wrong
    # git reset --soft HEAD~1
Depending on if you count the optional commands, that's one more or one less command. "Those aren't optional!" you might say - but yes, they are. I'll often merely amend my WIP commit into a real one instead of resetting. I'll often keep dead branches long term - perhaps some of my work relied on things that haven't landed on upstream/right yet, and can't be brought over sanely until upstream/wrong lands on upstream/right, or just for peace of mind that I might've forgotten something. Good dead branch names makes this less painful than... numbered stashes? Eww, gross.

Re: This is how I git

#49

Post by zikzak »

gtsteve wrote: post #23
yarcob wrote: post #8

Earlier quoted context omitted.

The problem with stash is that its easy to create a mess. Yes, it's useful to quickly stash your work, switch to a different branch, do some quick fix, then go back to your original branch. But in practice, what often happens is that your quick fix takes way longer than expected, and you don't immediately go back to your original branch. Then you pull in some changes, maybe someone else pushed something to the branch…

I personally only use stashes when I've given up on my current approach and want to reset but I might change my mind later (rarely happens). I don't think they're appropriate for stuff you want to keep across branches, there's no real visibility and they'd be easily forgotten.

I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I realize this isn't a best practice for config files but it is what I need to do for my particular mountain of technical debt. This works particularly well since the config files rarely change in a permanent way. I will only do it short term, though. For me, Stash is a tool I use sparingly as a convenience.

Re: This is how I git

#50

Post by greggman3 »

only related by "git" but while I believe i'm fairly proficient in git I'm not sure how to go about explaining to an inexperienced person how to fix a merge conflict.

It feels like not a simple thing to explain.

As an example someone sent me a PR with 15 commits. github claims only 1 file has changed and it's a new file so no conflicts (which AFAIK is correct) but git complains that somewhere around commit 4 there's a conflict.

The person sending the PR is not git comfortable, otherwise they wouldn't have this PR with 14 old unrelated commits showing up.

I have no idea what state they are currently in as well. meaning, I know the state of the PR but I don't know the state of their local machine.

I can clone their branch and make the merge myself but their next PR will just be the same branch they continue to work on.

Explaining to them how to fix what they have and how to proceed going forward seems like it requires a very large reply. Several pages. (here's how to fix this PR, this how to fix the state of your main/master branch, here's how to make different branches, here's how to update after each PR, here's what to do if the conflicts are real, here's what to do if you haven't made any more changes to your main branch., here's what to do if you have already made changes to your main branch.

I have no suggestions for solutions except to try to point them to other articles/pages/tutorials on the web

Post reply on HN