I went to the other extreme. I have a somewhat elaborate fish function which detects any use of -a and refuses to call Git with it.

I had gotten lazy about good commits, basically, `git commit -a` was in my muscle memory. Forcing myself to treat staging as a step before committing, and getting in the habit of using `git add -p` when called for, has made a meaningful difference in the quality of my commit history.

If one is disciplined about making changes in the first place, I suppose this matters less. But I'm not, and also don't want to be: if I spot something else which needs doing while I'm in flow mode, I'm not going to put it off just to keep commits nice, not when there are better options for doing that part.

My git status is `git s` aliased to `git status -sb`, don't need all the extra clutter.

I also have a few .zshrc aliases, like `gap` which is `git add -p` or `gam` which is `git commit --amend --no-edit`.

But also some typo fixing ones that I end up doing a lot, some because I type in half a command and get distracted / check something, then start over with a partially filled in command:

    alias gigit="git"
    alias gitgit="git"
    alias ggit="git"
    alias qgit="git"
    alias ght="git"
    alias got="git"
    alias cleear="clear"
    alias gits="git s"

    git = !git

    commmit = commit
    comit = commit

I have aliases like

  - `ls` for `ls-files`
  - `lo` for `git log --oneline`, then add a variety of letters in multiple combinations like
    - `r` for `--reverse`,
    - `s` for `--stat`,
    - `om` for `origin/master..`,
    - `1` for `-n1`, `2` for `-n2`, `3` for `-n3` (maybe up to 5),

  - `rbi` for `rebase -i`,
  - `rbiom` for `rebase -i origin/master`,
  - `rbc` for `rebase --continue`
  - `rba` for `rebase --abort`

  - `cp` for `cherry-pick`,
  - `cpa` for `cherry-pick --abort`,
  - `cpc` for `cherry-pick --continue`

Notice I don't have aliases for merging. I use strictly rebase and cherry-pick workflows.

I found these online and added them to my gitconfig at one point... I can't take credit for them. Integrating fzf with git makes working with branches even better (with fuzzy matches for checking out as well as deleting branches)...

cob = !BRANCH=`git recent --no-color | fzf` && git checkout ${BRANCH}

db = !BRANCH=`git branch --no-color | fzf` && git branch -d ${BRANCH}

dbf = !BRANCH=`git branch --no-color | fzf` && git branch -D ${BRANCH}

I so want to do this, but I am always scared that I will accidentally put in a wrong character and do something that will cause me hours of rework.

Sure question, why have it in zshrc and load it every time a new shell starts? It’s all in the .gitconfig after the first run anyways right?

It’s strange that git aliases can’t accept multiple git commands. It gives a strange divide between single command aliases which go in your git config and multi command aliases which go in a shell config. Shells vary and some don’t even have aliases (cmd is probably the most used shell of them all and it - almost - doesn’t have aliases at all).

Being able to define an && alias in .gitconfig would be great for being able to share snippets like these across shells and OS:es.

My most used alias is by far “git oops” for git commmit —all —-amend —-no-edit

you should add a dog for pretty logging

    git config --global alias.adog "log --all --decorate --oneline --graph"

Hello, author here :) It's actually not based on geolocation, I just directly look at navigator.language / navigator.browserLanguage: https://github.com/pcottle/learnGitBranching/blob/main/src/j...

If the browser says English, chances are pretty good that's because the user didn't configure it.

... that's the explanation I've heard, but I agree that it's obnoxious.

tig is a really nice tool for a very similar view https://jonas.github.io/tig/

Maybe explaining why would you ever want to have branches in your code? I'm a longtime git user and never felt a need for them.

Yeah that's the situation I keep running into.

Them: "I really want to be proficient in git." Me: "Here's the tutorial site that I used that helped me grasp concepts and be more adept." Them: "Cool thanks."

And of course they never put in the time or bother with the site ever again, repeat ad-nauseum.

For me, git is a prime example which shows that theoretical understanding of some problems is absolute beneficial. If you just keep in mind that it's (basically) just a directed graph, it makes the usage a lot easier.

I dunno - for me git doesn't really have branches. What it calls "branches" could more accurately be called version/commit pointers.

A "branch" traditionally in SCM was a sequence of versions/commits. In those SCMs, the "main" (or master) branch was an identifiable sequence of versions/commits.

There isn't a "main" branch in git, there's a current "main" version/commit. If your history is fully linear, a pointer to the "main" commit allows you, via parent following, to discern a "main" branch. But if you've been using merge, for example, there isn't a unique path from the current main commit to the root.

In theory one could amend the parent commit such that its timestamp is after its child commit. In practice I do occasionally edit one of the commits in my branch if a particular change fits better with that commit (most often typos).

