@@Microphunktv-jb3kjno, he did make linux. Its just at this point, everyone calls a linux distro “linux” because people dont want to say gnu/linux or [distroname] linux
1:22 nitpick - `git add .` adds all files in `.` (the current directory). Adding "all the files" (in the repo) is done with `git add -A`, which is a meaningful distinction if you are in a subdirectory
Man, I honestly tell you this is the best Git/Github video I've seen. Im pretty impressed how you manage to tell in an easy way and clearly so many topics in less than 10 mins. Kudos for you, bro 👍🏼👍🏼👍🏼
It’s easier to think of rebase as “moving your commits to ”. Usually what we want is for our commits to just follow on from the HEAD of the develop branch or what ever branch we’ve branched. So we generally “move our commits onto the HEAD of develop”
no you're already at the head of dev before you do git rebase main on the dev branch, rebase would just take all your commits up to the point where it diverged with main and stashed them, then it resets to the main branch and applies them back from stash
@@masterflitzer I’ve updated my comment because it isn’t specific to any branch. When I rebase, my thought process is…. I want to move the linear chain of commits representing the change I want to make onto some branch. I’ve always checkout out the feature branch. I’m usually branched from the develop branch, rather than the master branch (aka fit flow style), so I’ll run ‘git rebase develop’. I think of this command, as move all my commits from wherever they are on the develop branch to the HEAD of the develop branch.
@@br3nto yeah moving onto is a good term and makes it easier to think about, i was just confused because you said develop branch as in the video the example was rebasing a feature branch on top of the main branch, but i understand what you mean now
Always a good time when you need to submit a PR based on multiple dependent PRs so you make a branch then merge the dependencies there then rebase your branch onto that branch, then once the dependencies are merged again rebase from your dependency branch back onto main.
Rebase is annoying when you sometimes have to resolve conflicts for old commits you've made as it applies your commits to head 1 by 1 in the same order you committed them. Which might mean you're resolving conflicts for old code which is getting removed in the next commit anyway... It's one of the reasons I don't like it. Unless maybe you squish your commits so you don't have to resolve conflicts for older commits. But then you're managing commits a bit too much. I'd rather three-way merge in those cases.
This is the worst thing for me about rebase, too. I once (in a larger team) had to reapply like 40 commits during a rebase. That took more than 2 hours to finish, where a merge would have probably been done in 20 mins. Not only do you have to choose which is the right code to merge on each step, you also basically have to remember in which order you did it! Very error-prone. Also in my opinion you get very little in return. A clean history without merge commits. But what for? How often do you even actually look at the entire git history? I think I never did. MAYBE in order to understand code better when you join a new project. Honestly the few times a month I have to work with the history, I don't even notice merge commits, I just sort of skip them. And I think if you need to look into your history often, then something else may be wrong. Also, isnt' it kind of the point to have the history shown? Explicit merge conflicts then are just markers that show what actually happened. AND you have to force push. My 2 cents
This is exactly the video that I was looking for today and did not find but just noticed it was recommended to me somehow in my notifications!? Thanks subbed!
@@bravo90_ I can never remember the git cli. And I keep wondering if a gui could provide the visualizations we saw in this video, to help understand branching, etc...
I can't remember the last time I did a push before doing a fetch. I'm always amazed by the stubborness with which some (many!) full time developers refuse to learn the basics of git.
So rebase is like a fast forward for the case when main branch changed before we decided to merge? P.s. nevermind it literally doesn't merge and you just slide it along to the newest state of main.
I wonder how people handles whole codebase changes in just terminals. I prefer clicking on Plus Icon to stage then a button to commit. (Yes, Yes. I know. We don't get UI everywhere. I know)
Sometimes Im scared by failed merge and the worst thing that sometimes happens is that I push the `banana`. I use lazygit to resolve conflicts as my editor doesn't yet support git.
I think merge integrates the changes from upstream and creates a new "merge" commit while rebase just rewrites the history putting your changes after what you fetched.
the best strategy is to target linear or semi-linear git history: always rebase feature branches, always merge into main branch (never rewrite history in main), preferably squash merge into main so reverts of PRs are easier if you don't rebase feature branches you can easily loose control over the history and merge conflicts are harder because you don't know what changes when if you neither squash merge nor rebase feature branches your git history in main will be chaos and not semi-linear anymore and that doesn't scale well e.g. when you are working in a team
Couple of days i accidentally tried to push .env file with oauth api keys and i didn't know that this env wasn't in my gitignore so githup didn't accept the commits and i was freaking out not knowing what to do i didn't even read the error it was so long like a linux booting screen Being not able to push your finally it's working code is a terrifying experience especially if you spent couple of days on it and actually forgot what it does and how it works
im just trying to figure out how to remove a file i committed in a commit thats 7 commits back without changing any of the last 6 commits. i cant push bc that file is too large to push to github, i never meant to add it but i cant remove it no matter what i try.
You can also rebase using: `git checkout main && git pull . feature1 --rebase && git origin push`, which is way easier to to understand and figure out what's wrong when something goes wrong, imo.
aren't you pushing to main then? this should always be blocked, only PR into main, atleast as soon as you're not working alone anymore also your command is wrong it's git push not git origin
@@insu_na I'm using it for quite some time and never had any issues. I think it's experimental because of some advance features but if you just going to be switching and creating branches, it's perfectly fine.
yeah i always do git config --global pull.rebase true rebase everything, except merge into main (preferably squash), cause you don't want to rewrite history in main ever
Its not "How to finally Git Good", its "how to start with git". And im using it for while now, not good at it though. But i didnt find any info here that will fill my gaps.
@@br3nto checkout can be used to restore files in the working tree. If your project contains a branch and a file of the same name, you can accidentally delete your progress. There is a reason why checkout was split into switch and restore commands.
thats not even close to fireships branding, different colors, different fonts, font stroke vs no-stroke, non monotone background, use of glow vs no glow.
0:21 Jesus Chris my heart actually skipped a beat hearing that chime 😂😂😂
Seriously! I was watching this video on my phone at night, half past 12, and boom 💥 😅 😅 don't give us jump scares, man..
Torvalds isnt creator of Linux ,
He made the kernel, not the OS.
Its like saying Kellogs made corn.
@@Microphunktv-jb3kjno, he did make linux. Its just at this point, everyone calls a linux distro “linux” because people dont want to say gnu/linux or [distroname] linux
Linux is the kernel. GNU/Linux is the operating system that uses the kernel named Linux.
lmao fr guy scared the fuck out of me
1:22 nitpick - `git add .` adds all files in `.` (the current directory). Adding "all the files" (in the repo) is done with `git add -A`, which is a meaningful distinction if you are in a subdirectory
This is by far the most crisp and to the point explanation for merge conflicts I have ever come across, it's really helpful, thanks
Okay, this video deserves a bookmark in my browser. Well done.
cheat cheats are better for looking it up in the future, atlassian has a good one iirc
watch it now
better explanation than 99% 3-hour long git tutorials
Liking the video even before starting because 0:04 is the message I got today and this video shows up in my feed the same day.
Man, I honestly tell you this is the best Git/Github video I've seen. Im pretty impressed how you manage to tell in an easy way and clearly so many topics in less than 10 mins. Kudos for you, bro 👍🏼👍🏼👍🏼
As someone who is getting ready to apply to a job with no git experience, I’m glad I watched this. Thanks!
It’s easier to think of rebase as “moving your commits to ”. Usually what we want is for our commits to just follow on from the HEAD of the develop branch or what ever branch we’ve branched. So we generally “move our commits onto the HEAD of develop”
no you're already at the head of dev before you do git rebase main on the dev branch, rebase would just take all your commits up to the point where it diverged with main and stashed them, then it resets to the main branch and applies them back from stash
@@masterflitzer I’ve updated my comment because it isn’t specific to any branch. When I rebase, my thought process is…. I want to move the linear chain of commits representing the change I want to make onto some branch. I’ve always checkout out the feature branch. I’m usually branched from the develop branch, rather than the master branch (aka fit flow style), so I’ll run ‘git rebase develop’. I think of this command, as move all my commits from wherever they are on the develop branch to the HEAD of the develop branch.
@@br3nto yeah moving onto is a good term and makes it easier to think about, i was just confused because you said develop branch as in the video the example was rebasing a feature branch on top of the main branch, but i understand what you mean now
@@masterflitzer haha yeah I figured. Thanks for that, because i was able to improve my original comment.
Love the visuals you used on the video !
Always a good time when you need to submit a PR based on multiple dependent PRs so you make a branch then merge the dependencies there then rebase your branch onto that branch, then once the dependencies are merged again rebase from your dependency branch back onto main.
Rebase is annoying when you sometimes have to resolve conflicts for old commits you've made as it applies your commits to head 1 by 1 in the same order you committed them. Which might mean you're resolving conflicts for old code which is getting removed in the next commit anyway... It's one of the reasons I don't like it. Unless maybe you squish your commits so you don't have to resolve conflicts for older commits. But then you're managing commits a bit too much. I'd rather three-way merge in those cases.
This is the worst thing for me about rebase, too. I once (in a larger team) had to reapply like 40 commits during a rebase. That took more than 2 hours to finish, where a merge would have probably been done in 20 mins. Not only do you have to choose which is the right code to merge on each step, you also basically have to remember in which order you did it! Very error-prone. Also in my opinion you get very little in return. A clean history without merge commits. But what for? How often do you even actually look at the entire git history? I think I never did. MAYBE in order to understand code better when you join a new project. Honestly the few times a month I have to work with the history, I don't even notice merge commits, I just sort of skip them. And I think if you need to look into your history often, then something else may be wrong. Also, isnt' it kind of the point to have the history shown? Explicit merge conflicts then are just markers that show what actually happened. AND you have to force push. My 2 cents
You just need to enable the “rerere” flag. Once you resolve a conflict - future rebases will reuse the same resolution
Great video!
Dream coming in to #BoostTheBoy letsgooo
Thank you, I love your videos!
This is exactly the video that I was looking for today and did not find but just noticed it was recommended to me somehow in my notifications!?
Thanks subbed!
the ms teams ringtone is more triggering than my morning alarm
That teams ringtone, I got one yesterday. 😂
luv the video format!
I also suggest learning about working directory and local repository.
0:21 I panicked, and put on my headset 😂😂
I am watching nearly midnight and this woke me up
I legit jumped upon hearing that bruh
This was great! Would love to see a part 2, for using git in VS Code.
Git is a command line tool. It would be same as this video in vs code.
@@bravo90_ you’re right. But… what if we instead requested a video on some of the common GUIs and tools for git instead?
@@b_dawg_17 i think this tutorial was comprehensive
@@bravo90_ I can never remember the git cli. And I keep wondering if a gui could provide the visualizations we saw in this video, to help understand branching, etc...
@@i_accept_all_cookiesNot only could it, but there are in fact many such VS Code extensions that do just that
Add timestamps please
Bro, its a 10min video
Git gud
he forgot to make commits ig
@@sustrackpointus8613 That's long enough for timestamps imo.
@@sustrackpointus8613 Yeah but it covers a lot of very basic commands, so it would be nice to jump past them more easily.
I just want to let you know that I loved the video :)
best Git tutorial! 👏👏👏
Can you please tell me which terminal you are using with, if any, theme or settings ?
Hey there, could you share your nvim config? looks amazing
I can't remember the last time I did a push before doing a fetch. I'm always amazed by the stubborness with which some (many!) full time developers refuse to learn the basics of git.
Huh?
Fetch vs pull. please.
So rebase is like a fast forward for the case when main branch changed before we decided to merge?
P.s. nevermind it literally doesn't merge and you just slide it along to the newest state of main.
I wonder how people handles whole codebase changes in just terminals.
I prefer clicking on Plus Icon to stage then a button to commit.
(Yes, Yes. I know. We don't get UI everywhere. I know)
Sometimes Im scared by failed merge and the worst thing that sometimes happens is that I push the `banana`. I use lazygit to resolve conflicts as my editor doesn't yet support git.
i push the banana?
Really good tutorial!
"after this video, rebase will be like any other git command" this does not fill me with hope
Great vid
0:21 wtf man I immediately grab my phone
Such a great video to the point no bs
🔥 CSS Magic: Turn Basic Text & Emoji into a Masterpiece! #cssmagic #webdesign #webdevelopment
ruclips.net/user/shortsEao_bn95Z3Q?feature=share
Question: When to use git merge vs rebase? I can fetch updates from main, then merge main into my feature branch locally, then push that up right?
I think merge integrates the changes from upstream and creates a new "merge" commit while rebase just rewrites the history putting your changes after what you fetched.
Simple, never rebase anything.
the best strategy is to target linear or semi-linear git history: always rebase feature branches, always merge into main branch (never rewrite history in main), preferably squash merge into main so reverts of PRs are easier
if you don't rebase feature branches you can easily loose control over the history and merge conflicts are harder because you don't know what changes when
if you neither squash merge nor rebase feature branches your git history in main will be chaos and not semi-linear anymore and that doesn't scale well e.g. when you are working in a team
@@vasiliigulevich9202 there's a simple rule: squash merge into main, rebase everything else
Perfect, now teach us how to HEGALE!
What theme are you using for the terminal?
Couple of days i accidentally tried to push .env file with oauth api keys and i didn't know that this env wasn't in my gitignore so githup didn't accept the commits and i was freaking out not knowing what to do i didn't even read the error it was so long like a linux booting screen
Being not able to push your finally it's working code is a terrifying experience especially if you spent couple of days on it and actually forgot what it does and how it works
im basically sharing this with everyone I know.
Which font is being used in the terminal emulator?
im just trying to figure out how to remove a file i committed in a commit thats 7 commits back without changing any of the last 6 commits. i cant push bc that file is too large to push to github, i never meant to add it but i cant remove it no matter what i try.
why not use git pull origin main on the feature branch before merging
because you don't have linear history then, better do git pull --rebase origin main
this had pretty much all the basics covered.Great video .LIked and subscribed.
yessir!!!
You can also rebase using: `git checkout main && git pull . feature1 --rebase && git origin push`, which is way easier to to understand and figure out what's wrong when something goes wrong, imo.
aren't you pushing to main then? this should always be blocked, only PR into main, atleast as soon as you're not working alone anymore
also your command is wrong it's git push not git origin
what kind of color theme is it?
what terminal theme is that?
You shouldn't be using git checkout for creating and switching between branches, there is a new command for this, which is git switch.
That's true! git switch is more recent, I am just accustomed to using checkout at this point 😅
Git checkout is still supported by the latest git and also it's not depreciated. So why not?
@@bopon4090 It's because git promise backwards compatibility. Try switching to a branch that doesn't exist using checkout.
according to the git documentation `git switch` is considered experimental
@@insu_na I'm using it for quite some time and never had any issues. I think it's experimental because of some advance features but if you just going to be switching and creating branches, it's perfectly fine.
rebase should be the default, you always want your changes on the top of upstream, you don't want to do merges ever
yeah i always do git config --global pull.rebase true
rebase everything, except merge into main (preferably squash), cause you don't want to rewrite history in main ever
What cli does you use bro ?
Most likely zsh with powerlevel10k as a theme and autosuggestions (plugin)
What terminal application and shell prompt are you using?
Looks like zsh
Looks like the future
Its not "How to finally Git Good", its "how to start with git". And im using it for while now, not good at it though. But i didnt find any info here that will fill my gaps.
Too many o's in title. We only need one of them.
which code editor do you use
I usually use vscode, but what you saw in most of the video was neovim!
Seeing git commits without a jira ticket # gives me anxiety 😆
Video is too short
This guide is already outdated. You should be using git switch instead of git checkout to prevent unwanted behavior
When has git checkout ever given unwanted behaviour?
@@br3nto checkout can be used to restore files in the working tree. If your project contains a branch and a file of the same name, you can accidentally delete your progress. There is a reason why checkout was split into switch and restore commands.
@@Treviath I guess I’m exceptionally lucky. I’ve never run into that problem with git checkout.
@@br3nto Neither have I. It's probably quite rare, but dangerous enough to warrant the split
Another Fireship clone?
0:21 jesus this is not funny x(
Just add -force flag on every git command, problem solved
Is that a new wave of videos about git rebase? Who is the target audience, guys who never read docs on official git web site?
merge should be forbidden
This video is useless! Thumbsdown!
Bruh, invent Your style and stop using Fireship sh!t for the thumbnail! 😂😂😂
Fireship doesn't have a style. It's just the default vscode look and feel
thats not even close to fireships branding, different colors, different fonts, font stroke vs no-stroke, non monotone background, use of glow vs no glow.
His style is so good.
- Make shit content
- Put shit memes
End
I would like to reach you about a collab. What is the best way to reach you? Email?
Jezus fuckkkk just use git extensions