💌 Inquiries: thecodinggopher@gmail.com ☕ Buy Me a Coffee: ko-fi.com/theco... 👨💻 Get 40% OFF CodeCrafters (High-quality programming courses): app.codecrafte...
`git stash` is always presented as a way to save work without creating a commit, but it also has another use, especially if you use git worktrees: store changes that you often do during development but then remove, for example turning on debug messages or always build something that is normally not built.
It's a good usage but imho if you end up needing these tools frequently and consistently, you should consider introducing them in your codebase (eg, set up a specific build task) so that you can also provide these capabilities to other developers
@@carmineingaldi47 In my case it's just a temporary activation or deactivation of what is built by Jenkins. It's already controlled by flags, so there is nothing to add, but the default values are not always suitable for what I'm working on.
You don't have to use clickbait like "don't rebase", your content is good quality as it is. Git rebase has its purpose and nothing in this video talks about replacing that.
This was a perfect refresher, I used to use cherry-pick occasionally but totally forgot what the name was just remembered the functionality. Also I am a fan of stash save and stash pop in conjunction with the stuff you mentioned. The other commands were new to me and I love it.
Submodules are evil. I strongly recommend that you use a language specific build to maintain the dependencies. Cargo, Composer, NPM, or whatever, but using submodules is bound to cause issues.
Reset --hard is defintely not only for junior engs: if you like to make PoC of your changes before creating a real commit, you might want to mess up with your code from HEAD, reset, write good code based on informed decisions, commit and push
was really anticipating your next upload and you definitely delivered with this vid! been here since the beginning and I can tell ur starting to find a video style that works for u, it’s really great to see. regardless ur vids are always very informative cant wait for the next vid
Don't keep your code in stash for too long Stash is considered cache, it's very easy to mistakenly clear git cache If it's not committed, it doesn't exist
really solid video thank you for this one. how important is it to learn git? i want to learn more about git reset --hard and things like detached head state or removing things that are untracked. i think i can do that with git clean but there are lots of other commands out there in the wild that I don't fully understand. how about a vid on breaking down the 10 hardest git commands or least misunderstood ones? i think this could brings lots of value
can you make a follow-up video on git rebase? i never really understood if it's something I should be using or not. some devs say things like oh you should never rebase because you are rewriting history and you can't see all the other branches and merge commits if you use something like --no-ff. so what is your opinion here should we even be rebasing at all or just skip straight to using merge. i guess there are some use case for rebase if you really want to get that linear commit history or if you have a bunch of weirdly worded commits and you want to squash it using an interactive rebase with git rebase -i and then s or squash the commits together?
I usually rebase my own branch onto main branch, so that the main branch history look nice. If I work together with others on the same branch, then I avoid using rebase because it leads to conflict when pull. That can be deal with using git pull --rebase, but my coworkers usually dont know that.
@@truongpham1997 wait how does git pull --rebase work? i thought since it's a linear history it will just pull latest? i guess maybe with some merge conflicts
Rebase your own branches before pushing them, to keep them up to date without adding merge commits (which can cause you to track files that you didn't actually change, leading to confusing conflicts) Don't rebase when other people are also working on the same branch. If you use CI then you should never be too far from main/master/trunk anyway though. You can also set pull to rebase by default in your git config.
always rebase and do it often :D You really want linear history. For big teams and longer running branch you can get merge commit as big as rest if branch, making rest of branch irrelevant. Argument for always squashing everything into 1 commit or merging is just laziness in disguise: i dont want to go over all my commits again. You can have empty merge commit even with rebased branch before merging to master. (btw. the video is pretty basic stuff, i was really looking to learn simething new, but ...)
is there an option to join the members-only community? I am not seeing a join button on this video but would like to get early access to some of the videos you are posting here
I've used git submodules but didn't know about cherry pick. Its pretty useful. I used to do git rebase previously to resolve issues, now i have something better to use.
STASH is actually very useful. it allows you to try multiple ideas on a code section , then finally picking the one you have refined. dumping the rest. it's ideal for small changes...
I'm a principal engineer, and I've been using git professionally since 2010, and I know it pretty well. If you send me a PR with a crazy history that has 17 merges in it, I will not review it. rebase and squash is the golden workflow.
Having the same experience, I prefer to have full history. Merge commits are not a subject for review. Review whole PR and optionally separate meaningful commits. To rebase a published branch, is a peak stupidity. To squash a large PR destroy commit semantics.
@@vasiliigulevich9202 If you will call something that works well for another professional for a decade peak stupidity, then you do not have the experience you think you do.
I'm not 100% sure that cherry picked commits always get a new hash. The hash of a commit is deterministic and the parameters of the hash function, are the commit author, the commit date, the commit message, the content, and the parent commit. So if you cherry pick the first commit of a branch, and the other branch didn't have any new commits, the hash of the cherry picked commit should not change. Which makes sense since you would be looking at exactly the same work tree.
It will be different. When you cherry-pick a commit in Git, a new commit is created, even if the worktree (the actual files) remains the same. The hash of a commit in Git is derived from multiple pieces of information - some of which will always be different (e.g. the commit date and time - which is almost always different in a cherry-pick, and the parent commit hash - which is always different if you're cherry-picking into a branch with a different commit history). The parent commit hash will always be different unless the branch you're cherry-picking to happens to have the exact same commit graph up to that point (this is highly unlikely, especially in real-world scenarios where cherry-picking is used to apply changes across diverging branches).
Even if everything else (author, message, and content, etc.) remains identical, the parent commit hash + commit datetime are different; this results in a new commit hash. TL;DR: Cherry-picked commits always get a new hash.
@ I don't wanna be mean, but you didn't really read my comment 😅 The scenario I described would result in the cherry picked commit keeping the same parent (cherry pick the first commit of a new branch onto a branch that does not have any new commits). This keeps the parent hash the same, while commit author and datetime stay the same as well. There must be another parameter to calculate the hash that I must be forgetting about, though, because I just tested it and the hash does indeed change. So you are correct, but not for any reason that either of us are describing, so there's something here that both of us seem to not know about commit hashes 😂
@@Hedshodd Ah - I skimmed your comment. Did some digging into this. Commit hashes depend on more than just the above parameters. Even in your scenario, the hash changes because Git re-creates the tree object - which represents the file structure. There are some subtle differences in metadata (like how Git organizes the tree) and the committer field (which is updated during a cherry-pick). This will guarantee a new hash.
Surprised to not hear about git worktree. Discovering that was a game changer. Then abandoning it was another game changer. Git ls-files and git grep is another game changer.
I clicked on it thinking it's a fireship video 😂
Intentional I'm sure. But this video is good
Same 😅
Same LOL
Same here, 😂
Bro that is so wrong
`git stash` is always presented as a way to save work without creating a commit, but it also has another use, especially if you use git worktrees: store changes that you often do during development but then remove, for example turning on debug messages or always build something that is normally not built.
Great call-out : )
I used git patch apply and reverse patch apply for this purpose, but stash is a good idea, I'll try that instead
It's a good usage but imho if you end up needing these tools frequently and consistently, you should consider introducing them in your codebase (eg, set up a specific build task) so that you can also provide these capabilities to other developers
@@carmineingaldi47 In my case it's just a temporary activation or deactivation of what is built by Jenkins. It's already controlled by flags, so there is nothing to add, but the default values are not always suitable for what I'm working on.
You don't have to use clickbait like "don't rebase", your content is good quality as it is.
Git rebase has its purpose and nothing in this video talks about replacing that.
Working with submodules always sounds like a great idea but it never ends up being very convenient or beneficial in practice...
Bisect is the new one for me. Thanks
This was a perfect refresher, I used to use cherry-pick occasionally but totally forgot what the name was just remembered the functionality. Also I am a fan of stash save and stash pop in conjunction with the stuff you mentioned. The other commands were new to me and I love it.
Cheers 🥂!
Submodules are evil. I strongly recommend that you use a language specific build to maintain the dependencies. Cargo, Composer, NPM, or whatever, but using submodules is bound to cause issues.
my top two used commands:
git pull
git reset --hard
What's your top 10 git commands?
great video. I only heard of cherry pick in passing before, lots of good details in this one about sha-1, bisect, etc.
something i have used very very frequently.... when the circus comes to town...... sorry i mean outside programmers.
What a coincidence, i just searched and learnt to use cherry-pick today😅
Reset --hard is defintely not only for junior engs: if you like to make PoC of your changes before creating a real commit, you might want to mess up with your code from HEAD, reset, write good code based on informed decisions, commit and push
Finney enough I knew all of it before starting the video 😂
was really anticipating your next upload and you definitely delivered with this vid! been here since the beginning and I can tell ur starting to find a video style that works for u, it’s really great to see. regardless ur vids are always very informative
cant wait for the next vid
Thank you!
Don't keep your code in stash for too long
Stash is considered cache, it's very easy to mistakenly clear git cache
If it's not committed, it doesn't exist
First video of yours I ever saw. I knew most of these things, but it's a great video, and you just earned a new subscriber!🎉
Cheers 🥂!
Thanks, I learned git submodules, it's a new command, but I don't think that it is used often.
really solid video thank you for this one. how important is it to learn git?
i want to learn more about git reset --hard and things like detached head state or removing things that are untracked. i think i can do that with git clean but there are lots of other commands out there in the wild that I don't fully understand. how about a vid on breaking down the 10 hardest git commands or least misunderstood ones? i think this could brings lots of value
can you make a follow-up video on git rebase? i never really understood if it's something I should be using or not. some devs say things like oh you should never rebase because you are rewriting history and you can't see all the other branches and merge commits if you use something like --no-ff. so what is your opinion here should we even be rebasing at all or just skip straight to using merge. i guess there are some use case for rebase if you really want to get that linear commit history or if you have a bunch of weirdly worded commits and you want to squash it using an interactive rebase with git rebase -i and then s or squash the commits together?
I usually rebase my own branch onto main branch, so that the main branch history look nice. If I work together with others on the same branch, then I avoid using rebase because it leads to conflict when pull. That can be deal with using git pull --rebase, but my coworkers usually dont know that.
@@truongpham1997 wait how does git pull --rebase work? i thought since it's a linear history it will just pull latest? i guess maybe with some merge conflicts
Rebase your own branches before pushing them, to keep them up to date without adding merge commits (which can cause you to track files that you didn't actually change, leading to confusing conflicts)
Don't rebase when other people are also working on the same branch.
If you use CI then you should never be too far from main/master/trunk anyway though.
You can also set pull to rebase by default in your git config.
always rebase and do it often :D You really want linear history. For big teams and longer running branch you can get merge commit as big as rest if branch, making rest of branch irrelevant. Argument for always squashing everything into 1 commit or merging is just laziness in disguise: i dont want to go over all my commits again. You can have empty merge commit even with rebased branch before merging to master. (btw. the video is pretty basic stuff, i was really looking to learn simething new, but ...)
Didn't hear about submodule, heard about bisect but not had to use it, stash i use often
is there an option to join the members-only community? I am not seeing a join button on this video but would like to get early access to some of the videos you are posting here
00:30 the basicer basics that I use:
git update-ref
git write-tree
git hash-object
git cat-file
git send-pack
git show
Worktree tho
I've used git submodules but didn't know about cherry pick. Its pretty useful. I used to do git rebase previously to resolve issues, now i have something better to use.
Rebase and cherry-pick are both good, they are just used for different things.
Not sure about other things but cherry-pick is very good
STASH is actually very useful. it allows you to try multiple ideas on a code section , then finally picking the one you have refined. dumping the rest.
it's ideal for small changes...
I guess I’m a 10x engineer I use all these commands already. :p
What kind of clickbait is this? I was hoping to hear about rebasing. The content is good, but the thumbnail is irrelevant.
Good call-out, updated!
Heard about all of them, only used submodules.
1:01 guess what I know all of them and have used it
Feel kind of clickbaited by the thumbnail "don't rebase" which is not really the topic of this video
Literally why I clicked on this video
I'm a principal engineer, and I've been using git professionally since 2010, and I know it pretty well. If you send me a PR with a crazy history that has 17 merges in it, I will not review it. rebase and squash is the golden workflow.
Having the same experience, I prefer to have full history. Merge commits are not a subject for review. Review whole PR and optionally separate meaningful commits. To rebase a published branch, is a peak stupidity. To squash a large PR destroy commit semantics.
@@vasiliigulevich9202 If you will call something that works well for another professional for a decade peak stupidity, then you do not have the experience you think you do.
I'm not 100% sure that cherry picked commits always get a new hash. The hash of a commit is deterministic and the parameters of the hash function, are the commit author, the commit date, the commit message, the content, and the parent commit. So if you cherry pick the first commit of a branch, and the other branch didn't have any new commits, the hash of the cherry picked commit should not change. Which makes sense since you would be looking at exactly the same work tree.
It will be different. When you cherry-pick a commit in Git, a new commit is created, even if the worktree (the actual files) remains the same. The hash of a commit in Git is derived from multiple pieces of information - some of which will always be different (e.g. the commit date and time - which is almost always different in a cherry-pick, and the parent commit hash - which is always different if you're cherry-picking into a branch with a different commit history).
The parent commit hash will always be different unless the branch you're cherry-picking to happens to have the exact same commit graph up to that point (this is highly unlikely, especially in real-world scenarios where cherry-picking is used to apply changes across diverging branches).
Even if everything else (author, message, and content, etc.) remains identical, the parent commit hash + commit datetime are different; this results in a new commit hash. TL;DR: Cherry-picked commits always get a new hash.
@ I don't wanna be mean, but you didn't really read my comment 😅 The scenario I described would result in the cherry picked commit keeping the same parent (cherry pick the first commit of a new branch onto a branch that does not have any new commits). This keeps the parent hash the same, while commit author and datetime stay the same as well. There must be another parameter to calculate the hash that I must be forgetting about, though, because I just tested it and the hash does indeed change.
So you are correct, but not for any reason that either of us are describing, so there's something here that both of us seem to not know about commit hashes 😂
@@Hedshodd Ah - I skimmed your comment. Did some digging into this. Commit hashes depend on more than just the above parameters. Even in your scenario, the hash changes because Git re-creates the tree object - which represents the file structure. There are some subtle differences in metadata (like how Git organizes the tree) and the committer field (which is updated during a cherry-pick). This will guarantee a new hash.
@@TheCodingGopher Oh, that's interesting. Cool, thanks for looking that up!
Submodules are cool, but what about subtrees?
Submodules are like boats, you are happy the day acquire them and the day you get rid of them
It's fireship, but with a crap mic!
don't think i have used reset hard in over 5 years...
Man, I love/hate git.
where git rebase -i? this is superpower
Surprised to not hear about git worktree. Discovering that was a game changer. Then abandoning it was another game changer.
Git ls-files and git grep is another game changer.
10x? my dude those are mid engineer things
Cmon you are better than fireshipio
Fireship straight from Alibaba.
Submodules sucks. Just import artifacts you dofus
I became a 10x developer simply by coding instead of watching these kinds of clickbait videos.
10x Git users use LazyGit
Bro think he's fireship
👎 for clickbait
Homie wants to be fireship so bad 🤡
lazygit tui, written in go