Thank you for sharing! It’s given me the inspiration to revisit my aliases. I avoided them for some time whilst working with devs who were new git, but there’s probably a happy medium that echos out the actual command being run, and maybe it even runs a ‘gst‘ afterwards.
I’ve always found consistent implementation of Co-authoring across our teams tricky, possibly due to remembering the format, and found that when we leant on tools such as GitHub desktop, we were better at keeping this up (it’s a couple of button clicks). Would you any have any tips to getting this working well and consistently with others?
At Zed we pair a lot and that's also when we add the Co-authored-by to the commits: when writing the code with someone else. I sometimes (rarely) forgot to add it, but mostly you don't forget it because someone else is on the call :)
Shell abbreviations are a very nice feature for having aliases which always show what's underneath. I use them in fish to expand git commands like `gap` to `git add --patch` or Docker compose commands. Also makes the history easier to read.
Fascinating, and downright uncanny. I can share it with others and say "This is 96% me."
I didn't have 'git lr', but I do now.
I actually use Conventional Commits. I spent a total of 5 minutes bike-shedding "chore". I didn't use "chore" before, because I don't get it, but I care more about consistency than being right. So with my current colleague, I use "chore" as he does.
Another big difference is: I used `git worktree` extensively in my previous job. I don't now. I used it extensively in my old job, since I maintained multiple long-lived contexts, and got distracted a lot. I don't do that recently, so it's probably a work culture thing.
I've attached my Atuin frequency table for git-specific commands:
That's awesome! Thanks for sharing your approach. How do you resolve merge conflicts when you have them? I found that lazygit did a pretty good job for me when I needed to resolve a conflict.
Just using my `gst` (git status) alias and going through the file. I manually delete the `<<<<` markers, tbh. Sometimes I use the GitHub UI to look at a file on another branch while doing this.
I either manually remove them, or use the VSCode plugin GitLens which lets me pick ours/theirs on each conflict rather than each file. Maybe a —progressive CLI tool would be useful here, but in some cases you just need to get dirty with the final version being a mixture between the two.
Nice! Thanks for the article!
I do my commits like this:
`$ c feat: your commit message`
c being my bash function which looks like this:
`c() { git add --all; git commit -m "$*"; }`
This let's me stage and commit without having to put the message in quotes.
Don't mean to hog the light here as it's your article so feel free to remove my link, but if you're interested this is the list of my git alises/functions I use: https://gist.github.com/matzar/3a8e8b4d28429d62420689a894583247
Thank you for sharing! It’s given me the inspiration to revisit my aliases. I avoided them for some time whilst working with devs who were new git, but there’s probably a happy medium that echos out the actual command being run, and maybe it even runs a ‘gst‘ afterwards.
I’ve always found consistent implementation of Co-authoring across our teams tricky, possibly due to remembering the format, and found that when we leant on tools such as GitHub desktop, we were better at keeping this up (it’s a couple of button clicks). Would you any have any tips to getting this working well and consistently with others?
At Zed we pair a lot and that's also when we add the Co-authored-by to the commits: when writing the code with someone else. I sometimes (rarely) forgot to add it, but mostly you don't forget it because someone else is on the call :)
Shell abbreviations are a very nice feature for having aliases which always show what's underneath. I use them in fish to expand git commands like `gap` to `git add --patch` or Docker compose commands. Also makes the history easier to read.
Have you considered git worktrees for working with multiple branches?
Yeah, I tried it at some point, but it seemed cumbersome in 99% of cases, only to make edge cases easier. My branches are *very* short-lived.
> Something about it being not in your editor makes you spot more bugs and left-over print statements.
That's so true. I also always read my own changes in the browser, before I hand it over for review... weird
Which git commit would you choose if you were to merge your peers work to yours (not to main branch)?
Fascinating, and downright uncanny. I can share it with others and say "This is 96% me."
I didn't have 'git lr', but I do now.
I actually use Conventional Commits. I spent a total of 5 minutes bike-shedding "chore". I didn't use "chore" before, because I don't get it, but I care more about consistency than being right. So with my current colleague, I use "chore" as he does.
Another big difference is: I used `git worktree` extensively in my previous job. I don't now. I used it extensively in my old job, since I maintained multiple long-lived contexts, and got distracted a lot. I don't do that recently, so it's probably a work culture thing.
I've attached my Atuin frequency table for git-specific commands:
```
gs # git status
gap # git add -p
gl # git log
gc # git commit (with -m, -v or --amend)
ga # git add
gdc # git diff --cached
gd # git diff
gp # git push (sometimes with --force-with-lease)
gco # git checkout
gpr # git pull --rebase --prune
git restore
git config
git rebase
```
my favorites:
`alias aaa="git add . && git commit --amend --no-edit --no-verify && git push -f"`
`alias sss='git stash && git checkout main && git pull && `git branch | grep -v "main" | xargs git branch -D` ; pnpm install'`
:D
That's awesome! Thanks for sharing your approach. How do you resolve merge conflicts when you have them? I found that lazygit did a pretty good job for me when I needed to resolve a conflict.
Just using my `gst` (git status) alias and going through the file. I manually delete the `<<<<` markers, tbh. Sometimes I use the GitHub UI to look at a file on another branch while doing this.
You could also do
`git checkout --ours .` to accept all the current changes
and
`git checkout --theirs . ` to accept all incoming changes.
I either manually remove them, or use the VSCode plugin GitLens which lets me pick ours/theirs on each conflict rather than each file. Maybe a —progressive CLI tool would be useful here, but in some cases you just need to get dirty with the final version being a mixture between the two.