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

291–300 of 435 posts

Re: Idiot Proof Git

#291

Post by MetaWhirledPeas »

qu4z-2 wrote: post #287
MetaWhirledPeas wrote: post #277

Earlier quoted context omitted.

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…

I definitely sympathise with the confusing and scary command names! "reset" is the worst in my opinion. Rebase is kind of the natural choice once you understand the data model, but it doesn't necessarily make it more approachable. `git rebase main` will modify your currently checked out branch to make the commits on that branch now branch off of the current value of main. It won't update main or modify it in any othe…

Thanks, that's useful information!

Re: Idiot Proof Git

#292

Post by throwaw20221107 »

Modern Git workflow is very simple on its own:

1. Your codebase has a `main` branch which is write-protected

2. Devs submit changes to `main` from their own branches using PRs

3. Devs can do whatever the fuck they want on their own branch

4. PRs are merged one at a time

5. When merge happens a dev's PR is squashed into one commit that gets appended to `main`

6. If next dev wants to merge their PR with a conflicting change they have to resolve the conflict first and then they merge

7. The end result is that `main` is a linear history of all PRs with the time they were committed to the `main` branch i.e., when they could've started to break prod.

This is a solved problem and it works great in industry. Why break it? If you want interactive rebase then make 2 PRs.

Re: Idiot Proof Git

#293

Post by squeaky-clean »

agentwiggles wrote: post #41

I guess this will come off kinda... douchey? But I just don't find Git to be that hard. I know there's a lot of complexity there, but I find that 95% of the time I'm just git add -p or git add . and then committing. Every once in a while I'll do a rebase, and that's the most complex part of Git that I use with any frequency. I remember when I first was introduced to Git I found it confusing, so I'm sympathetic to new…

95% of hit usage is fairly easy, yeah. But that other 5% can be extremely difficult.

Re: Idiot Proof Git

#294

Post by tremon »

krinchan wrote: post #183
dec0dedab0de wrote: post #78

Earlier quoted context omitted.

When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy. Yes,…

git add .; and git commit --amend --no-edit; git push origin --force Rarely, I have to do pipeline work on repositories. You'd normally see twenty "Fix Jankins Issue" commits on the main branch because of some nonsense that only happens when you deploy UAT or whatever. Once I learned this little gem, this is also how I manage my feature branches mostly. But also my employer's fleet of laptops has been aging and I've…

git add .

We have had multiple security incidents because some developer left a credential file inside the local git clone (no, not all tooling supports out-of-tree stored credentials). Blind 'git add .' is the first thing I teach my developers not to do.

Re: Idiot Proof Git

#295

Post by seba_dos1 »

opsy_ wrote: post #182
seba_dos1 wrote: post #126

Earlier quoted context omitted.

> and even if you want to get back to them right away it requires some delicate git surgery. `git reflog` to get the old commit ID, and then `git reset --hard `. Seems more like "basic everyday git operations" than "some delicate git surgery".

Many past confused teammates of mine I've dropped in to help would disagree. reflog and reset, for better or worse, require what seems to be above-average comfort with git.

I don't think you can call yourself "using git" if you're not comfortable with such simple concepts. Pointing a branch to a specified ref is one of the most basic operations you can reason about when using git!

I'm perfectly aware that many people don't think when using git at all and instead merely copy'n'paste memorized commands hoping that they'll do what they want to accomplish, but this is something you should move past when you want to stop calling yourself a "junior developer". This is one of the most important and helpful tools in your field of work, you can either take advantage of it or suffer.

Re: Idiot Proof Git

#296

Post by [deleted] »

throwaw20221107 wrote: post #292

Modern Git workflow is very simple on its own: 1. Your codebase has a `main` branch which is write-protected 2. Devs submit changes to `main` from their own branches using PRs 3. Devs can do whatever the fuck they want on their own branch 4. PRs are merged one at a time 5. When merge happens a dev's PR is squashed into one commit that gets appended to `main` 6. If next dev wants to merge their PR with a conflicting c…

[deleted]

Re: Idiot Proof Git

#297

Post by squeaky-clean »

RadiozRadioz wrote: post #134
ccity88 wrote: post #90

Earlier quoted context omitted.

I know HN will absolutely tear me apart for recommending this, but I use GitHub desktop. It has all the bells and whistles of the CLI, but you can actually see and understand what's going on. As a Junior Engineer, a Senior Engineer recommended it to me. I thought he was joking at first, but he kindly reminded me that using a GUI app is completely fine and okay. We shouldn't stigmatise tools that make it easier to use…

The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important. In my experience mentoring juniors new to git, those who are jus…

  git add . 
  git commit -m ""
Are like the first 2 got commands anyone tends to learn after git init or clone

Re: Idiot Proof Git

#298

Post by throwaw20221107 »

corytheboyd wrote: post #269

Aliases don't make git easier to understand, they make one specific git command require typing fewer characters to run. I am not against making aliases, but just saying, if you don't have an understanding of the commands they run, you'll still one day be in a state you don't know how to fix, and THAT is when people "lose their code" etc. You use git every day, it's worth learning and understanding. You don't need to…

The only reason people lose code is because

1. they didn't read this one diagram: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-...

2. And then they run `reset --hard`

Re: Idiot Proof Git

#299

Post by tremon »

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…

so reverting it is easier.

Only reverting the entire feature is easier. Reverting a single change (for example, because it introduced a bug but is not critical to the feature itself) becomes much harder after squash.

Re: Idiot Proof Git

#300

Post by throwaw20221107 »

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?

Ya, the three arguments are

1. `|`

2. `grep`

3. `"my actual filter"`

Post reply on HN