Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

301–310 of 435 posts

Re: Idiot Proof Git

#301

Post by seba_dos1 »

pierrebai wrote: post #247
Jenk wrote: post #166

Earlier quoted context omitted.

I'm advocating that merge commits in main make it easier precisely for the requirements you specify: To track what feature(s) was introduced at a given release. With merge commits you not only have groupings of commits for features developed, you have that ability to revert a whole feature with just one revert. If you rebase onto main you are flattening those groupings and the entire commit stack into one serial hist…

Squash commit will squash everything done into a single commit, so reverting it is easier . Also when you have to cherry-pick fixes into an older release branch, you get to fully appreciate squashed merges. If you did not squash, you need to cherry-pick all commits from the merge. If the feature branch was not rebased and the dev merged main into the feature branch multiple times, then the branch commits are inter-mi…

> Squash commit will squash everything done into a single commit, so reverting it is easier.

No, it's just as easy, while needlessly throwing away other useful information.

> If you did not squash, you need to cherry-pick all commits from the merge.

...or use a single `git rebase` invocation.

> If the feature branch was not rebased

Linear workflows with merge commits usually require feature branches to be rebased on merge (just like squashes, just without the actual squashing), so that's not a problem at all.

Re: Idiot Proof Git

#302

Post by blep_ »

MetaWhirledPeas wrote: post #277
OkayPhysicist wrote: post #213

Earlier quoted context omitted.

Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all you…

This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And…

There's also `git pull --rebase`, which is just "pull like normal, then rebase onto the thing I just pulled".

Remember that it's okay to screw around and break stuff! Sometimes that's the best way to learn. Git's whole thing is tracking history, even the history of the history itself[0]. It is hard to accidentally lose something if you've committed it at least once.

If you're nervous, push your branch somewhere before starting (it's not strictly necessary, but it's the easiest way to get peace of mind).

Nothing you do locally will be pushed back to the remote unless you explicitly do `git push`. If you manage to screw up your branches so badly you don't know how to recover, you can just delete the local branch you broke and re-pull the remote one like it's a new branch, even if it's main/master.

[0] https://ohshitgit.com/, especially the first thing there

Re: Idiot Proof Git

#303

Post by seba_dos1 »

cnity wrote: post #161
daneel_w wrote: post #16

I'm incredibly thankful that 99% of my Git usage at work gets away with just PULL, CHECKOUT [-b], COMMIT [--amend] and PUSH. Rarely do I need to rebase, for any reason.

I mentally categorise `commit --amend` right there next to rebase personally. When people debate about rebasing and rewrite of history, I include `--amend`. Maybe I'm unique there though.

--amend is conceptually nothing else than interactive rebase to squash the last two commits together.

Re: Idiot Proof Git

#304

Post by expazl »

teo_zero wrote: post #286

Git's interface is like the 'find' UNIX command: it makes complex things possible, but does nothing to make common ones easy. 99% of times I want to find a file in the current directory or below: find . -name foo -print Can you spot the 3 obvious arguments that find shouldn't require me to type? Similarly, if so many users add -a to their git commands, why is this relegated to such an ugly flag?

Genuine question. What makes you feel that -a is an ugly flag?

Re: Idiot Proof Git

#305

Post by mixmastamyk »

__blockcipher__ wrote: post #240
andrewvc wrote: post #31

Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…

