40 minutes sounds like a long time, but it was all jam packed with legitimate information and no fluff. Great video. Watched the whole thing and didn't even notice the time.
This would have been an excellent 40 minute class in college. The knowledge is there in college, just spread out. this is clear and consise. Thanks for your work!
My compliments to the speaker. You are a very good teacher. Speaking in a relaxed way makes listening to you a huge pleasure in following your explanations. Top!!!
I consider myself as pretty profficiant with git, yet I'm doing this thing where i'm occasionally revisiting known technologies to maybe learn some new things. Anyhow, just I wanted to say that this 40-minutes long video was ALL WORTH IT just for the sake of learning about the git add with the -p flag to only mark some parts of a file to be included in the commit :) Love it! definitely gonna use it in the future♥ Thank you!
this is an introductory video, and "-p" flag is useless. As in the real work, most ppl uses temporary local branch with a logical name for each commit, thus no need to deal with staging or splitting commits especially in case of 50+ modified files.
@@s.i.m.c.a Plus, it doesn't work very well. Since posting this comment I tried using it, and man it sucks... sometimes it takes 2 or 3 rows and considers them as ONE CHANGE! Take it or leave it! When in fact each row is a chance on it's own, where I want only one of them. And yeah, the point you made is also valid. Haven't used it since. But it's nice to know all these "secret" git command. like git rerere for instance 😉
@@dannnsss8034 Your're not the only person out here. I've read the documentation for "git rerere" a dozen times and I'm still confused. I mean, I use git every day, and I think I'm proficient, but there are some very dark corners.
@@talkohavy Agree that git add - p not so useful, but just because it's command line interface makes harder to work out staging line by line instead of by blocks of code. Remember a lot of an optional "one letter" decisions in the interactive prompt? In this video the author just skips explanation of all options to just yES (accept incoming block of changes to stage) and nO (do not stage this whole block). The most IDEs (e. g. VS Code) gives you a useful interface to actually select which lines you would like to stage on commit. Of course sometimes happens that you needed to stage only partial change of the line, but that rare cases. In that situation you may modify line to one state, stage it and after that reimplement partial change that must be separated.
A very important consideration when you start spliting a file into multiple commits is to be very careful about not breaking or creating errors into one of the two generated commits, especially if a CI pipeline is using them.
First I'd like to thank you FCC and thank all your collaborators that bring content to us! I promise that I'll try to get as much experience as I can to get better and I will retribute all your efforts. Regards from Brazil!
I'd like to thank you for this video. English is not my native language & I'm a little bit rusty for now, but your spelling is clearly comprehensible. This is great, thanks. Besides this, your advice is a pure jewel. Thank you.
notes to self: only combine changes of a single topic in the same commit, git add -p enables staging parts of the changes of a file (patch level), of course, the file must already be tracked (using git add). merge: combining two different branches, it creates a merge commit in the process. with merge the two branches keep there own history seperated: b1-------- c1---------c2-----------------cm b2 |----c1-----c2--- c3 -------| rebase: rebase will unite the two commit histories of both branches, do not use rebase changes pushed to remote repo, rebase diagram: before rebase: b1: c1-------------c3------------ b2 |-------c2-----------c4----- after rebase: c1-----c2-----c4-----c3* notice that c3 is at the end, rebase moves commits that happened on b1 after the common ancestor, this means that c3 has changed (different parent)
Its been more than 2 years of development i didn't know there was a -p option in add command it could have helped me soo much in past but I am sure it will help me more in future thanks man!!
I can concentrate well while watch this video, and understood more quickly and deeply, because of your speaking speed that is more comfortable for me. Thanks a lot.
Good content. However, I think you missed one of the more common patterns involving rebase and merge. In your case of an LT branchA and work branchB with changes on both you rebased the changes in branchA on the changes in branchB. In my experience, it is more common to rebase the changes in branchB on the changes in branchA (checkout branchB, rebase branchA, , commit) then merge the resolved changes back into branchA (checkout branchA, merge branchB). That final merge MUST be a fast-forward. If it isn't, start over. This completely avoids the problem of rewriting history on branchA that you alluded to. Given branchA may be used as a base by other developers and could be hosted on a server that disallows history changes, that is essential.
Also even if you like to rebase an already pushed branch, you could do it safetely using the "git push --force-with-lease" and the "git pull --rebase" options, that will avoid you overwritten any changes made in the remote branch.
My Note: the arrow of every visualization means the old commit if exist Staging is important to differentiate some projects! 6:17 commit message should have subject and body. 8:30 conventional branches on team is important! IMPORTANT FOR ME: 24:33 Merge Conflict 27:55 undo a conflict and start over
Great video, However I see at time 34:44 (and many other times too), there are 2 arrows. One shows where branch is progressing. The other one points in other direction i.e. the directionwhere branch started(on c3 -> c2 -> c1). (the opposite arrow is orange in color) Why is one arrow opposite from other? Whats the purpose? Again thank you for the great content. Cleared up so many things for me
So I have learned a bit more about git, the arrows are a good tracking tool. So for example, say you make a commit, you can follow the arrows to see what past commits this new commit is built upon. Say you have a commit and you can trace all the arrows from that commit to any other commit, if you can cover all the paths following arrows, you can be sure that this new commit has all the previous commit history. The purpose of the arrow is to 1. Find parent commit 2. More generally follow commit path
Love this talk. Concise but clear explanations on some of the concepts that people misunderstand. Would love to see something similar about the basics e.g. how git work (local vs origin), how commits work etc.
the intricacies on how commits are created via globs gets very fine detailed, I would recommend reading Pro Git, unless you find some RUclips video that explains it, please do tell.
Very nice tutorial. I like the patch add. Yes, I like concise commits but sometimes I end up having to do parallel development so I am not ready to commit until I have too much to commit and files have pieces from more than one change.
finally i understood hunks. Thank you, you needed just 2 minutes to explain it :)
Год назад+2
Sometimes it is useful to realize that commits do not carry changes (i.e. diffs), rather they contain snapshots of the whole repository (though unchanged files are reused from previous versions).
For me the most important thing that belongs in a commit message is: Why this change. This should go in the subject not the What, because the What can be seen easily by looking at the changes. I think commit-messages as annotations to the changed lines, not describing the history of the project. So I write the messages for `git blame` and not for `git log`
Thank you so much, Guru Ji💖🙏, You are an amazing teacher! You taught us so much useful information in such a short period and made it a lot easier to understand. Thanks a lot for providing us free education. I'm the greatest fan of your work and knowledge. Keep it up! 🙌 This is one of my most favorite channels on RUclips 😍🥰
i worked with a cooworker that was stoling the branch commits that our team was doing just the purpose of getting more evaluation point at the company. I think he used a more complex approuch than "rebase" to do it, ecause he was replacing the commits author for himself. This cost his job, but it was a serious act. Hope to see a more indepth video to show how to detect and avoid this kind of situations.
@Dragon My apologies. English isn't my native language. "Stealing" is what i meant. And i didn't understand what do you mean by patriot. What this word have to do with my comment at all?
Very informative and comprehensive on the main topics we work with in Git. I just saved myself several google searches trying to understand the concepts. Thank you @freeCodeCamp!
ez thanks mate! proper, could of just added a git pull request, review, issues, commit merge reviewed cycle. apart from that, spectacular and some funny bits inbetween. Keep it up and thanks! Sometimes when I look at my commit history I want to rebase the whole thing, cleaning out the closet, now its perfecty clear on your own branch and not merged/pushed, its fine so your team does not send you a commit with a swear word in it. :D
Your voice was so relaxing it put me to sleep but when I woke up I knew how rebasing works, so thank you!
Lmao
😂
same here!
He sounds like christoph waltz. So soothing!
@@cokeantonio Came to the comments just to see if someone else was thinking it.
40 minutes sounds like a long time, but it was all jam packed with legitimate information and no fluff. Great video. Watched the whole thing and didn't even notice the time.
for me 40 min is when the guy is straight to the infos and not 5+ hours of beginner talk
Yeah! that to me as well wondering why could it be, maybe the timing and pacing of the video is just fenomenal.
Indeed it was quality time
1.25x speed is optimal
This would have been an excellent 40 minute class in college. The knowledge is there in college, just spread out. this is clear and consise. Thanks for your work!
Agreed
I closed my eyes for a moment there and I believe it was truly Christoph Waltz teaching me about Git.
I got that too. I was in the bar in Django Unchained, having a beer with Dr. King Schultz, having bounty hunting explained to me.
"You can live a happy Git life just using merge", I felt it!
as long as no conflicts are there
The way you narrated the whole concept is so awesome, everything got stick to the mind perfectly. Thanks for this beautiful content.
my thoughts exactly
My compliments to the speaker. You are a very good teacher. Speaking in a relaxed way makes listening to you a huge pleasure in following your explanations. Top!!!
I consider myself as pretty profficiant with git,
yet I'm doing this thing where i'm occasionally revisiting known technologies to maybe learn some new things.
Anyhow, just I wanted to say that this 40-minutes long video was ALL WORTH IT just for the sake of learning about the git add with the -p flag to only mark some parts of a file to be included in the commit :) Love it! definitely gonna use it in the future♥ Thank you!
this is an introductory video, and "-p" flag is useless. As in the real work, most ppl uses temporary local branch with a logical name for each commit, thus no need to deal with staging or splitting commits especially in case of 50+ modified files.
@@s.i.m.c.a Plus, it doesn't work very well. Since posting this comment I tried using it, and man it sucks... sometimes it takes 2 or 3 rows and considers them as ONE CHANGE! Take it or leave it! When in fact each row is a chance on it's own, where I want only one of them. And yeah, the point you made is also valid. Haven't used it since. But it's nice to know all these "secret" git command. like git rerere for instance 😉
Still so confused about rebase.
@@dannnsss8034 Your're not the only person out here. I've read the documentation for "git rerere" a dozen times and I'm still confused. I mean, I use git every day, and I think I'm proficient, but there are some very dark corners.
@@talkohavy Agree that git add - p not so useful, but just because it's command line interface makes harder to work out staging line by line instead of by blocks of code.
Remember a lot of an optional "one letter" decisions in the interactive prompt? In this video the author just skips explanation of all options to just yES (accept incoming block of changes to stage) and nO (do not stage this whole block).
The most IDEs (e. g. VS Code) gives you a useful interface to actually select which lines you would like to stage on commit. Of course sometimes happens that you needed to stage only partial change of the line, but that rare cases. In that situation you may modify line to one state, stage it and after that reimplement partial change that must be separated.
This is the best channel i would suggest every one if they are beginners
I just can't believe such great video is just free to everyone.
I wish I had such clarity of mind as the person explaining these concepts
I was not aware of the -p parameter who give me the ability to add only a specific part to the staging area.
+1
I had to cut, commit and then re-paste but now this powerful "-p" is awesome
I swear me neither.
really.. 😶
I usually do that kind of stuff in git gui.
Phenomenal video. These types of dev tutorials can be so dry but you made it highly visible and explained things simply and clearly. Thanks!
This video came just before our first group project for my uni course. Thanks!
Good luck man.
asmr is strong with this one
such a calming voice
The way you explain things is simply....awesome. Thanks !!!
Maybe the most useful (intermediate/advanced) video on git/Github I've seen so far
Man! your voice is soo soothing, whenever I get started watching this video, I fall asleep in 5 minutes.
A very important consideration when you start spliting a file into multiple commits is to be very careful about not breaking or creating errors into one of the two generated commits, especially if a CI pipeline is using them.
First I'd like to thank you FCC and thank all your collaborators that bring content to us! I promise that I'll try to get as much experience as I can to get better and I will retribute all your efforts.
Regards from Brazil!
I'm quite a big fan of "git add -i". This lets you do all the hunk-specific addition, while avoiding having to retype commands
I'd like to thank you for this video. English is not my native language & I'm a little bit rusty for now, but your spelling is clearly comprehensible. This is great, thanks.
Besides this, your advice is a pure jewel. Thank you.
Great lesson for most of new dev guy who need to use GIT here. Highly recommended :)
notes to self:
only combine changes of a single topic in the same commit,
git add -p enables staging parts of the changes of a file (patch level), of course, the file must already be tracked (using git add).
merge: combining two different branches, it creates a merge commit in the process. with merge the two branches keep there own history seperated:
b1-------- c1---------c2-----------------cm
b2 |----c1-----c2--- c3 -------|
rebase: rebase will unite the two commit histories of both branches, do not use rebase changes pushed to remote repo, rebase diagram:
before rebase:
b1: c1-------------c3------------
b2 |-------c2-----------c4-----
after rebase:
c1-----c2-----c4-----c3*
notice that c3 is at the end, rebase moves commits that happened on b1 after the common ancestor, this means that c3 has changed (different parent)
most valuable channel on yt for me rn ✨
thanks 🤧
Bravo! Not only the action steps to complete certain actions, but "why" and an explanation of what actually happens when you do! Nicely done.
working with git a lot these days and this is great. I have gotten more comfortable with rebase and merge requests
Its been more than 2 years of development i didn't know there was a -p option in add command it could have helped me soo much in past but I am sure it will help me more in future thanks man!!
This is an awesome intro on some intermediate git techniques. Looking forward to the Advacned Git tips and tricks!
+
Awesome tutorial. This man explained everything in a very Calm and awesome way. Loved It!!
this is outstanding quality. The pace and the tone might seem irrelevant but they really helps
Man I love these videos. I wish I had the time to watch the whole channel and visit every contributor. Much love
so SIMPLE explanation of REBASE. Thank you for that 🥰
I can concentrate well while watch this video, and understood more quickly and deeply, because of your speaking speed that is more comfortable for me. Thanks a lot.
I've just realized I didn't know Git at all lol. Thank so much for this.
Good content. However, I think you missed one of the more common patterns involving rebase and merge. In your case of an LT branchA and work branchB with changes on both you rebased the changes in branchA on the changes in branchB. In my experience, it is more common to rebase the changes in branchB on the changes in branchA (checkout branchB, rebase branchA, , commit) then merge the resolved changes back into branchA (checkout branchA, merge branchB). That final merge MUST be a fast-forward. If it isn't, start over. This completely avoids the problem of rewriting history on branchA that you alluded to. Given branchA may be used as a base by other developers and could be hosted on a server that disallows history changes, that is essential.
Also even if you like to rebase an already pushed branch, you could do it safetely using the "git push --force-with-lease" and the "git pull --rebase" options, that will avoid you overwritten any changes made in the remote branch.
What`s a branch?
@@wiurxee1993 What is `Re-base`?
@@markcuello5 branch is pointer to the recent commit
To update a branch we can pull master to that branch :
Git checkout b1
Gut pull origin master
I really enjoyed my experience watching this. Tobias teaches in a delightfully soothing way.
My Note:
the arrow of every visualization means the old commit if exist
Staging is important to differentiate some projects!
6:17 commit message should have subject and body.
8:30 conventional branches on team is important!
IMPORTANT FOR ME:
24:33 Merge Conflict
27:55 undo a conflict and start over
that's such a cool explanation of rebase. The visual helped a lot! Glad I stuck till the end
I'm glad you started with git add -p. I always teach that to folks when I can... it's so useful!
I’ve been working with GIT for a few years but never got deeper than basic concepts. The patching was neat and will come in handy.
What is `Patching`?
Very good content, learned a lot through this course, Just a tiny little request: can you please share the slides? So I can make notes more easily.
I was literally looking for these advanced concepts earlier this week! Thank you!
"You an always abort and try again" loved it, thanks!
Great video,
However I see at time 34:44 (and many other times too), there are 2 arrows. One shows where branch is progressing. The other one points in other direction i.e. the directionwhere branch started(on c3 -> c2 -> c1). (the opposite arrow is orange in color)
Why is one arrow opposite from other? Whats the purpose?
Again thank you for the great content. Cleared up so many things for me
I got confused by this too, the arrows seem to go in the wrong direction?
@@oliversmith7097 still waiting for an answer
So I have learned a bit more about git, the arrows are a good tracking tool. So for example, say you make a commit, you can follow the arrows to see what past commits this new commit is built upon.
Say you have a commit and you can trace all the arrows from that commit to any other commit, if you can cover all the paths following arrows, you can be sure that this new commit has all the previous commit history.
The purpose of the arrow is to
1. Find parent commit
2. More generally follow commit path
Tobias you have a fantastic speaking voice and presentation style. Really enjoyed this practical no bs review of how to use Git effectively,
For sure the best video I watched on git! Thank you so much.
one of best tutorials I found🔥
straightfoward to the necessary, i feel enlighted
Love this video especially the pace of the video so much!
One topic in and I knew this is premium stuff. Thank you for this!
La forma en que narraste todo el concepto es tan increíble que todo se quedó perfectamente en la mente.
Love this talk. Concise but clear explanations on some of the concepts that people misunderstand. Would love to see something similar about the basics e.g. how git work (local vs origin), how commits work etc.
the intricacies on how commits are created via globs gets very fine detailed, I would recommend reading Pro Git, unless you find some RUclips video that explains it, please do tell.
wow this was great. couldn't be better explained. for who wonders, time moves forward from left to right. I got confused initially.
I really enjoyed your talk. It really helped in understanding git in a more wholistic manner.
Very nice tutorial. I like the patch add. Yes, I like concise commits but sometimes I end up having to do parallel development so I am not ready to commit until I have too much to commit and files have pieces from more than one change.
finally i understood hunks. Thank you, you needed just 2 minutes to explain it :)
Sometimes it is useful to realize that commits do not carry changes (i.e. diffs), rather they contain snapshots of the whole repository (though unchanged files are reused from previous versions).
Excellent!! this video has helped me to finally undestand git commands easy explained. Thanks.
Thank you so much for this man. Your content is a better than a lot of paid courses out there !
Just wanted to thank you for the graph arrows going in two different directions
Rebase explanation - incredibly painful
great video, very clear and also with the right amount of valuable background information
Man. My boss just told me to learn git and then I saw notification for this video.
This video is awesome. I derespected Merge vs Rebase ! Thanks again!
This was very well done. I am sending it on to others. Best video for git at this level that I have seen.
Great video. Watched the whole thing and didn't even notice the time.
I didn't knew about rebase cons, thanks a lot for sharing this valuable info!
Very useful, thank you, Tobias!
6:16 One of the best line of this tutorial
Man you were so clear and to the point. Thanks for the tutorial it was very informative man.
Great video! Something which can be useful for finding files with merge conflict markers:
git diff -check
Very humble guy! 👍🏽
I like how you can link commit messages with the tasks, so you don’t need to make them meaningful after this, everything will be in task
Great Job! Now I am confident enough to manage any size code base. Thank You.
Very good, Thank's!!!
vey very precise and accurate for Git hub Learner
Awesome video.
Very impactful!
For me the most important thing that belongs in a commit message is: Why this change. This should go in the subject not the What, because the What can be seen easily by looking at the changes. I think commit-messages as annotations to the changed lines, not describing the history of the project. So I write the messages for `git blame` and not for `git log`
main and feature branches are all we ever need
I really appreciate this tutorial . It was worth it. Learned something new with excellent explanation
Awesome video. Please keep educating us. Thanks
The video on branching and now this video. Thank you so much for making these difficult concepts easy for me.
Found a proper professional for teaching all of us about GIT.
It's like listening to Christoph Waltz. Very slick
Thank you, this gave me a better idea on rebase.
Thank you so much, Guru Ji💖🙏, You are an amazing teacher! You taught us so much useful information in such a short period and made it a lot easier to understand. Thanks a lot for providing us free education. I'm the greatest fan of your work and knowledge. Keep it up! 🙌 This is one of my most favorite channels on RUclips 😍🥰
a very important video would love to see more like these and some advanced as well!!!
Fantastic video, nice explanations. Thank you. :)
i worked with a cooworker that was stoling the branch commits that our team was doing just the purpose of getting more evaluation point at the company. I think he used a more complex approuch than "rebase" to do it, ecause he was replacing the commits author for himself. This cost his job, but it was a serious act.
Hope to see a more indepth video to show how to detect and avoid this kind of situations.
@Dragon My apologies. English isn't my native language.
"Stealing" is what i meant.
And i didn't understand what do you mean by patriot. What this word have to do with my comment at all?
Great topics to talk about. Thanks!
WOW! I was just looking for this. Thanks y'all
The first few lines made me already confident
Thanks a bunch for this great tutorial. I have just learned many new thing by watching.
this video is truly amazing, thanks a lot
Very informative and comprehensive on the main topics we work with in Git. I just saved myself several google searches trying to understand the concepts. Thank you @freeCodeCamp!
ez thanks mate! proper, could of just added a git pull request, review, issues, commit merge reviewed cycle. apart from that, spectacular and some funny bits inbetween. Keep it up and thanks! Sometimes when I look at my commit history I want to rebase the whole thing, cleaning out the closet, now its perfecty clear on your own branch and not merged/pushed, its fine so your team does not send you a commit with a swear word in it. :D
Something so simple is so complicated and nerve racking
I was always writing a long commit msg but now I will be dividing it in subject and body thanks
Thank you FCC team! Great job again! 🖖
very great tutorial, solved many questions I had, which I never looked up in past...Thank you!