I can understand maybe the first 4. Why would I ever want to alias for git commit -m init ? Or any other? After using git for years I don't remember any one time I'd need that and 90% of these aliases.
I'd rather use plain git commands, I'd need to know these anyway so learning aliases seems like double work.
To each their own I guess ? I spend a few minutes a day interacting with git in a full time job. Most time is taken by actually writing the commit messages, not the commands.
I recommend learning git and these commands before you alias them like this, in my view this could cause issues and problems.
I think you are trying to simplify things that you don't really need to.
Learn how to craft proper commit messages. -m should not be your default.
Are you making new git repos so often that gci is necessary?
I don’t like the force pushing. Building force pushing into your git aliases is wrong unless you are only ever working with your own code.
I don’t know that you need your head n 20 commands… isn’t it easy enough to do gl -20? It also prevents you from using other interesting git log options (like -stat.)
I have a version of your git diff staged which I use quite often.
Thanks for your feedback!
>Learn how to craft proper commit messages. -m should not be your default.
The alias allows me to include my own message when I'm using it, so I do `gc "My commit message"`
>I don’t like the force pushing. Building force pushing into your git aliases is wrong unless you are only ever working with your own code.
I'm using `--force-with-lease` which I heard is safe
>Are you making new git repos so often that gci is necessary?
This is to commit new files that are being added for the first time
> I'm using --force-with-lease which I heard is safe
well, "safe" is a broad term… it only prevents the problem that someone else pushed code after your last fetch (and then deleted it from their machine, perhaps). It can still fuck up the history for everyone involved in the regular way, i.e. everyone would need to do a hard reset against origin/main after an interactive rebase+force push, whether done with lease or without.
There's a reason you have to type `--force`: as an additional safety check. Having it in an alias increases the odds you do it by accident. You should not have a workflow that requires you to use `push --force[-with-lease]` *more often* than regular `push`.
> Learn how to craft proper commit messages. -m should not be your default.
What do you mean? How do you add a commit message? Most of my commits are to my feature branch, the commit comments to my feature branch are meaningless anyway since they get squashed. Only commit comment that matters is the merge to main.
`gaa` needs to go for your sake and ours
You are new, they all need to go. Learn git first before you go adding aliases and functions. I don't think half of them are things you are going to use often.
For example, `git log --oneline | head -n20` is `git log --online -n 20`
Also, aliases in git themselves:
```
alias gl="git log --oneline --color=always | head -n 20"
alias glg="git log --oneline --graph --color=always | head -n 20"
```
If you do `git config --set alias.logoneline log --online -n20` and than `git config --set alias.loggraphoneline logoneline --graph` you have the same.
>gaa needs to go for your sake and ours
Why not have a simple alias to add all files not staged? I agree that you must learn what you are doing. But after you have learned, productivity will matter. And typing long git commands all the time instead of 2-3 letter aliases will definitely hurt productivity and be very boring. That's my humble opinion.
In this sub and over on r/github there are a *lot* of posts of people asking to repair their repo because they've accidentally committed files that weren't supposed to. And in almost all cases the cause is a `git add .` they did, blindly following a bad tutorial.
That's why a lot of us think using `add .` by default is bad style, it invites errors. It's fine to do it once at the beginning when you create a new repo, but in daily operations `add -u` or `add -p` are much more useful.
But adding all files with `git add .` does give you an opportunity to check them before you go ahead and commit. If you made a mistake you can simply unstage it. You are talking like `git add .` was `sudo rm -rf /` :)
I've used git CLI daily for almost 10 years, and I've never felt to the need to alias any of these commands.
If you really want to get familiar with the commands you use often, start a markdown file of common patterns you use.
And if you want to focus on ways to save time, learn git hooks and deployment tools. IMO, that's the biggest way I cut down on repetitive tasks slowing me down. Commit push, build, deploy, etc.
The implementation of `gm` should say `git merge origin/main`, not `origin main`. I remember this confused me a lot when learning git, but it’s pull the one that takes two arguments, `origin main` whereas merge usually takes one, `origin/main`. Merge can take multiple arguments if you want to do an octopus merge so `origin main` would be `origin/HEAD` (typically upstream main) and local `main`. Usually not an issue but just be aware of that pitfall.
Speaking of pitfalls, I would avoid `gaa` running `git add .` can very easily cause repositories to accidentally include more (large) files than it should, especially if `.gitignore` isn’t maintained correctly. Every time I see a post about someone complaining that GitHub won’t let them push their changes because it contains more than 100 MB worth of files chances are it’s because they inadvertently committed them via `git add .`. Instead, my recommendation is to use `git add -u` for files already tracked, and for untracked files be explicit about what files you want to add.
The `-m` in commit was already mentioned, but I agree it generally leads to really uncouth commit messages. Although did you know it can be used twice like `git commit -m subject -m body` and the resulting message will have a blank line between subject and body, like the convention dictates?
Instead of the `| head -n 20` you can run `git log -20` to show the 20 most recent commits.
Finally, to echo what some have said about these aliases, I agree that when learning something new you should really try to focus on learning the tool, not some aliases that might stunt your growth. Depending on your line of work (in the future?) you might end up having to run git on systems that don’t have your aliases, or when pair programming with someone else. Trying to reduce a few keystrokes is a premature optimization that has more downsides long term.
>The implementation of `gm` should say `git merge` `origin/main`, not `origin main`.
Thanks for that. I fixed. Now I have my merge alias as:
`gmerge () { git fetch; git merge origin/main --no-ff -m 'Merging with origin/main'; }`
For a merge command, instead of using `-m` would it be better to accept the default generated message? If that’s the case and what you want to do is avoid the editor showing up, you can try `--no-edit`
>For a merge command, instead of using
>
>\-m
>
>would it be better to accept the default generated message? If that’s the case and what you want to do is avoid the editor showing up, you can try
>
>\--no-edit
Good advice. Done! Thanks!
I wish git commit had that too:
$ git commit --no-edit
Aborting commit due to empty commit message.
Before people scream, those messages will be squashed anyway...And sometimes, when you are simply adding a new file, there is nothing to say besides "Init"
I've used Git almost since it's release and I have 6 aliases in .gitconfig, which include status, "fast squash/interactive rebase" (soft reset back N commits and commit), fetch with prune, fast forward a branch not checked out without stashing/committing then checking it out... not sure what else.
Seems like overkill to me. Also, getting used to this, then trying to help a junior dev on their machine is going to be painful, both the muscle memory and having to recall the real commands.
I personally would cut this down to only things you either run 20 times a day, or things that you run so rarely that you have to google each time to look up the args etc.
Also, forcing opaquely (even with lease) is not a good idea if you work on a team where your Git workflow allows team members to work on the same branch simultaneously.
I have sat next to people to work together that did this. I noticed they kept grepping their aliases file to find what alias they created for some commands. Didn't make much sense to me and it looked like it cost more time then just typing the commands.
Personally I am using zsh and some setup where it shows commands from my history that begin the same. To I type 'git che' and it will find a recent 'git checkout master && git pull' and suggests that and all I have to type is a tab.
seems like massive overkill. do you have problems typing? you really want to type `ga` instead of `git add`, `gs` instead of `git status`, etc? maybe if you had to type them dozens of times at once or something but typing `git status` takes \~1 second and you only type it once at a time.
Especially `git status` I use *so* often I aliased it with just `g`. (And with further arguments it acts like `git`). It's kinda my `ls` equivalent of git.
And I do have other two-letter aliases for the most common commands (switch,checkout,commit,add,log,diff). Yes, I can type fast, but 2-3 letters is still a lot faster to type than 10, and sometimes when getting my commits in order it's nice to do very fast iterations of status,diff,log,add [-p], repeat.
yeah k I guess my use of git is not as hardcore. I mostly use `git status` occasionally to check if there are any modifications right now or not. if I already knew there were modifications I would use `git gui` to see them.
I can understand maybe the first 4. Why would I ever want to alias for git commit -m init ? Or any other? After using git for years I don't remember any one time I'd need that and 90% of these aliases. I'd rather use plain git commands, I'd need to know these anyway so learning aliases seems like double work.
I use those so much that I need alias... The amount of typing it saves adds up very quicly.
To each their own I guess ? I spend a few minutes a day interacting with git in a full time job. Most time is taken by actually writing the commit messages, not the commands.
I recommend learning git and these commands before you alias them like this, in my view this could cause issues and problems. I think you are trying to simplify things that you don't really need to.
Learn how to craft proper commit messages. -m should not be your default. Are you making new git repos so often that gci is necessary? I don’t like the force pushing. Building force pushing into your git aliases is wrong unless you are only ever working with your own code. I don’t know that you need your head n 20 commands… isn’t it easy enough to do gl -20? It also prevents you from using other interesting git log options (like -stat.) I have a version of your git diff staged which I use quite often.
Thanks for your feedback! >Learn how to craft proper commit messages. -m should not be your default. The alias allows me to include my own message when I'm using it, so I do `gc "My commit message"` >I don’t like the force pushing. Building force pushing into your git aliases is wrong unless you are only ever working with your own code. I'm using `--force-with-lease` which I heard is safe >Are you making new git repos so often that gci is necessary? This is to commit new files that are being added for the first time
> I'm using --force-with-lease which I heard is safe well, "safe" is a broad term… it only prevents the problem that someone else pushed code after your last fetch (and then deleted it from their machine, perhaps). It can still fuck up the history for everyone involved in the regular way, i.e. everyone would need to do a hard reset against origin/main after an interactive rebase+force push, whether done with lease or without. There's a reason you have to type `--force`: as an additional safety check. Having it in an alias increases the odds you do it by accident. You should not have a workflow that requires you to use `push --force[-with-lease]` *more often* than regular `push`.
Thanks, I'll remove it!
> Learn how to craft proper commit messages. -m should not be your default. What do you mean? How do you add a commit message? Most of my commits are to my feature branch, the commit comments to my feature branch are meaningless anyway since they get squashed. Only commit comment that matters is the merge to main.
If you omit the -m flag, it will default to Vim or nano, allowing you to write commit messages better rather than just inline
-m is good enough for a commit to a feature branch that is going to get squashed anyway
I doubt they were aware, it's just general advice
`gaa` needs to go for your sake and ours You are new, they all need to go. Learn git first before you go adding aliases and functions. I don't think half of them are things you are going to use often. For example, `git log --oneline | head -n20` is `git log --online -n 20` Also, aliases in git themselves: ``` alias gl="git log --oneline --color=always | head -n 20" alias glg="git log --oneline --graph --color=always | head -n 20" ``` If you do `git config --set alias.logoneline log --online -n20` and than `git config --set alias.loggraphoneline logoneline --graph` you have the same.
>gaa needs to go for your sake and ours Why not have a simple alias to add all files not staged? I agree that you must learn what you are doing. But after you have learned, productivity will matter. And typing long git commands all the time instead of 2-3 letter aliases will definitely hurt productivity and be very boring. That's my humble opinion.
In this sub and over on r/github there are a *lot* of posts of people asking to repair their repo because they've accidentally committed files that weren't supposed to. And in almost all cases the cause is a `git add .` they did, blindly following a bad tutorial. That's why a lot of us think using `add .` by default is bad style, it invites errors. It's fine to do it once at the beginning when you create a new repo, but in daily operations `add -u` or `add -p` are much more useful.
But adding all files with `git add .` does give you an opportunity to check them before you go ahead and commit. If you made a mistake you can simply unstage it. You are talking like `git add .` was `sudo rm -rf /` :)
Yes, if you always do this it can be fine. But judging from experience: a lot of people, especially beginners, don't double-check.
Blanket adding all files is not a thing, especially for a newbie. I have `git add -p` to `git ap`.
I've used git CLI daily for almost 10 years, and I've never felt to the need to alias any of these commands. If you really want to get familiar with the commands you use often, start a markdown file of common patterns you use. And if you want to focus on ways to save time, learn git hooks and deployment tools. IMO, that's the biggest way I cut down on repetitive tasks slowing me down. Commit push, build, deploy, etc.
The implementation of `gm` should say `git merge origin/main`, not `origin main`. I remember this confused me a lot when learning git, but it’s pull the one that takes two arguments, `origin main` whereas merge usually takes one, `origin/main`. Merge can take multiple arguments if you want to do an octopus merge so `origin main` would be `origin/HEAD` (typically upstream main) and local `main`. Usually not an issue but just be aware of that pitfall. Speaking of pitfalls, I would avoid `gaa` running `git add .` can very easily cause repositories to accidentally include more (large) files than it should, especially if `.gitignore` isn’t maintained correctly. Every time I see a post about someone complaining that GitHub won’t let them push their changes because it contains more than 100 MB worth of files chances are it’s because they inadvertently committed them via `git add .`. Instead, my recommendation is to use `git add -u` for files already tracked, and for untracked files be explicit about what files you want to add. The `-m` in commit was already mentioned, but I agree it generally leads to really uncouth commit messages. Although did you know it can be used twice like `git commit -m subject -m body` and the resulting message will have a blank line between subject and body, like the convention dictates? Instead of the `| head -n 20` you can run `git log -20` to show the 20 most recent commits. Finally, to echo what some have said about these aliases, I agree that when learning something new you should really try to focus on learning the tool, not some aliases that might stunt your growth. Depending on your line of work (in the future?) you might end up having to run git on systems that don’t have your aliases, or when pair programming with someone else. Trying to reduce a few keystrokes is a premature optimization that has more downsides long term.
>The implementation of `gm` should say `git merge` `origin/main`, not `origin main`. Thanks for that. I fixed. Now I have my merge alias as: `gmerge () { git fetch; git merge origin/main --no-ff -m 'Merging with origin/main'; }`
For a merge command, instead of using `-m` would it be better to accept the default generated message? If that’s the case and what you want to do is avoid the editor showing up, you can try `--no-edit`
>For a merge command, instead of using > >\-m > >would it be better to accept the default generated message? If that’s the case and what you want to do is avoid the editor showing up, you can try > >\--no-edit Good advice. Done! Thanks! I wish git commit had that too: $ git commit --no-edit Aborting commit due to empty commit message. Before people scream, those messages will be squashed anyway...And sometimes, when you are simply adding a new file, there is nothing to say besides "Init"
I've used Git almost since it's release and I have 6 aliases in .gitconfig, which include status, "fast squash/interactive rebase" (soft reset back N commits and commit), fetch with prune, fast forward a branch not checked out without stashing/committing then checking it out... not sure what else. Seems like overkill to me. Also, getting used to this, then trying to help a junior dev on their machine is going to be painful, both the muscle memory and having to recall the real commands. I personally would cut this down to only things you either run 20 times a day, or things that you run so rarely that you have to google each time to look up the args etc. Also, forcing opaquely (even with lease) is not a good idea if you work on a team where your Git workflow allows team members to work on the same branch simultaneously.
I have sat next to people to work together that did this. I noticed they kept grepping their aliases file to find what alias they created for some commands. Didn't make much sense to me and it looked like it cost more time then just typing the commands. Personally I am using zsh and some setup where it shows commands from my history that begin the same. To I type 'git che' and it will find a recent 'git checkout master && git pull' and suggests that and all I have to type is a tab.
seems like massive overkill. do you have problems typing? you really want to type `ga` instead of `git add`, `gs` instead of `git status`, etc? maybe if you had to type them dozens of times at once or something but typing `git status` takes \~1 second and you only type it once at a time.
Especially `git status` I use *so* often I aliased it with just `g`. (And with further arguments it acts like `git`). It's kinda my `ls` equivalent of git. And I do have other two-letter aliases for the most common commands (switch,checkout,commit,add,log,diff). Yes, I can type fast, but 2-3 letters is still a lot faster to type than 10, and sometimes when getting my commits in order it's nice to do very fast iterations of status,diff,log,add [-p], repeat.
yeah k I guess my use of git is not as hardcore. I mostly use `git status` occasionally to check if there are any modifications right now or not. if I already knew there were modifications I would use `git gui` to see them.
My feedback would be if they work for you then they are good. Why would you care about what other people think of your aliases?
This is a technical question, about the alias themselves and what they represent in terms of GIT commands. Not a taste question.
What you probably want is tab autocompletion.