Good tip, do not use -force, this will make all your coworkers hate you, use -force-with-lease, this will only allow you to push the code if there are no conflicting changes with the current parent branch 👌
We block force on Main for all but a few admins in the rare case a build system breaks underneath us which requires code changes to fix. Everything else requires a PullRequest.
Important note: "git commit -a" will only automatically add changes to files git is already tracking. If you create a new file, you still need to "git add" it.
Yeah, I'm all in for old-school in this aspect. Adding files manually first and committing in a separate command. As stated in the video "sometimes going fast lead to mistakes"
I have an alias set up: gcad=“git add .; git commit -v” Occasionally I’ll end up staging stuff I don’t expect to, but using -v means I usually spot my mistake. VERY occasionally I end up committing something I didn’t mean to, but I’m confident enough with git to edit the commit before the PR gets merged, so for me the trade off is worth it.
alias uncommit="git reset HEAD~1" alias recommit="git commit --amend --no-edit" alias editcommit="git commit --amend" These are my all time favorite aliases
Instead of showing "--force" flag you should default to "--force-with-lease" which will avoid pushing the code if it would overwrite something you didn't anticipate (coworker's code)
The most useful git technique I've learned is understanding how it works internally (what is a commit and how it is stored, that a branch is pretty much a pointer to a commit etc). This allows for much more flexibility when it comes to managing your local repo. At work I'm constantly juggling commits between local branches, mixing and squashing them as I need them to. There is no problem in running cherry-pick on a branch to get its' top commit or pushing your previous commit to remote while current one is not ready. And also reflog.
@@BosonCollideris it an abstraction? To me it's a tool that makes it easier to copy code around and have messages and IDs attached to certain versions of it, instead of having separate folders for working on a new feature or so. There are some abstractions in the naming, yes, but even without all of them it's just a tool to avoid having tons of folders and a spreadsheet to know what's where.
git switch: move your current changes to another branch. I regularly work on the main branch and then switch those untracked changes to a new branch then I commit them. The perfect use case is when you just want to test something, but you're not sure it's worth it. > git switch -c''
So would you do. Work on main branch git checkout -b newbranch Then won't it automatically take you to new branch? Then have to go back to switch again? How does it work?
@@voyageruk2002 switch is a replacement for checkout. `git checkout -b` and `git switch -c` work the same. They created switch because checkout does more than just switching branches and now they are trying to make things more specific. To simplify the code base, I guess.
One operation that I use quite a lot is "git add -p", which basically allows me to review each piece of code I changed/added/deleted in order to have more granular control over what I want to include in the next commit, and maybe squash the changes I didn't include, for later.
I don't watch Fireship videos that often, but when I do they always blow my mind. Like, I need to watch them over & over to absorb all the things that are in them. Thank you so much for this, we developers need to master GIT for sure.
The quality on your videos is insane. The voiceover is amazingly clear and nice to listen to. The topics touched on are explained really well The graphics are on point.. Amazing stuff!!
This is heavily used when your code has tests and automated jobs. If you have Travis or Jenkins that run tests frequently, this feature allows to figure out which commit introduced a bug that it’s causing failures
You can also run it automatically by providing a script with exit vode 0 for success and non-zero exit code for failure and it will mark all your commits good or bad based on that automatically
My favourite one is "git add -p" to Interactively add blocks of codes, you can add and ignore them as you go through the changes in case you want to split the changes in multiple commits. A colleague showed it to me and it was 🤯
2:35 git revert does not "got back to the original state"; that's checkout / reset. git revert creates a new commit with the opposing changes effectively reverting the reverted commit (hence the name).
He said "without removing the original commit". How else would you "go back to the original state [...] without removing the original commit"? The only way is to create a new commit. So creating a new commit is implied here and you comment is superfluous.
Sometimes, especially when someone's commit might overwrite the changes you did, removed something, etc, etc, you might wanna do a git rebase on another branch. It helps to just make your branch on top of that one without any consequences. But we need to be careful with it, since it can really mess up everything.
@@Fireship I'm sorry for off-topic, don't know other way to contact... My top-level comment about the long list of Git GUIs seems to disappear, is it caught by youtube's spam filter, by any chance?
sample usage of git hooks: you can make it extract a Jira ticket number from branch name and prepend it to the commit message automatically, so that when you merge branches, you can track all tickets that were merged just by looking at the commit message of the merge
There's one more handy command.. To revert a PR merge and avoid reverting every commit, simply revert the merge commit by using git revert merge_commit_id -m 1 Here 1 means stay on the main branch and revert the merged branch changes
git cherrypick is also useful when we have to merge a specific commit im another branch to our Say main branch by directly referencing the needed commit and the new added commit is same as that commit in that branch from where it got picked but with a completely new commit id.
That bonus tip in the end blew my mind!! The others you come across whenever you Google issues you have with git. But that last one saves so much time especially on terminals that don't have autocomplete.
Nah, the master 'copy' (oxymoron) is on someone else's server (Github?). Git's called a distributed VCS for a reason. As long as you have the same hash, you have the same Mona Lisa! PS the correct historical term should have been a slave copy, based on slave clocks, but folks back then went with the 'master' figure of speech
Apparently, using the word master anywhere in your code or other tools is now considered as a reference to slavery. If you still have a branch in any of your repos called master, then congratulations you are racist. 😂 Welcome to the inclusive and diversified kingdom of Woketopia 😂😂😂
@@Kevin-jc1fx Most folks simply don't know where the usage comes from. There is a distinction between unique masterpieces created by master craftsmen (such as the Mona Lisa), or the original ship's drawing of Titanic, and forced perfect replication, originally conceived to drive slave clocks from a master pendulum. The original reference is discussed in [1] R. Eglash, “Broken Metaphor: The Master-Slave Analogy in Technical Literature,” Technology and Culture, vol. 48, no. 2, pp. 360-369, 2007, doi: 10.1353/tech.2007.0066 where the 'master' analogy was used directly to call up the idea of slave copies. Given that perfect replication/copying is the hallmark of software storage, it fits the latter description better than the former. Learning takes time.
@@philipoakley5498 I guess it does not matter, nobody should be force to use "main", master is fine so it make no sens to change it just because someone want to see his ideologie in it
I never used the interactive rebase to squash, but you can do it manually as well: Assuming last common commit in both master and your branch is f8324b, then: git rebase --onto master f8324b git reset --soft master git commit -m "Your squashed commit name" Works like a charm!
I personally avoid git commit -a or git add . because it will stage and commit all new and changed files and it's important to be selective about what you commit if you happen to be working on a few things at once or just want to separate commits into chunks of specific functionality (so you can revert only those chunks if needed).
@@sufiserious798The -p option let's you selectively add changes from a file instead of adding the entire file. Can sometimes be useful, i suggest you try it out yourself.
The most important thing for me was to learn how the git graph is built. Not the details but the structure of the commits in general. Close to all operations update that graph. Visualizing what these operations do was most helpful. I love git extensions.
if you cant remember the full name of a branch during checkout. put a letter then press tab, it will either autocomplete the branch name for you or it will lists all the branches starting with the prefix/letter you provided.
Great video. I never understood Git in depth until i started using GitKraken. Having an UI is so more convinient and u can learn the things a lot quicker. Give it a shot and you will never go back.
For me, it was exactly the other way around. I have a feeling that using a UI tool should be allowed only after you understand the git internals. But if you understand those, you won't bother yourself with using a UI tool - plain aliased commands are typically faster to type and execute, and bonus point - you are pretty sure what is going on. While with that that fancy tool you are left at the mercy of its authors.
I recommend against renaming the master branch in existing projects, it can break things. Then again, its best to have your branches be named stuff like "prod" for production and "dev" for development
Extremely well explained video and added new stuff I did not know. The master rename to main is the stupidest thing I have ever felt in person about this new vibe of racism and sexism. It is ridiculous.
No one is forcing you to do anything (hopefully anyway). However, when starting new projects, it really doesn't matter what you name your main branch, so why not go with the least controversial one?
@@ibrahimomer9263 Because at a certain point, you have to say STOP. Otherwise this bullshit will go on until we cannot communicate anymore w/o constant fear of hitting the next trap. In my country, Germany, the language is being completely demolished meanwhile... Think for a minute: Do you really believe the word 'master', especially in the absence of a 'slave' as here with git, did hurt a certain group of people so much, that they gathered together and started lobbying at microsoft, for their just case? So that microsoft bent, because the pressure from that group was so high, that they decided to skip the word master in github's default repo settings? If you believe that, I would like to know who those people were and how they started their campaign for their cause. Face it: That group does not exist. Nobody, not a single person, is *honestly* being insulted by git using the word master for its default branch. Just like not a single woman in Germany is insulted by the word Wissenschaftler (scientiest), which we may not use any more. You will HAVE to realize that this stuff is coming NOT from bottom up. It's coming top down, upon us. Then ask youself why, whats the reason. *Why* is this being pushed top down? Invest half a day - You'll find the answer easily.
This video feels like the first page of any StackOverFlow Git-related question's first page. I'm glad to be referring to this video instead of spoofing dust on the lost side of StackOverFlow.
I feel like these videos are someone watching how shit I am and prodding me with encouragement. like "here you go little monkey, use this hammer to open that coconut you have been hitting with your head for a few hours"
Oh, I was really wishing for what the bonus trick does, haha! Something that I do often when before opening a PR is doing ‘git reset -soft {destination-branch}’ so that my changes are not lost, and then reconstruct the commit history. This helps build a cleaner one. Then do ‘git push -f’ and that’s it. But, of course, be careful with the ‘-f’.
I know this is controversial, but I really like to use a UI for git. Personally I use Fork. It just gives you a nice graphical overview of the brances, stashes and currently staged files. Especially for beginners it's easier to wrap your head around everything with a UI.
I like the part where he just explains the core function. No hand holding, no long explanations. He at least expects the people watching this to be competent enough to figure stuff on their own. Subbed
Hey fireship, I think these tricks for terminal git commands are all cool, but I personally believe in the supremacy of GUI's for git. Originally I fell in-love with GitKraken, ended up getting the pro version, and since then I've converted my entire team to using it. While it does bar you off from some the optional commands / flags you can use in your terminal, I feel it includes all the most important git utilities (checking out, commiting/pushing, ammending, reverting, rebasing (also interactive-ly), merging, stashing, and even more) whilst also providing you with an extremely intuitive UI for a git repository's state. About half of the tips you showed in this video I believe can be handled more cleanly in a GUI, the useful ones that I like doing in GitKraken being bisect, interactive rebase, pretty logs and stashes. Just being able to see a project's entire history, who made each commit, the relationship of all branches to one another, are all extremely valuable features on their own.
I personally only think I really began understanding how git works properly after I started using the console version but that might just be me. I would also have a hard time working without the git-worktree command ¯\_(ツ)_/¯
Yes! Just wanted to second that. Also it has some nice features like adding hunks and partial stashes (for hunks and files). Even though that is possible with some CLI magic too in GitKraken it is way, way easier. For the SSH "I don't have an graphical environment at all" people I can also recommend lazygit, which is a pretty neat TUI for git.
git merge --no-ff performs a merge without fast-forwarding, so the graph still shows merged branches and their commits. This can be set in a global option. Another cool global option is autostash, so that git pull with stash, pull then apply the stash automatically.
@@henriquematias1986 Not fast forwarding is actually a terrible tip. There is nothing worst than a git log full of merge commits, makes it hideous and unreadable. It's a trunk based development anti pattern.
Great video! Even though I've worked with git for some time, there are some commands that I didn't know that would make my life easier, so thanks for that!
The best thing I did was start using a Git UI (e.g. in Webstorm) for git. I make far fewer mistakes and it helps a lot when doing complex rebase / conflict resolution. It's important to understand git fundamentals but why make it hard for yourself?
git cherry-pick is also my favorite to pick the commits(changes) from different branches to my current branch, sometimes helpful in testing new changes/features 🔥
`git reset -hard` doesn’t delete your changes forever. You can always get them back using `git reflog` and creating a new branch referencing the dangling commit that had your old changes. Just make sure you do it before it’s garbage collected
When creating a new branch and switching over to it traditionally you would use git branch new-branch git checkout new-branch This can be done with a single command git checkout -b new-branch
Idk, those Git CLI commands are only for masochistic guys. I mean, the VSCode Git plugin and GitHub/GitLab UI are there for a reason! They visualize the diffs properly, simplify staged commits, assist you at resolving merge conflicts, let you modify the squash message before merging the feature branch, show you which commit made the CI/CD break, etc. Why not use those tools instead? It saves lots of time if properly used :D And btw, great work @Fireship ;)
as a bonus tip on squashing commits - if you branched off of, let's say, master and made some commits on your feature branch, provided you keep master and feature up to date (rebased), you can do git reset --soft master to get your feature branch commits turned into the staged files and then proceed to create one commit out of all the changes.
Do not bend a knee to an ideology that tells you 2 + 2 = 5, men can get pregnant, and gender is a social construct. We have to push back against the woke insanity.
Another pointless woke thing then? *sigh* Have they not considered the minority of sexual submissives might prefer the term "Master"? Shame on them.. :-P
Thanks for the social warning. I will start naming all branches just 'branch' so that no one feels left out. I'll also start adding random ascii characters to binary files to make them more inclusive of other bits. It might be a small adjustment in the short term but ultimately worthwhile.
@@sodiboo Git does not have a "default" branch - the first created branch is the default. Github/-lab/Bitbucket added that functionality to their implementation.
@@flightvision Oh? really? I mean that does sound completely plausible, but how does git know which branch to actually pull if you clone with no extra parameters?
Fireship keeps git'ting better and better! P.S the way I thought git commit -am worked was like: you can only use it if the files you're trying to add were added before, with git add. If it's new files you're trying to add, you're gonna have to first use git add, and only then you're gonna be able to stage and commit with git commit -am. Of course, it's git, so there's a chance I got it all wrong.
That is correct, commit -am only stages & commits files that are already tracked. You'd have to track any new files with 'git add .' before running the commit command
@@CynicalOldDwarf Oh, thanks! I always distrust myself when it comes to git and always double check what I know. Although I was pretty sure about this one. Also, yeah, the proper way of saying that is: it only works with already tracked files. With untracked files you just use git add first since git commit won't work. Thanks!
The guy who created git seems really smart. He should create a kernel someday.
Am I a certificated geek to understand this joke? :D
Yeah, and he could call it something based on his name… something like Linuz or Linuks or something. 🤔
@@ThotsAndPrayers Lunix would be better.
People would find different reasons... One could say Lol Unix
😅
@@DevAmateur the guy is linus trovald and he created a kernel called linux
@@TOn-fx2gr lmao, I said that I understood the joke
Good tip, do not use -force, this will make all your coworkers hate you, use -force-with-lease, this will only allow you to push the code if there are no conflicting changes with the current parent branch 👌
If you don't want your coworkers to hate you, then you should just git-blame-someone-else so they'll have that someone else instead
I usually use `git push origin +feature/name`
it only push the current working branch which is usually we wants to force change
@@bugs389 pfwl
came here for this, sound advice that more people should know about
We block force on Main for all but a few admins in the rare case a build system breaks underneath us which requires code changes to fix. Everything else requires a PullRequest.
Important note: "git commit -a" will only automatically add changes to files git is already tracking. If you create a new file, you still need to "git add" it.
Thanks, I tried to be all smart and use this new -am and now I am surprised to see none of my new files on the online repo...
Usually I favor git add - - update
This allows you to only commit changed files added to the repo.
I can confirm this
Yeah, I'm all in for old-school in this aspect. Adding files manually first and committing in a separate command. As stated in the video "sometimes going fast lead to mistakes"
I have an alias set up:
gcad=“git add .; git commit -v”
Occasionally I’ll end up staging stuff I don’t expect to, but using -v means I usually spot my mistake.
VERY occasionally I end up committing something I didn’t mean to, but I’m confident enough with git to edit the commit before the PR gets merged, so for me the trade off is worth it.
Let's take a moment to appreciate how this guy drops amazing content every other day.
St. Fireship
💓
alias uncommit="git reset HEAD~1"
alias recommit="git commit --amend --no-edit"
alias editcommit="git commit --amend"
These are my all time favorite aliases
git config --global alias.magic '! git add . >/dev/null 2>&1 && git status --porcelain | git commit -F -'
Thank you!
try this one
alias lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit
@@radadadadee Is this the masochist version of "git log --oneline -a --graph"?
Instead of showing "--force" flag you should default to "--force-with-lease" which will avoid pushing the code if it would overwrite something you didn't anticipate (coworker's code)
omg! that should be the default option for force : D
does that flag have a short version? like how --force is -f?
@@andresreyes8509 no, not as far as I'm aware unfortunately. You can always make an alias if you use it often enough.
cant that just be replaced by a simple
git pull
and then
git push....
??
lmao that seems kinda useless because --force is usually used to overwrite someone else's code. Otherwise just pull the code and push normally.
The most useful git technique I've learned is understanding how it works internally (what is a commit and how it is stored, that a branch is pretty much a pointer to a commit etc). This allows for much more flexibility when it comes to managing your local repo. At work I'm constantly juggling commits between local branches, mixing and squashing them as I need them to. There is no problem in running cherry-pick on a branch to get its' top commit or pushing your previous commit to remote while current one is not ready.
And also reflog.
Can you make a video on this. I would love to learn from you.
Because I am also facing the same issue and cherrypicking is so hard for me to maintain.
Can you please give me some insight on how it works internally please 🙏
That's mostly a sign that git is a leaky abstraction imho
@@BosonCollideris it an abstraction? To me it's a tool that makes it easier to copy code around and have messages and IDs attached to certain versions of it, instead of having separate folders for working on a new feature or so. There are some abstractions in the naming, yes, but even without all of them it's just a tool to avoid having tons of folders and a spreadsheet to know what's where.
@@BosonColliderL take
git switch: move your current changes to another branch. I regularly work on the main branch and then switch those untracked changes to a new branch then I commit them. The perfect use case is when you just want to test something, but you're not sure it's worth it.
> git switch -c''
I didn't know about that. I have been stashing my changes my whole life haha
Thanks
So would you do.
Work on main branch
git checkout -b newbranch
Then won't it automatically take you to new branch? Then have to go back to switch again?
How does it work?
@@voyageruk2002 switch is a replacement for checkout. `git checkout -b` and `git switch -c` work the same. They created switch because checkout does more than just switching branches and now they are trying to make things more specific. To simplify the code base, I guess.
Yup. I use checkout -b
Same results.
OMG THAT EXISTS??? WHAT A PAIN I HAD IN THE LAST COUPLE SPRINTS!
3:21 ah yes, stash: "That's the code the project deserves, but not the one we need right now"
One operation that I use quite a lot is "git add -p", which basically allows me to review each piece of code I changed/added/deleted in order to have more granular control over what I want to include in the next commit, and maybe squash the changes I didn't include, for later.
I add -p to stashes often because I’ll change different components in my code and sometimes I need to filter changes out of the same files
I don't watch Fireship videos that often, but when I do they always blow my mind. Like, I need to watch them over & over to absorb all the things that are in them. Thank you so much for this, we developers need to master GIT for sure.
The quality on your videos is insane.
The voiceover is amazingly clear and nice to listen to.
The topics touched on are explained really well
The graphics are on point..
Amazing stuff!!
IKR, so undersubscriber
TBH the voiceover sounds almost like Microsoft Sam. I am wandering whether he automated the voice track by concatenating prerecorded word samples
Nah, the guy is good fr
git bisect blew my mind. I don't think I will need it in the future, but I love that this functionality exists
This is heavily used when your code has tests and automated jobs. If you have Travis or Jenkins that run tests frequently, this feature allows to figure out which commit introduced a bug that it’s causing failures
You can also run it automatically by providing a script with exit vode 0 for success and non-zero exit code for failure and it will mark all your commits good or bad based on that automatically
My favourite one is "git add -p" to Interactively add blocks of codes, you can add and ignore them as you go through the changes in case you want to split the changes in multiple commits. A colleague showed it to me and it was 🤯
2:35 git revert does not "got back to the original state"; that's checkout / reset. git revert creates a new commit with the opposing changes effectively reverting the reverted commit (hence the name).
Thanks bro
Revert is what you want to use if the commit is already pushed to the remote. Reset is for if you haven't pushed yet.
Yes he mentioned that
He said "without removing the original commit". How else would you "go back to the original state [...] without removing the original commit"? The only way is to create a new commit. So creating a new commit is implied here and you comment is superfluous.
@@Dmitri_Ivanovich by deleting last commit obviously
Sometimes, especially when someone's commit might overwrite the changes you did, removed something, etc, etc, you might wanna do a git rebase on another branch. It helps to just make your branch on top of that one without any consequences. But we need to be careful with it, since it can really mess up everything.
That is good advice, I mention that in the full course.
@@Fireship Glad you liked it! Looking forward to that
Its good practice to make a backup of your current branch and then rebase it with main/yourbranch.. learnt it the hard way
@@buntysingh7315 same
@@Fireship I'm sorry for off-topic, don't know other way to contact... My top-level comment about the long list of Git GUIs seems to disappear, is it caught by youtube's spam filter, by any chance?
6:55 there's also the python pre-commit to check coding style with clang-format before commit. Very useful to be sure the remote only have clean code
Amazing video once again!
--force-with-lease is another awesome --force flag that reduces some of the risks regarding overwriting others changes 😎
sample usage of git hooks: you can make it extract a Jira ticket number from branch name and prepend it to the commit message automatically, so that when you merge branches, you can track all tickets that were merged just by looking at the commit message of the merge
There's one more handy command.. To revert a PR merge and avoid reverting every commit, simply revert the merge commit by using
git revert merge_commit_id -m 1
Here 1 means stay on the main branch and revert the merged branch changes
git cherrypick is also useful when we have to merge a specific commit im another branch to our Say main branch by directly referencing the needed commit and the new added commit is same as that commit in that branch from where it got picked but with a completely new commit id.
git cherrypick is an underrated feature of git.
Yeah
`git cherrypick -x` always.
That bonus tip in the end blew my mind!! The others you come across whenever you Google issues you have with git. But that last one saves so much time especially on terminals that don't have autocomplete.
Master will always be my main branch, It’s the master copy.
Nah, the master 'copy' (oxymoron) is on someone else's server (Github?).
Git's called a distributed VCS for a reason.
As long as you have the same hash, you have the same Mona Lisa!
PS the correct historical term should have been a slave copy, based on slave clocks, but folks back then went with the 'master' figure of speech
Apparently, using the word master anywhere in your code or other tools is now considered as a reference to slavery. If you still have a branch in any of your repos called master, then congratulations you are racist. 😂
Welcome to the inclusive and diversified kingdom of Woketopia 😂😂😂
I am always using master even in new projects.
@@Kevin-jc1fx Most folks simply don't know where the usage comes from. There is a distinction between unique masterpieces created by master craftsmen (such as the Mona Lisa), or the original ship's drawing of Titanic, and forced perfect replication, originally conceived to drive slave clocks from a master pendulum. The original reference is discussed in [1] R. Eglash, “Broken Metaphor: The Master-Slave Analogy in Technical Literature,” Technology and Culture, vol. 48, no. 2, pp. 360-369, 2007, doi: 10.1353/tech.2007.0066 where the 'master' analogy was used directly to call up the idea of slave copies.
Given that perfect replication/copying is the hallmark of software storage, it fits the latter description better than the former. Learning takes time.
@@philipoakley5498 I guess it does not matter, nobody should be force to use "main", master is fine so it make no sens to change it just because someone want to see his ideologie in it
Been using Git for almost a decade, I didn't know most of you shortcuts. Thanks.
This was perfect Jeff. Being a pro member has really paid off. Keep up the great content my guy
I never used the interactive rebase to squash, but you can do it manually as well:
Assuming last common commit in both master and your branch is f8324b, then:
git rebase --onto master f8324b
git reset --soft master
git commit -m "Your squashed commit name"
Works like a charm!
Bookmarking this vid because I'm sure I need to rewatch it sooner or later LOL
I just made a personal playlist to just book mark his videos lol
Everything is gold in this channel
I personally avoid git commit -a or git add . because it will stage and commit all new and changed files and it's important to be selective about what you commit if you happen to be working on a few things at once or just want to separate commits into chunks of specific functionality (so you can revert only those chunks if needed).
'git add -p [file-name]' 🙂
@@RaulTavares what does -p do?
@@sufiserious798The -p option let's you selectively add changes from a file instead of adding the entire file. Can sometimes be useful, i suggest you try it out yourself.
This is the sort of shit I don't learn working as a solo developer man -.-
Nice shortcuts!!
D3.js in 100 seconds LETS GOOOOOO 🥳🥳
The most important thing for me was to learn how the git graph is built. Not the details but the structure of the commits in general. Close to all operations update that graph. Visualizing what these operations do was most helpful.
I love git extensions.
if you cant remember the full name of a branch during checkout. put a letter then press tab, it will either autocomplete the branch name for you or it will lists all the branches starting with the prefix/letter you provided.
That's a common feature of terminals btw
@@ifelseprog completions are a shell feature, not a terminal feature
@@user-ux2kk5vp7m yes my bad
Great video. I never understood Git in depth until i started using GitKraken. Having an UI is so more convinient and u can learn the things a lot quicker. Give it a shot and you will never go back.
I actually find gitkraken confusing, git is more easy to understand.
For me, it was exactly the other way around. I have a feeling that using a UI tool should be allowed only after you understand the git internals. But if you understand those, you won't bother yourself with using a UI tool - plain aliased commands are typically faster to type and execute, and bonus point - you are pretty sure what is going on. While with that that fancy tool you are left at the mercy of its authors.
I use the git graph extension in VSC along with using the built-in git source control viewer that VSC has
'senpai' is the best alternative to 'master'
I have renamed all my master branches to slave-owner
@@vforsh Based
'goshujin-sama' is where it's at for me
git push senpai --force
hmm, i wouldn't wanna forcefully push my senpai
This is the only acceptable alternative to master.
Some nice tips. I didn't know named stashes, will certainly use them in the future. And the 'checkout -' will also be a time saver.
"git checkout -" was a mic drop moment. Blew my mind
there's also a "git checkout -- ." to reverse changes not yet committed if changes are not needed for later, otherwise stash is the way
The same thing works with cd. "cd -" to go back to the previous directory.
I love your content and video style. Best part for me is how you use gifs that perfectly describes what you are talking about.
This might help...
`Git switch -c `
create and checkout directly to the new branch.
I typically use `git checkout -b `
Many ways to git a cat I suppose.
You did awesome, In short span of time you deliver awesome content...
Another pragmatic, useful and time efficient video.
Thanks!
I recommend against renaming the master branch in existing projects, it can break things. Then again, its best to have your branches be named stuff like "prod" for production and "dev" for development
I'm good, I'd rather neck myself than rename from master to main just to please woke activists. Even if main is default I still rename to master.
Personally, I like to rename new repos back to master just to spite the word Nazis.
I name my master branch fuehrer
I name my branches Toby…..
@@evancombs5159 Wait till they here that every usb stick is a slave.
Extremely well explained video and added new stuff I did not know. The master rename to main is the stupidest thing I have ever felt in person about this new vibe of racism and sexism. It is ridiculous.
No one is forcing you to do anything (hopefully anyway). However, when starting new projects, it really doesn't matter what you name your main branch, so why not go with the least controversial one?
@@ibrahimomer9263 probably because not everyone wants to feel being influenced by snowflakes
@@ibrahimomer9263 Because at a certain point, you have to say STOP. Otherwise this bullshit will go on until we cannot communicate anymore w/o constant fear of hitting the next trap. In my country, Germany, the language is being completely demolished meanwhile...
Think for a minute: Do you really believe the word 'master', especially in the absence of a 'slave' as here with git, did hurt a certain group of people so much, that they gathered together and started lobbying at microsoft, for their just case? So that microsoft bent, because the pressure from that group was so high, that they decided to skip the word master in github's default repo settings?
If you believe that, I would like to know who those people were and how they started their campaign for their cause.
Face it: That group does not exist. Nobody, not a single person, is *honestly* being insulted by git using the word master for its default branch. Just like not a single woman in Germany is insulted by the word Wissenschaftler (scientiest), which we may not use any more.
You will HAVE to realize that this stuff is coming NOT from bottom up.
It's coming top down, upon us.
Then ask youself why, whats the reason. *Why* is this being pushed top down?
Invest half a day - You'll find the answer easily.
@@ibrahimomer9263 Because the whole ‘controversy’ is idiotic.
@@ibrahimomer9263 master isn't a "controversial" word outside weird echo chambers.
This video feels like the first page of any StackOverFlow Git-related question's first page. I'm glad to be referring to this video instead of spoofing dust on the lost side of StackOverFlow.
I feel like these videos are someone watching how shit I am and prodding me with encouragement.
like "here you go little monkey, use this hammer to open that coconut you have been hitting with your head for a few hours"
This is the video I needed! I spent several work hours trying to fix a committed bug.
2:45 lol I felt that. I am like a trauma surgeon when things go wrong with git.
Gold as usual. Amazing tips.
`git reflog` -- it's like quicksave ;-)
Oh, I was really wishing for what the bonus trick does, haha!
Something that I do often when before opening a PR is doing ‘git reset -soft {destination-branch}’ so that my changes are not lost, and then reconstruct the commit history. This helps build a cleaner one. Then do ‘git push -f’ and that’s it. But, of course, be careful with the ‘-f’.
I know this is controversial, but I really like to use a UI for git. Personally I use Fork. It just gives you a nice graphical overview of the brances, stashes and currently staged files. Especially for beginners it's easier to wrap your head around everything with a UI.
I like the part where he just explains the core function. No hand holding, no long explanations.
He at least expects the people watching this to be competent enough to figure stuff on their own.
Subbed
For the first time I knows most of the things that's explained in a video from this channel,
Feels so proud,
Ima wizard now. LoL
Best git video in the entire world. Thank you for existing fireship
That is funny how you tell about “main” but still using ”master” in examples 😁
In the main, You gotta be noticed..
Bro!! Having the browser-based VS Code editor right there in repo is a game changer!! Blew my mind 🤯
Hey fireship, I think these tricks for terminal git commands are all cool, but I personally believe in the supremacy of GUI's for git. Originally I fell in-love with GitKraken, ended up getting the pro version, and since then I've converted my entire team to using it. While it does bar you off from some the optional commands / flags you can use in your terminal, I feel it includes all the most important git utilities (checking out, commiting/pushing, ammending, reverting, rebasing (also interactive-ly), merging, stashing, and even more) whilst also providing you with an extremely intuitive UI for a git repository's state. About half of the tips you showed in this video I believe can be handled more cleanly in a GUI, the useful ones that I like doing in GitKraken being bisect, interactive rebase, pretty logs and stashes. Just being able to see a project's entire history, who made each commit, the relationship of all branches to one another, are all extremely valuable features on their own.
I personally only think I really began understanding how git works properly after I started using the console version but that might just be me.
I would also have a hard time working without the git-worktree command ¯\_(ツ)_/¯
Yes! Just wanted to second that.
Also it has some nice features like adding hunks and partial stashes (for hunks and files). Even though that is possible with some CLI magic too in GitKraken it is way, way easier.
For the SSH "I don't have an graphical environment at all" people I can also recommend lazygit, which is a pretty neat TUI for git.
Ahh YES! The first trick you showed I use a lot when updating only modified files. I love the convenience of “git commit -am”!
git merge --no-ff performs a merge without fast-forwarding, so the graph still shows merged branches and their commits. This can be set in a global option. Another cool global option is autostash, so that git pull with stash, pull then apply the stash automatically.
autostash sounds really cool! --no-ff i never heard of, good tip as well
@@henriquematias1986 Not fast forwarding is actually a terrible tip. There is nothing worst than a git log full of merge commits, makes it hideous and unreadable. It's a trunk based development anti pattern.
@@jeremyjones4019 good to hear you point of view! i'm sure it's useful somehow for some people tough ( :
thanks for bringing this up
the github tip was actually incredible. Thank you.
git rebase > git merge when updating a feature branch from dev / master
Great video! Even though I've worked with git for some time, there are some commands that I didn't know that would make my life easier, so thanks for that!
The best thing I did was start using a Git UI (e.g. in Webstorm) for git. I make far fewer mistakes and it helps a lot when doing complex rebase / conflict resolution. It's important to understand git fundamentals but why make it hard for yourself?
Actually it's harder to leave keyboard and go to mouse that's it
@@amit-mishra I don't need to leave my keyboard at all to use the UI
This is such a well explained and clean video! Everything to the point.👏
git cherry-pick is also my favorite to pick the commits(changes) from different branches to my current branch, sometimes helpful in testing new changes/features 🔥
Kya 'Chacha' kya chal raha hai ? Tumko college me sab log 'Chacha' 'chacha' kyu bolte the ?
"git checkout -" will save me a couple years of life, thank you
@@user-tu6oh2op9s get a job
I have always used main as my default branch name, but for personal projects, I now use master since they decided to make it politically incorrect
That "git bisect" is so darn neat, why have I never seen this before?!
Tip #14
alias pit="git "
alias bull="pull "
pit bull
alias bush="push"
alias world="origin"
alias wide="master "
pit bush world wide
git bush did 9/11
Want to undo just some files? Try `git restore -SW `.
`-S` unStages the file and `-W` undoes it in the Working directory.
4:05 I'm going to name the master branch "slave" just to be contrarian
@@randomyoutubeuser8509 Weed out the "problematic" ones. It's a solid strat.
Based and redpilled
@@undefinedvariable8085 Exactly, if the word 'master' is too much for someone, we're definitely not gonna be able to work together.
Timing couldn’t be better, thx!
sticking with master, I don't like being dictated to by seditious ideologues.
`git reset -hard` doesn’t delete your changes forever. You can always get them back using `git reflog` and creating a new branch referencing the dangling commit that had your old changes. Just make sure you do it before it’s garbage collected
4:05 Next thing I know the police is outside my house confiscating all of my IDE drives because they use master/slave configuration jumpers
That github vscode thing is life changing. Thank you
When creating a new branch and switching over to it traditionally you would use
git branch new-branch
git checkout new-branch
This can be done with a single command
git checkout -b new-branch
We can use: git switch -c
@@nishanths9652 its switch only right, checkout -b used to create new branch
Oh wow git bisect looks so powerful. Finding the issue in O(log n) instead of O(n) is a huge improvement.
Idk, those Git CLI commands are only for masochistic guys. I mean, the VSCode Git plugin and GitHub/GitLab UI are there for a reason! They visualize the diffs properly, simplify staged commits, assist you at resolving merge conflicts, let you modify the squash message before merging the feature branch, show you which commit made the CI/CD break, etc. Why not use those tools instead? It saves lots of time if properly used :D
And btw, great work @Fireship ;)
as a bonus tip on squashing commits - if you branched off of, let's say, master and made some commits on your feature branch, provided you keep master and feature up to date (rebased), you can do git reset --soft master to get your feature branch commits turned into the staged files and then proceed to create one commit out of all the changes.
Twitter: "everyone should use main instead of master!!"
Most Devs: "nah"
Agreed
Do not bend a knee to an ideology that tells you 2 + 2 = 5, men can get pregnant, and gender is a social construct. We have to push back against the woke insanity.
Medium: "everyone should use main instead o-"
Most Devs: "nah"
Devto: "everyone should-"
Most Devs: "nah"
@@kavustock 100%. Don't allow your enemies to define the words you use.
Another pointless woke thing then? *sigh*
Have they not considered the minority of sexual submissives might prefer the term "Master"? Shame on them.. :-P
When I subscribed to your channel you had about 80K subs.. just saw you surpassed 800K. Keep up the good work.
Thanks for the social warning. I will start naming all branches just 'branch' so that no one feels left out. I'll also start adding random ascii characters to binary files to make them more inclusive of other bits. It might be a small adjustment in the short term but ultimately worthwhile.
Even from SVN days, I find UI tools like Tortoise Git will help you a lot specially when checking conflicts.
I will never stray from calling my master master. Any other name would be disrespectful.
Great video as always. the first tip `git -am` will add the git-tracked files (not all the files)
still remember this "Nvidia 0:23 you ".
😂👌
Love it. Even as an experienced dev I didn't know all of this. Thanks !
"git stash save" has been deprecated in favor of "git stash push".
The comments section is somehow a better version of Stackoverflow with less hate toward new developers.
Loving it
Nothing wrong with the word master
yes there is
@@TeHzoAr please elaborate...
After years of using git, I'm blown away @2:00
How will you know what the master branch is if everyone is using a different naming convention?
because there is always a default branch, and not just a naming convention
@@sodiboo Git does not have a "default" branch - the first created branch is the default. Github/-lab/Bitbucket added that functionality to their implementation.
but you can rename the first created branch of course - effectively being the default for people cloning the repo.
@@flightvision Oh? really? I mean that does sound completely plausible, but how does git know which branch to actually pull if you clone with no extra parameters?
Dude, Many People around their world had problems with their previous BDSM partners so calling the branch master might be offensive to them.
git work trees has also been really handy for me. Having two branches up on the ide has helped me with context switches.
I refuse to use any term other than "master" for the master branch of my project, simply because everyone else insists on changing it.
I mean you could say “wow, problematic language exists, let’s fix that quickly and easily so we welcome everyone”, or you could be this guy
2:48 That literally BLOWN my mind!
Why didn't I know it earlier???
Today's Challenge: Speak rapidly, "Get Good At Git"
I love his speed
That's just _Bleed_ by Meshuggah
Tomorrow's Challenge: create a git shortcut for today's challenge.
Also good:
Reflog
Gitk
How to search commits by change or message
How to handle merge conflicts
Checking out individual files at a commit
+1 for gitk . Although you have to install it separately. It makes easier to find old commits and changes easily without going through git log.
04:05 master branch renaming is so stupid 🤦🏻♂️
To avoid the "Master" branch controversy I always rename my main branch to "Massa". I am doing my part!
Never use --force, use --force-with-lease
This man does not stop, and I don’t want him to
It's still called a master branch in the docs.
And it should remain that way, unless Git can find a better reason for a change than the one implied.
Fireship keeps git'ting better and better!
P.S the way I thought git commit -am worked was like: you can only use it if the files you're trying to add were added before, with git add. If it's new files you're trying to add, you're gonna have to first use git add, and only then you're gonna be able to stage and commit with git commit -am.
Of course, it's git, so there's a chance I got it all wrong.
That is correct, commit -am only stages & commits files that are already tracked.
You'd have to track any new files with 'git add .' before running the commit command
@@CynicalOldDwarf Oh, thanks! I always distrust myself when it comes to git and always double check what I know. Although I was pretty sure about this one. Also, yeah, the proper way of saying that is: it only works with already tracked files. With untracked files you just use git add first since git commit won't work. Thanks!