> Since moving to this workflow I’ve had zero issues losing data due to a confusing git situation. Nobody who understands git will ever lose data, because once committed you can never lose it (it's in the reflog). Indeed, even just adding a file means you will never lose it, although it's not as convenient as having an actual commit. So yeah, you kind of revealed the anti-rebase case quite tellingly there. It's for p…

> A big one being that it's not actually stored in git, so if you ever migrate from github to gitlab or some other system, that context is gone.

Request is committed to the repo on acceptance. Closed are typically useless.

> What's your fear of rebasing if you're going to do the equivalent...

The system takes care of the details without incidental complexity or errors.

> This is a very confusing and nonsensical ideology.

Pretty simple, folks are trying to get shit done. Not screw around with tools. One or two clicks where someone else did the hard work correctly wins every time.

From today, design is important:

- https://www.ncsc.gov.uk/blog-post/so-long-thanks-for-all-the...

- https://news.ycombinator.com/item?id=33531560

Re: Idiot Proof Git

#306

Post by [deleted] »

__blockcipher__ wrote: post #242
andrewvc wrote: post #143

Earlier quoted context omitted.

I think you misunderstood my post, if you squash merge as I suggested your main branch is linear as with a rebase. Your PRs and the the working branches behind them should just use merged however. Come merge time the diff is turned into a single commit

If you squash into a single commit upon merge, ignoring for the moment the fact that as a blanket rule that's a bad pattern, you've now eliminated one of the core arguments against rebasing. The merge commit adds no value if the branch itself is a single commit. Just rebase your squashed-into-one-commit branch ontop of latest master and push that to master instead. Now you have one commit representing your whole PR,…

[deleted]

Re: Idiot Proof Git

#307

Post by mixmastamyk »

__blockcipher__ wrote: post #242
andrewvc wrote: post #143

Earlier quoted context omitted.

I think you misunderstood my post, if you squash merge as I suggested your main branch is linear as with a rebase. Your PRs and the the working branches behind them should just use merged however. Come merge time the diff is turned into a single commit

If you squash into a single commit upon merge, ignoring for the moment the fact that as a blanket rule that's a bad pattern, you've now eliminated one of the core arguments against rebasing. The merge commit adds no value if the branch itself is a single commit. Just rebase your squashed-into-one-commit branch ontop of latest master and push that to master instead. Now you have one commit representing your whole PR,…

Seems you don't understand merge commits, they are nothing special.

Just don't: https://news.ycombinator.com/item?id=33518496

Re: Idiot Proof Git

#308

Post by mixmastamyk »

andrewvc wrote: post #145
dogleash wrote: post #88

Earlier quoted context omitted.

Your perspective is one I've only recently come to understand after migrating a team to git and being the "source control guy." The lesson I learned was: Prescribe everything about the workflow because nobody is going to learn git. All the nice flexibility of git just becomes risk. By the time you have enough structure in place, you're back where you started: rigid source control, and you're using git locally on the…

For what it’s worth I know git fairly well and have used more git strategies than most. I just happen to have found that simple usage actually works better for me personally and most teams I’ve been on. Knowing a tool also means knowing what not to use:

Like an acceptable subset of C++.

Re: Idiot Proof Git

#309

Post by copperx »

smaudet wrote: post #77
dec0dedab0de wrote: post #36

Earlier quoted context omitted.

The log should track the product's evolution, not the developers' activities. Git is a development tool, not a product release tool. If you want to see the product evolution you could filter to just merge commits, or just merge commits in a specific format. If you want to keep track of releases specifically, then use tags, that's what they're for. I suppose you could make a separate branch/repo where every commit = a…

Actually you're both wrong, its a change tool, not a development or a product release tool. "then use tags, that's what they're for" No they're not - that's definitely a useful way of using them, but they are just labels. Why is it useful to know this? Well, when you know your tool better (how it operates, not the porcelain or CLI), you have better insights and are able to use it better. You can manage Agile-style "f…

> Actually you're both wrong, its a change tool, not a development or a product release tool.

It's funny that HN can't agree on what Git is.

Re: Idiot Proof Git

#310

Post by copperx »

jfk13 wrote: post #83
agentwiggles wrote: post #68

Earlier quoted context omitted.

I won't disagree with that, but idk. Once you understand the basic operations everything weird is a Google away. I'll admit that Git is the only VCS I've spent any time with, so maybe I just don't know how much better it could be. But I've almost never had an issue with Git where I actually lost code. And anytime I'm doing something dangerous, I just make a backup copy of the directory in case I screw up irrevocably.…

> almost never ... actually lost code That seems like one of the absolute basics. "Almost" never...? > I just make a backup copy of the directory in case I screw up irrevocably If you really felt you could trust your source control system, that shouldn't be needed, and... > the cases where I've need to use my backup copy ...should be nonexistent.

I agree. If losing code with Git is even a remote possibility, then you're "holding it wrong" indeed.
Post reply on HN