It's "git notes" for sure, because my science supervisor often forgets why did we decide to change something, and notes are very convenient to refresh the memory
One of the things I find myself using way too often is `git stash`. Sometimes I will make a bunch of changes, and then when I go to commit, I realize that I'm still in the main branch. But I want them to be in a feature branch. So I will use `git stash` to store my changes, switch to the feature branch, and use `git stash pop` to bring those changes into that feature branch instead.
If the feature branch doesn't exist yet, you should be able to just 'git checkout -b feature_branch'. Or at least that's how I remember it, I have to admit I've been switching and creating branches with GitHub Desktop for the last year or so.
I think that if the files you've changed in the main branch have not been modified in the feature branch, you don't even have to do a "git stash" and just switch branches.
Incidentally, that's what JetBrains IDEs do. I always get annoyed with VS Code when it says "oh, I can't pull/rebase this branch, because you have uncommitted changes!"... "Then do a stash before, and a stash pop after, you dummy!"
I think being comfortable with interactive rebase, reflog and understanding how to use git reset --mixed and --soft pretty useful. For example if you've accidentally amended your changes to the last commit, but wanted to make a separate commit, just find the SHA from before the ammend with reflog, mixed-reset to that, and your changes are staged to be committed again.
Could you please make a follow along dev video using git best practices - what to commit, when to switch and so on, how merge, rebase - and why . just kind a real life workflow.
There are two other great lectures in this format that I can strongly recommend - ”So you think you know Git” and part 2 by Scott Chacon. It’s a bunch of random stuff just like this, some of it very useful or interesting. 🧐😁
First time I used `git bisect` was to track a bug in the Linux kernel .. took like 7-8 iterations (and kernel builds .. and reboots) to find the culprit. Very satisfying when successful! One command I use a lot to get the current commit hash: `git rev-parse HEAD`
Hi Arjan! Please, read till the end ✌ Long-long-long time ago when the magic of RUclips algorithms recommended me one of your videos, I actually didn't like it at all, in any possible way it was the opposite of what I'd consider a good tech video, because I had an impression, you are just another tech-blogger, a little bit too much pretentious, and the content itself is not that much useful, but... BUT! But for some reason I subscribed and kept watching (don't know why, maybe click bates work haha), and I didn't notice how my perception of your channel changed gradually. Today I believe you are an awesome person, and when I saw that this really cool video only has 37 comments I felt it's not fair. Honestly, I was expecting at least 1-2 thousand of comments. I'd like to say what I like about your channel and your videos specifically: 1. So nice, cozy and comfy! It's almost like a Christmas evening but, it's about coding, and you are Santa. 2. I like the little humor you add, it's exactly enough to make watching interesting, yet not turn into a comedy. The kind of intellectual humor which's so rare these days. 3. It's obvious for every one: you sir, are a 100% pro in this field, not a person, who just pretends to be one. And even I don't need 75% of what you are talking about for my work, I like to know more about it, because it looks so easy when you explain things. 4. The setting, the light, the sound - just perfect without any shouting, music or anything else! Honestly, I started to watch your videos not for education purposes, but just to listen to something smart during coffee breaks. Your channel gives the same feeling as the famous LockPickinLawyer: calm intellectual retreat. I sincerely wish your channel to grow and prosper! 🖖 If one day you are traveling in Hong Kong or Shenzhen (or just South China in general), I owe you a cup of coffee! Cheers!
Thanks so much! It’s awesome to know the hard work doesn’t go unnoticed. There’s so much more behind a single video than people realize, all the behind-the-scenes hustle. Would love to grab that cup of coffee one day!
My whole workflow is built around worktrees. I do a "bare" clone to keep that base directory relatively clean, and the keep all worktrees in that base.
I really expected to see git ls-files / git cat-file in the list. Learning about those two will help dispel the mystery in the git db. I echo the comments about interactive rebase - git rebase -i - that command has saved my bacon more than once. Also this is a standard alias I setup on any new system to get a one line, colorized log per commit: alias.lg=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%Creset' --abbrev-commit Aliases are a powerful feature such as this one to save typing: alias.stashu=stash --include-untracked But I guess git worktree might be even more useful now a days ... Thanks again for a great video!
You left out one important detail about "git bisect" - If you have many commits to go through to figure out where a bug was introduced it becomes quite tedious to manually mark every commit as good or bad. You can pass a script to "git bisect" that based on its exit code will mark a commit as good or bad and can automate the search for the oldest bad commit. That script could take care of the heavy lifting such as pulling dependencies and then building and testing your application.
Since .gitkeep is a convention and not a first class feature, I prefer a .gitignore file that ignores all files except itself. If that is confusing, a documentation file e.g. README that explains the purpose of the kept empty directory might be preferred. I think both those are slightly better than a .gitkeep, IMHO.
My favorite one by far is git worktree. It saves me a lot of time switching between branches. What's yours?
Mine too, as I have to do it a lot stash or commit and then move to other repo
It's "git notes" for sure, because my science supervisor often forgets why did we decide to change something, and notes are very convenient to refresh the memory
The -p (patch) flag for git-stash and git-add, helps me avoid monster commits.
Agreed with worktrees.
For complied languages, it can actually save complain time as well, since no files need to be changed when switching branches.
One of the things I find myself using way too often is `git stash`. Sometimes I will make a bunch of changes, and then when I go to commit, I realize that I'm still in the main branch. But I want them to be in a feature branch. So I will use `git stash` to store my changes, switch to the feature branch, and use `git stash pop` to bring those changes into that feature branch instead.
If the feature branch doesn't exist yet, you should be able to just 'git checkout -b feature_branch'.
Or at least that's how I remember it, I have to admit I've been switching and creating branches with GitHub Desktop for the last year or so.
I think that if the files you've changed in the main branch have not been modified in the feature branch, you don't even have to do a "git stash" and just switch branches.
Incidentally, that's what JetBrains IDEs do. I always get annoyed with VS Code when it says "oh, I can't pull/rebase this branch, because you have uncommitted changes!"... "Then do a stash before, and a stash pop after, you dummy!"
I just git checkout a new branch
You don’t need to stash in this case! Just create the new branch.
I think being comfortable with interactive rebase, reflog and understanding how to use git reset --mixed and --soft pretty useful. For example if you've accidentally amended your changes to the last commit, but wanted to make a separate commit, just find the SHA from before the ammend with reflog, mixed-reset to that, and your changes are staged to be committed again.
Yeah I still haven't wrapped my head around what "--mixed" does when using git reset 😅
Could you please make a follow along dev video using git best practices - what to commit, when to switch and so on, how merge, rebase - and why . just kind a real life workflow.
There are two other great lectures in this format that I can strongly recommend - ”So you think you know Git” and part 2 by Scott Chacon. It’s a bunch of random stuff just like this, some of it very useful or interesting. 🧐😁
ruclips.net/video/aolI_Rz0ZqY/видео.html
Yes, those are really good!
Amending is certainly one feature not mentioned that is very important to know - fixing existing commits.
First time I used `git bisect` was to track a bug in the Linux kernel .. took like 7-8 iterations (and kernel builds .. and reboots) to find the culprit. Very satisfying when successful!
One command I use a lot to get the current commit hash: `git rev-parse HEAD`
Hi Arjan! Please, read till the end ✌ Long-long-long time ago when the magic of RUclips algorithms recommended me one of your videos, I actually didn't like it at all, in any possible way it was the opposite of what I'd consider a good tech video, because I had an impression, you are just another tech-blogger, a little bit too much pretentious, and the content itself is not that much useful, but... BUT!
But for some reason I subscribed and kept watching (don't know why, maybe click bates work haha), and I didn't notice how my perception of your channel changed gradually.
Today I believe you are an awesome person, and when I saw that this really cool video only has 37 comments I felt it's not fair. Honestly, I was expecting at least 1-2 thousand of comments.
I'd like to say what I like about your channel and your videos specifically:
1. So nice, cozy and comfy! It's almost like a Christmas evening but, it's about coding, and you are Santa.
2. I like the little humor you add, it's exactly enough to make watching interesting, yet not turn into a comedy. The kind of intellectual humor which's so rare these days.
3. It's obvious for every one: you sir, are a 100% pro in this field, not a person, who just pretends to be one. And even I don't need 75% of what you are talking about for my work, I like to know more about it, because it looks so easy when you explain things.
4. The setting, the light, the sound - just perfect without any shouting, music or anything else! Honestly, I started to watch your videos not for education purposes, but just to listen to something smart during coffee breaks. Your channel gives the same feeling as the famous LockPickinLawyer: calm intellectual retreat.
I sincerely wish your channel to grow and prosper! 🖖 If one day you are traveling in Hong Kong or Shenzhen (or just South China in general), I owe you a cup of coffee! Cheers!
Thanks so much! It’s awesome to know the hard work doesn’t go unnoticed. There’s so much more behind a single video than people realize, all the behind-the-scenes hustle. Would love to grab that cup of coffee one day!
My whole workflow is built around worktrees. I do a "bare" clone to keep that base directory relatively clean, and the keep all worktrees in that base.
I really expected to see git ls-files / git cat-file in the list. Learning about those two will help dispel the mystery in the git db.
I echo the comments about interactive rebase - git rebase -i - that command has saved my bacon more than once.
Also this is a standard alias I setup on any new system to get a one line, colorized log per commit:
alias.lg=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%Creset' --abbrev-commit
Aliases are a powerful feature such as this one to save typing:
alias.stashu=stash --include-untracked
But I guess git worktree might be even more useful now a days ...
Thanks again for a great video!
You left out one important detail about "git bisect" - If you have many commits to go through to figure out where a bug was introduced it becomes quite tedious to manually mark every commit as good or bad. You can pass a script to "git bisect" that based on its exit code will mark a commit as good or bad and can automate the search for the oldest bad commit. That script could take care of the heavy lifting such as pulling dependencies and then building and testing your application.
Awesome video!
Thank you! Glad you liked it.
Could you consolidate all the concepts of git in a course like structure. Could be pretty usefull
I like interactive rebase the most and force push to master.
I like "git blame". The name says it all!
@ArjanCodes I always wonder why you don't pronounce the "i" in repository. You always say: repostory
learning git really well honestly is harder than learning Python.
My favourite: "git gud".
Haha, right on!
Since .gitkeep is a convention and not a first class feature, I prefer a .gitignore file that ignores all files except itself. If that is confusing, a documentation file e.g. README that explains the purpose of the kept empty directory might be preferred. I think both those are slightly better than a .gitkeep, IMHO.
IIRC, Linus said GIT sucks, but sucks less than all the others.
`git co -p` or `git reset -p` or `git add -p`, `git co main; git pull; git co -; git rebase -`
if git was really good then every writer would be using it but no it's a distraction from the artistic process
Not really, is just a skill, like regex, once you're confident with it you'll kick yourself for not learning it years ago.
It's because every day we stray further from the beauty of punched card coding
@@iSJ9y217 😂