As such pointing to the parent is more stable than pointing to when the parent.

Same here, tried clicking near the prompt, nothing. Maybe I'm bad at git, can't even perform a simple commit.

edit: right after typing this, I clicked the title of the MacOS styled window to the left and somehow it worked, even though clicking everywhere inside it didn't.

I had this issue, a page refresh helped

It's a really great resource to come back to for those of us who have been using git over over a decade, too!

https://onlywei.github.io/explain-git-with-d3/ is another one that I've used to demonstrate the repository state after various operations.

I always send this to new hires who don't know git. Pretty common in mechanical engineering

Don't git describe in anger, I heard you say.

Just to be clear, and you probably won't disagree with this, there's nothing wrong with commits like "temp" or "checkpoint" or "WIP" (Work In Progress). I often make these sorts of commits as I'm working on stuff.

The issue is in submitting an MR/PR with those commits. There's an expectation among professionals that you make your work presentable before submitting it for review, although those who are new to the profession don't realize that this cleanup step is necessary (how could they? the intro courses don't teach this and they're usually struggling enough with the code).

I just wanted to throw this comment in here in case some newbie sees this and comes away thinking "oh, I can't have 'temp' or 'checkpoint' in my commit messages"

Git rebase aka People rewriting history to make it LOOK like the commit was a compilable, working work result at a point in time even though the real history was something completely different, then f*cking up the rewriting of said history, then whining "please mighty Senior SWE heeeelp I don't know what happened please help my work is gone".

It all has trade-offs.I prefer seeing the dirty laundry.

It's a mindset problem; people use git commits as the equivalent of hitting save in their editor, and they feel like they should use it as a work log, justifying their time spent or feeling like they have to demonstrate how they got to a certain solution. It's not relevant. Ego is not important. You don't need to justify your time.

I agree with you in spirit (people need to learn their tools more) but your examples...not so much. Merging main into the feature branch was the original intent on how to do it. PRs are sent the way you describe because GitHub literally offers the maintainer a squash option and it's a lot easier to review a pull request when history is unedited.

It seems there are no best practices here. I remember senior devs working with a gui for git that didn’t have rebase in it. I worked on the cli, whenever I mentioned that I rebased people looked at me with raised eyebrows since I was not a senior and new.

> It just seems like a decent proxy for "do you care at all?"

Because the reality is, when it comes to Git history, no, I don't care in the slightest. I get all the information I need by:

- Reading previous PRs (the final diff)

- Checking the name on a git diff of a line

- The ticket reference

Git commits are a tool to help me write code and reverting to a "known-good" state. Once it's merged into master/main, I don't care how messy it is because 99.999999% of the time, I'll just go back to the merge commit.

> It really annoys me

Have you set those expectations with your team or the people you are working with? Your ‘style’ shouldn’t just show up in reviews

From my experience, nobody teaches you Git properly in school. And once you get your first job, it is too late.

We had various lectures on languages models, math, algorithms, networking... absolutely nothing on git (I did my classes between 2008 and 2013, things might have changed now)

same case here. almost new guy on my team we need to train them because basically just know to use what vs code exposes as git interface and some of them can replicate the same flow on terminal. rebase? that's a forbidden command for them, while our entire company use this as daily basis.

that just kinda sad. hopeless.

It's so frustrating. We had a reasonably okay process going on, but then another team started working in our repository on their feature completely ignoring the fairly lightweight commit message format we ask them to uphold, and they were like "doesn't matter, we'll squash merge it". But it's not even about the commit messages; it's about the workflow they have behind it, where they commit and push as often as they hit ctrl+s, which to me communicates they're just hacking around until it works.

A commit should be atomic; it should be a complete change with code and tests all adjusted, and ideally a message explaining what and why it changes. (In practice / in my line of work this doesn't happen because it's all front-end code implementing some poorly documented user story in jira, but hey).

If I'm ever involved in hiring again I'll add git usage to my list of criteria. Along with whether they can actually touch type. I can't believe that the standards have dropped so far that basic computer skills are no longer necessary apparently.

I share your frustration, personally. But unfortunately Git is more user-unfriendly than it needs to be, and doing things the proper way tends to get you into a rabbithole.

Like merging main back into your feature branch: just rebase. But then you often need to re-do conflict resolution. You have git-rerere but, eh, it’s not discoverable at all. But let’s say you get over that hurdle. Now the next obstacle is the “never rewrite shared history”. And if you’re in a “corporate” environment chances are that you publicize your branch when you make a PR. And it can take a few days to get approval.

Now I care. But sometimes I have doubts about whether the caring is well-founded. Exactly because sometimes people around me seem to care not one bit.