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

91–100 of 140 posts

Re: This is how I git

#91

Post by freehunter »

lastofthemojito wrote: post #87

> Ordinary days, I issue git commands several hundred times. I wonder if this is an exaggeration, or if the author truly has that git-heavy of a workload? Assuming you're working an 8-hour day, that's 480 minutes. If you're issuing "several hundred" git commands, I'd take that to mean a minimum of 300. So that's a git command every 96 seconds. When do you have the time to write the actual software in between all of t…

Could be some back to back commands:

git add .

git commit -m “update”

git push

Although if you’re doing it that often I’d want to set up .bashrc to condense it to a single command.

Re: This is how I git

#92

Post by hibbelig »

dreamcompiler wrote: post #67

I find stashes quite useful and intuitive. For me, rebasing is the root of all evil.

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.

Re: This is how I git

#93

Post by tele_ski »

ufo wrote: post #66
jgraham wrote: post #51

Earlier quoted context omitted.

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually be…

Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.

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?

Re: This is how I git

#94

Post by bitjson »

ricardobeat wrote: post #42
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.

If anyone is interested, there's a tiny utility I've used daily for years to do this: https://github.com/bitjson/wip

Each time you run `wip`, all current work is committed. When you run the squashing utility `naenae` (autocomplete: `nae + Tab`), the most recent line of "WIP" commits is saved to a `wip-archives/[branch]/[timestamp]` branch for safe keeping, the commits are all squashed in place, and you're left in your default git editor to define the commit message. It also handles unusual situations, like using `wip` for the first commit (in which case, `git reset HEAD^` will return an error).

Being able to set a sort of "WIP checkpoint" in the current working directory makes it really easy to start or back out of big changes, and it can be very useful to check back in past WIP commits to grab segments of code you previously threw away.

Re: This is how I git

#95

Post by wildfire »

koonsolo wrote: post #41
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…

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

Re: This is how I git

#96

Post by grovellogic »

I really like the idea deleting feature branches after they are merged, but I rather would have a recycle bin or trash can concept where the branch is deleted after ~7-30 days in case I make a mistake and delete the wrong branch. Searching for a SHA to recover a branch is never fun.

Re: This is how I git

#97

Post by jgilias »

Just to add a datapoint. This[0] is what Linus has to say about rebasing and merging, and these[1] are the kernel development guidelines, when it comes to using git.

Of course, not every project is the kernel and to each their own, but I find it's useful to know how git is used in the project for which it was originally made.

[0] https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

[1] https://www.kernel.org/doc/html/latest/maintainer/rebasing-a...

Re: This is how I git

#98

Post by koonsolo »

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

Maybe you have a point. I can imagine when things are failing, they start clicking all kinds of things.

My juniors get stuck on the command line and then contact me :).

So maybe it is indeed better that they use their limited knowledge of the command line ;).

Re: This is how I git

#99

Post by obelos »

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.

Same for me. I only ever use stash in cases where I don't materially care if I never see the content again, as with an experimental approach.

Re: This is how I git

#100

Post by divbzero »

ufo wrote: post #66
jgraham wrote: post #51

Earlier quoted context omitted.

If you have tooling to support it, rebase-and-ff-merge is perhaps an even better workflow. In this model every commit on the main branch has a first parent that's the previous merge, and a second parent that's a linear set of the commits that were landed together, with the parent of the first commit being the previous state of master. This has the following advantages: * It's clear which states master has actually be…

Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.

You can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired.

[1]: https://docs.github.com/en/free-pro-team@latest/github/admin...

[2]: https://docs.github.com/en/free-pro-team@latest/github/admin...

Post reply on HN