The "reflog" in "git reflog" is short for "reference log". So, "ref-log" is a git command; "re-flog" is what your boss does to you when you once again miss your sprint deadline.
@mykalimba Hardly ever write comments but came here to point this out. Was going to say something along the lines of "bless you heart but mate, it's short hand for "reference log", lol @ re-flog." Then was like, no way someone else hasn't mentioned this, didn't even have to scroll to find the first occurence.
I think he went too fast over that prune branch command. What awk does there is: match all lines containing ": gone" and print first "word", meaning stuff until first space. Since this operates on lines (maybe you had 10 branches and 3 have that string ": gone"), it spits out 3 lines. We then need to use xargs which basically takes each line and runs command "git branch -d" followed by that line. So at the end he ran "git branch -d 21-25". Oneliners like these can be usefull without knowing how it works, but this is beauty of unix tools. You can combine them to do anything, since everything is basically files, lines of text and only your imagination is the limit.
All true. Worth noting that there's no need to pipe anything at all. You can simply use one command to do the same thing in many cases: git remote prune origin.
git reset doesn't actually delete commits when you reset to an old commit, because you still can reset to one of the later commits or cherry pick it. The way I see it is that the command just leaves the commits that you dropped dangling with no way to reach them unless you can refer to them through their SHA (short or full).
Instead of teaching people to stage all files in the directory, you should teach people to only stage and commit the changes they intend. That is done with `git add -p` and `git commit -v`. This is a good video about how *not* to use git.
Just commented a similar thing. Doing commit -a or add . and unknowingly pushing in sensitive files like .env or logs that might have plaintext secrets in them sounds like a great way to leak data and loose your job 👍 not everyone knows how to setup gitignore properly and relying on it would be very foolish
my tip is use :x (or ZZ) to quit vim in those revert (and many other) situations. saves you 2 (or 3) keystrokes over :q!, probably many times over throughout your day
Very informative video. The good thing I learnt today is how to make aliases, especially for `git add .` followed by `git commit -m "some message"`. So, I really like the trick of `git ac "some message"`. It will surely save my time. Thank you Kyle!
Great tips overall, word of caution though - using git add . or -A could very very easily end up with junk or sensitive files being included in your repository, especially if your gitignore files aren't up to date.
How have I gone all these years never knowing that git log has a content-search option? 😮 That is *so incredibly useful.* Same goes for bisect! Thank you for this video!
Great video! I'm pretty sure that even after a git reset --hard, the commits still exist in your local repository, they are just no longer pointed to by HEAD or master, but they could still be referenced (and resurrected) by their commit hashes. The reflog is a history of which hashes were pointed to by HEAD in the past, so you can use that to identify the hash that HEAD pointed to before the commit.
This is extremely useful stuff, I always find myself messing up using GIT because I never really took the time to learn the commands properly and simplify the commands.
git reset actually does not delete anything. it just forces the tip of your current branch to a specific ref, be it a branch, tag, or commit. if you remembered the commit hash your branch was at before using git reset --hard origin/main, you could just do a git reset to your old commit hash. this works until these unreferenced commits are deleted from the graph via garbage collection.
You can also `git reset --hard HASH` too if you need to reset your changes to a specific commit. I didn't know about `bisect` and that looks super helpful. Another great video Kyle!
Cool video. But you should really warn people about 'stash'. It's 1 stash per repository, not per stack. So if you are not careful, you delete your work. Personally i prefer commit any day, because it's safer.
Makes a video about git… proceeds to execute advanced shell commands. Also if you’re looking to really screw yourself, use git stash the way that’s presented in this video.
The git alias seems unnecessary when you can create aliases directly in your .rc file of choice and then persist then in a github repo to quickly pull onto any new machine. Just to make things even more trivial, if you are using something like oh-my-zsh, a lot of convenient git aliases are built in - you don't even need to write them yourself.
I think you need to mention that doing git add for all files is not always the best way to add files. Sometimes you are working on a complex feature and it is important to commit little and often.
git bisect only works on the top of the working tree... you can ONLY do it on main, not on branches. Or did I understand it wrong? This makes it basically useless to me, as when I push something on main, it's usually quite clean :( Quite disappointed
Great video! You should be able to use ctrl-L to clear the terminal (or cmd-k in macOS to clear and forget scrollback, not sure if that works in VS Code), instead of typing `clear`.
I came to this thinking I would know all of them all LMFAO..Search/bisect/prune I didn't even check for...I can't wait to explore bisect further it sounds like a game-changer for me..I wrote a very similar alias to delete all braches except main as well...I feel like I am more productive squashing my local feature branch commits into 1 commit before merging with main..this way I commit way more because I don't have to care about the commit messages until I am ready to merge..
git reset does not really delete commits, it deletes references. The commits themselves still exist until the repo is eventually (automatically) purged in a cleanup. If you mistakenly do a reset, you can still list or search the unreferenced commits
I used git bisect, it's really awesome. The one caveat I have is that it sometimes is a bit annoying because you may have uncommitted code that you need in order to test if the bug is present, and if that code is in a tracked file, then git bisect will tell you to stash it (which you don't want to do). The solution is then to add an untracked file that lets you test, so git bisect won't complain.
There are also ways to prune local branches that were committed into a given branch. We use this weekly on the code base I work on at my job so that the overall git repositories stay clean. The nice thing is that it won't get rid of non-merged local branches, so changes you're still working on that haven't been pushed to the remote stay in place allowing one to continue working in them.
Hey Kyle, you may want to amend the respective blog post. In section 2. Aliases you suggest adding the ac alias through the command: git config --global alias.ac "!git add -A && git commit -m" but double quotes won't make it. I came to the video to check which command you had run and you use single quotes. Just wanted to let you know as the blog posts do not take comments. Cheers man and keep up the awesome work!
Great video! the most important thing to remember is that everything is fixable, i see a lot of juniors get all stressed out over simple fixable mistakes so no worries :). Again, Awesome video!
Such helpful tips and a clean explanation! Will definitely use bisect for debugging in future👍🏻 Just loved it! How to come out of the bisect mode though?
tbh finding a bug by traveling through a commit history doesn't seems to be a good idea. If you need git for this rather then the code itself it means you are not quite understand what you are debugging. P.S. thanks for log -S
But then he isn't wrong because the alias thing is something you do not know and he said ALMOST nobody! So there is a chance that somebody knows this! :)
Every video Kyle makes, it's like he's sprinting through a marathon! So much useful information and detailed explanation crammed into a short amount of time.
A Great example of why software that is published has really nice features in one version that future versions don't have cause a new branch is created... While git is a good tool andIlove your video instructions, your quick paced diatribe on this video just sounds like double talk... This reverses the previous reverses, lol .
Bad advice in the first half (adding and committing everything at once) and not that exotic commands in the second. Next time less click bait and more research for actual commands that "almost nobody knows".
git stash is also handy when you made changes in the wrong branch :) stash; change branch; stash pop
Way more useful than the case he describes imo
What a nice video. I’m bit suprised you didn’t add rebase -interactive, by my opinion is one of the most amazing and underused git commands.
l think every body knows 'rebase' command. :)
rebase interactive is of great help
@@kyujong93 but did you try it with -interactive option? It is on another level!
@@Pilecek oh I'll try that option! thank you :)
I don't know rebase :(
The "reflog" in "git reflog" is short for "reference log". So, "ref-log" is a git command; "re-flog" is what your boss does to you when you once again miss your sprint deadline.
it depends, some bosses go with reflux
@mykalimba Hardly ever write comments but came here to point this out. Was going to say something along the lines of "bless you heart but mate, it's short hand for "reference log", lol @ re-flog." Then was like, no way someone else hasn't mentioned this, didn't even have to scroll to find the first occurence.
git cherry-pick is pretty good too
I think he went too fast over that prune branch command. What awk does there is: match all lines containing ": gone" and print first "word", meaning stuff until first space. Since this operates on lines (maybe you had 10 branches and 3 have that string ": gone"), it spits out 3 lines. We then need to use xargs which basically takes each line and runs command "git branch -d" followed by that line. So at the end he ran "git branch -d 21-25".
Oneliners like these can be usefull without knowing how it works, but this is beauty of unix tools. You can combine them to do anything, since everything is basically files, lines of text and only your imagination is the limit.
All true. Worth noting that there's no need to pipe anything at all. You can simply use one command to do the same thing in many cases: git remote prune origin.
For the git-revert example, you should've shown how to revert a merge commit as that is very commonly the usecase
honestly i haven't met most of the issue after i started to use gui version control, it is just so much better to look at visualize information
Which one are you using?
git reset doesn't actually delete commits when you reset to an old commit, because you still can reset to one of the later commits or cherry pick it. The way I see it is that the command just leaves the commits that you dropped dangling with no way to reach them unless you can refer to them through their SHA (short or full).
Instead of teaching people to stage all files in the directory, you should teach people to only stage and commit the changes they intend. That is done with `git add -p` and `git commit -v`.
This is a good video about how *not* to use git.
Just commented a similar thing. Doing commit -a or add . and unknowingly pushing in sensitive files like .env or logs that might have plaintext secrets in them sounds like a great way to leak data and loose your job 👍 not everyone knows how to setup gitignore properly and relying on it would be very foolish
my tip is use :x (or ZZ) to quit vim in those revert (and many other) situations. saves you 2 (or 3) keystrokes over :q!, probably many times over throughout your day
Very informative video. The good thing I learnt today is how to make aliases, especially for `git add .` followed by `git commit -m "some message"`. So, I really like the trick of `git ac "some message"`. It will surely save my time. Thank you Kyle!
Great tips overall, word of caution though - using git add . or -A could very very easily end up with junk or sensitive files being included in your repository, especially if your gitignore files aren't up to date.
You can also automate bisect which is great when in combination with regression tests
native is better
@@arshdeepkumar2586 Not having a bad commit is even better.
@@donnyroufs551 not having a repo is even better
or just using file system for code management
@@arshdeepkumar2586 You must be on crack
How have I gone all these years never knowing that git log has a content-search option? 😮 That is *so incredibly useful.* Same goes for bisect! Thank you for this video!
Great video! I'm pretty sure that even after a git reset --hard, the commits still exist in your local repository, they are just no longer pointed to by HEAD or master, but they could still be referenced (and resurrected) by their commit hashes. The reflog is a history of which hashes were pointed to by HEAD in the past, so you can use that to identify the hash that HEAD pointed to before the commit.
This is extremely useful stuff, I always find myself messing up using GIT because I never really took the time to learn the commands properly and simplify the commands.
git reset actually does not delete anything. it just forces the tip of your current branch to a specific ref, be it a branch, tag, or commit. if you remembered the commit hash your branch was at before using git reset --hard origin/main, you could just do a git reset to your old commit hash. this works until these unreferenced commits are deleted from the graph via garbage collection.
You can also `git reset --hard HASH` too if you need to reset your changes to a specific commit. I didn't know about `bisect` and that looks super helpful. Another great video Kyle!
Cool video.
But you should really warn people about 'stash'.
It's 1 stash per repository, not per stack.
So if you are not careful, you delete your work.
Personally i prefer commit any day, because it's safer.
Makes a video about git… proceeds to execute advanced shell commands.
Also if you’re looking to really screw yourself, use git stash the way that’s presented in this video.
I don't really think all of them are " must know ". git stash and git revert are " must know " ones. Rest, I highly doubt
Very informative and quick video.... Thanks bro 👍
Wow.. do you ever take a 1-second break in your ongoing speech ?! 😂😂😂😂
Absolutely amazing video. We want more of this please
"I've done it countless times" -- doesn't sound very inspiring when the teacher accidentally deletes his work without knowing how to get it back
The git alias seems unnecessary when you can create aliases directly in your .rc file of choice and then persist then in a github repo to quickly pull onto any new machine. Just to make things even more trivial, if you are using something like oh-my-zsh, a lot of convenient git aliases are built in - you don't even need to write them yourself.
Git add . Adds everything in the current directly and below, not the current directory.
its annoying that you type a command and smash enter split second later so you talk about great command that i need to put video to 0.5x speed to see
I think you need to mention that doing git add for all files is not always the best way to add files. Sometimes you are working on a complex feature and it is important to commit little and often.
That's easy to remember, what do you call cutting tree branches? Pruning
Watched the first 5 seconds. Answer is 149712.
If you like to do git in terminal my favorite is TIG! Cannot do a single commit without using tig now
git bisect sounds amazingly powerful
What about a completely new, in depth git tutorial remake, all in one.
WRT to aliases - couldn't you also use bash aliases for this?
You need to scroll up so what you are typing is not blocked by the video controls
Top 10 git pranks to do with your friends
Could you make a BASH video? 😃
Can you make the video on node blog which has authentication and many other features like other has and also deploy a node application on AWS
I already have a Node blog article and a separate user authentication Node video.
@@WebDevSimplified 👍👍👍
I learned so much. I love this. :)
You oughta do a short on rebase. Best thing ever.
Kyle = Google ai in physical form
Awesome video mate, thanks so much!
you dont need to separate -a and -m. -am works fine
First I want heart
It's even easier: >git commit -am 'message'
... that almost *nobody knew* 😉
Please do version 2 of this video!!
(ctrl + l) for clearing the terminal
git bisect only works on the top of the working tree... you can ONLY do it on main, not on branches. Or did I understand it wrong?
This makes it basically useless to me, as when I push something on main, it's usually quite clean :( Quite disappointed
Great video! You should be able to use ctrl-L to clear the terminal (or cmd-k in macOS to clear and forget scrollback, not sure if that works in VS Code), instead of typing `clear`.
On Windows command line, use double quote instead of single quote, otherwise parameters to git command will not work as expected.
I came to this thinking I would know all of them all LMFAO..Search/bisect/prune I didn't even check for...I can't wait to explore bisect further it sounds like a game-changer for me..I wrote a very similar alias to delete all braches except main as well...I feel like I am more productive squashing my local feature branch commits into 1 commit before merging with main..this way I commit way more because I don't have to care about the commit messages until I am ready to merge..
git reset does not really delete commits, it deletes references. The commits themselves still exist until the repo is eventually (automatically) purged in a cleanup.
If you mistakenly do a reset, you can still list or search the unreferenced commits
I used git bisect, it's really awesome. The one caveat I have is that it sometimes is a bit annoying because you may have uncommitted code that you need in order to test if the bug is present, and if that code is in a tracked file, then git bisect will tell you to stash it (which you don't want to do). The solution is then to add an untracked file that lets you test, so git bisect won't complain.
Helpful for sure - you should emphasize that some of this won't work on windows without awk or xargs.
Great video. Now that I'm working on a company, all this commands make more sense! Gonna create the git log --graph one!
There are also ways to prune local branches that were committed into a given branch. We use this weekly on the code base I work on at my job so that the overall git repositories stay clean. The nice thing is that it won't get rid of non-merged local branches, so changes you're still working on that haven't been pushed to the remote stay in place allowing one to continue working in them.
@kyle For deleting a branch we can use
git branch -D branchName
Great video rundown of the best git commands, thanks.
wow... bisect is sick.
+1 for bisect. Very useful, I'll be trying this out next time I break my code
Do you know if wildcards (*) behave like . or like -A when dealing with git add?
Probably the best git tutorial I've seen the past year. To the point. Thanks!
thank you, very useful! I should try debug with bisect
Hey Kyle, you may want to amend the respective blog post.
In section 2. Aliases you suggest adding the ac alias through the command:
git config --global alias.ac "!git add -A && git commit -m"
but double quotes won't make it. I came to the video to check which command you had run and you use single quotes. Just wanted to let you know as the blog posts do not take comments.
Cheers man and keep up the awesome work!
Thanks for the heads up. I will get that fixed.
omg.. so confusing
Great video! the most important thing to remember is that everything is fixable, i see a lot of juniors get all stressed out over simple fixable mistakes so no worries :). Again, Awesome video!
Thanks, awesome video, please more git tutorials for the future!
Lazygit Will handle all of this for you. Great video thought
You can replace 11:45 by 'git fetch -p', much simpler 😊
Basement Jaxx : "where's your head at ?"
WDS : "hold my git ."
Bisect. Never knew that one. Makes me want to write a bug just so I can use it.
Do you ever use a graphical git client? Fork is very good
Thank you!!
Hey Kyle, the aliases work only on the PC you set up or are associated with your GitHub account? Thanks!
Related to your pc, it is not shared
bruh! recently I read your article and now we have a video :O
i did! thanks for saving my life and my career!
Such helpful tips and a clean explanation! Will definitely use bisect for debugging in future👍🏻 Just loved it! How to come out of the bisect mode though?
git bisect reset
Superbbbb...... video like other videos 😍
Hi
Crazy useful content, thanks
Would be nice to see a video on working trees in git.
Thanks for knowledge brother 👍
Bisect and Reset!!! Thanks Kyle!
Very helpful, Kyle, thank you !
That bisect command is amazing 👌
Cool. Much needed video 🤓
Thanks. This is very interesting
Git dev simplified. 😁😁
First one may be
11:29 what's the difference of this and using git fetch --prune ?
both are same it just removes the remote branch from the .git subfolder
'git fetch -p origin' is a simpler way to remove branches from the local repository that were deleted in the remote repository.
18th
Next level ❤️❤️
tbh finding a bug by traveling through a commit history doesn't seems to be a good idea. If you need git for this rather then the code itself it means you are not quite understand what you are debugging.
P.S. thanks for log -S
Thanks.
you are wrong i knew all the commands except adding multiple git commands as alias
But then he isn't wrong because the alias thing is something you do not know and he said ALMOST nobody! So there is a chance that somebody knows this! :)
@@jodu adding multiple git commands as alias is still useless as you can run both the commands individually
@@ajjitsabat9786 No not really cause the config thing with the alias is also a git command...
@@jodu with great powers comes great responsibilites if you know what you are doing then go ahead :)
@@ajjitsabat9786 I think I know but you can also go ahead and again it's "Almost Nobody"
Every video Kyle makes, it's like he's sprinting through a marathon! So much useful information and detailed explanation crammed into a short amount of time.
A Great example of why software that is published has really nice features in one version that future versions don't have cause a new branch is created...
While git is a good tool andIlove your video instructions, your quick paced diatribe on this video just sounds like double talk...
This reverses the previous reverses, lol
.
Bad advice in the first half (adding and committing everything at once) and not that exotic commands in the second.
Next time less click bait and more research for actual commands that "almost nobody knows".