This is a great video for explaining the difference between merge and rebase. The only thing that seemed "weird" to me was rebasing feature branch on master. I like to use rebase to keep a feature branch up to par with master, but then use merge to move feature changes into master (once development is finished on the feature).
When Manu switched to master and typed "git rebase feature" what he actually did was literally as he would do "git merge feature" because he just pulled the commits from feature branch into the master branch. This is why it seems weird at first glance. Actually the examples Manu showed in this video are not likely to be used in real world because no one merges directly into their master branch but it was a really nice example of how these two commands work :) I don't know if you are familiar with interactive rebasing. If you are not google how "git rebase -i " command work :)
I'm totally with you on this one. Rebasing should *never* happen on common branches like `master` or `develop`. It should only happen on feature branches.
Yea, rebasing a feature branch with master is just a bad example. It looks straightforward here without a conflict, but it can be huge pain when such rebasing results in conflicts. Not to mention the effort it would take to undo a problematic rebase. I personally use merge commits for the same exact reason, that way I can easily revert to a good commit when things go south
Quick example: 0:30 In the project: 2:00 Merge a 'summarized' new feature: 4:25 git merge --squash branch-name : 5:50 Adding the new 'merge' commit: 6:30 Second way with rebase: 8:00 git rebase master: 9:20 Explanation: 10:25 Playlist: Git & GitHub - Managing Your Code: @
I’ve watched tons of git videos as I try to increase my understanding of keeping history clean when merging code. This is one of the best I’ve seen, hands down. The example was clear and you explained exactly what the different options would produce in terms of history/commits. Thank you, this is a huge help.
I’ve been trying to wrap my head around this git stuff for a month now and things like this have just alluded me. But this demonstration was perfectly and concisely clear. Thank you for opening my eyes.
Excellent. Best source (written or video) that I've ever come across that simply shows you how to use rebase to your advantage when working on a feature branch.
Abdelhak Marouane Almost... The golden rule is: Never rebase a public branch. So if your feature branch is shared... Don’t rebase that, either. (Can drop your teammate’s commits if they push while you are rebasing...) Use ‘- force-with-lease' for safety.
Also: Don’t rebase your feature branch if you’ve already merged master in. In that case, it can get very messy when you feature rebase + rebase PR merge... Rebase rewrites history, and now you might re-apply “new” commits that are actually an old state of master.
Good to know. So far I only used merge. So when I'm on a long-living feature branch I sometimes merged the master branch from time to time in, to get the latest updates and to make merging into the master easier later. Now I will use rebase for this
Best token of the year! #lzn #Luzionprotocol 🚀 Massive 383,125.80% APY. 💯 Fully Doxed Team and KYC. 🔥 2% Auto Black Hole (Actual dEAd address) 🟢 4%-5.3% BUSD. 🔒 Audited, Safe and Secure (ZERO Team Token).😎
I’m a rebaser and proud of it :) lol, I always work with private feature branches, either taken from master or from a public feature branch. My workflow is to then rebase from the source branch prior to merging (or creating a PR). This way I can validate that my code changes, through unit and integrations tests, work with the latest code. Not saying it’s the right way that’s just how I work, wanted to share! Happy merging!
This is a really good video because you slowed things down and thoroughly went through and explained stuff, repeating the key important points over and over. This is important information to understand basic of git. Thank you!
Worth mentioning that when doing 'git rebase master' while being in the feature branch, the original f1 commit was rewinded on top of the feature branch with a new commit id. Whereas when doing 'git rebase feature' while being in the feature branch, there was nothing really to be rewinded (there were no new commits on master) so master branch was just fast forwarded i.e. none of the commit ids changed. In short, When in feature branch with feature branch ahead, commits in master will have same ids, but feature commits will have new ids When in master branch with feature branch ahead, commits in master will have same ids, and it will same feature commit ids to master branch
I finally "got" it .. the very "fine detail" of how rebase works start at around 10:45 of this video. Using my own way of thinking: Whichever branch you are about to issue a rebase command against another branch, the steps are: 1) Git "rewinds" both branch "timelines" until it finds the common "denominator" ( ie: common commit both branches share). 2) Git then finds all the changes that happened in the current branch past the common "denominator" and puts them "aside" - let's call this "my current branch changes" .. 3) Git will then find the changes of the other branch that happened past the common "denominator" and puts them "aside" - let's call this "the other branch changes" .. 4) Git will now re-create a new branch timeline after the common "denominator" on the current active branch we issued the rebase command using the following "formula": "other branch changes" + "my current branch changes" and will add that timeline of events after the common "denominator" .. So the new branch timeline on the branch we issued the rebase command will be: .... "common denominator commit" + "commit changes of the other branch after the common denominator" + "commit changes of my current branch after the common denominator" While now all is "crystal clear" to grasp this concept, nevertheless it took my about two days of thinking and reasoning and replaying this video several times until I got it .. Thank you for providing this video.
Awesome! Super simple explanation for understanding 'squash' and 'rebase'. Also useful in avoiding merge commits (maintaining a clear/clean history) - just use 'git pull --rebase' before pushing all local commits to repository (since git pull is effectively just a git fetch followed by git merge).
Oh I finally understand why it's called rebase, because you are effectively changing the m2 commit feature is based off of to the m3 commit. You have effectively rebased it! thanks!
I was looking for a example video to share with some devs, and this is an example of a video that complicates something that is very easy. Basically "merge" keep the history of the branch untouched and "rebase" moves your code/code that is different between branches to the tip of the branch you are rebasing and insert newer/the difference of the code before, simple like this.
The pseudo-algorithm (at 10:25) for git rebase was a very good step-by-step guide showing what is going on under the hood while execution the rebase operation.
wow truly helpful in understanding the rebase command I would have used in last project but somehow not confident on how things would be, now all my doubts are cleared now. Thanks for the video.
Great tutorial. Never seen the squash command being used directly on master like that. I am used to doing an interactive rebase on the branch and squashing on the branch before merging with master Doing this flow with pull request would be nice to see. That is how we currently work at my job
oh! my! god! why didn't I get that before? I completely ignored rebase, never saw the interest in it... but the way you explained it, amazing! Also instant like on --squashed! thanks for this video, really!
Is it necessary to do the first rebase of the feature branch (adding the m3 to the feature branch) or can I just rebase in the master branch adding feauture to it (even if feauture stops at m2) ?
I felt the same, I'd prefer pictures and diagrams sticked around anyway and he was very clear with words anyway. Wrote down some notes for better understanding :D
Great demonstration! You are really good at explaining the concepts, similar to how Max does it. The individuals here asking for more pictures in my opinion need to work more with Git to better understand the basics. The explanations were really clear, and I only have around a year and a half experience. This is not easy stuff by any means, so if you're confused, just take a step back and practice adding, committing, branching, and merging some more.
I agree with you that doing your own examples will probably help you understand it better but I don't think that means the explanation was clear. If anything, I think the only thing the video did well was the naming convention for branches and commit messages for experimentation. That however means you understood it because you did it yourself not because the concept was clearly explained.
This was surprisingly clear. I think you did a terrific job of being very clear, with easy-to-understand examples. Also - kudos for using VS Code. I'm not much of a Microsoft fan, but VS Code rocks!
I think »git merge --squash« is named wrongly, as it doesn't create a merge commit. It is actually more like a »git cherry-pick --all --squash« (name invented). This video didn't explain what an actual merge is (other than saying "there is nothing wrong with it"). git merge --squash can have similar disadvantages as rebase when the branch you are "merging" was already public and used by someone else.
Not sure why you didn't make the terminal window taller, since the "code" window had at most 3 lines, and why you didn't use `--oneline' instead of scrolling to see the commits. I think it would have been easier to see the "whole" picture that way. Just my opinion, though. As for the explanation and examples, superb job! Thanks.
Thanks for the hints Fernando, I'll keep these in mind for upcoming videos! And of course thanks also for your great feedback, happy to read that you liked it :)
exactly my question as well! would the order still have been f2 -> f1 -> m3 -> m2 -> m1 or would it have been jumbled up based on the "time" at which each commit has been made (something like f2 -> m3 -> f1 -> m2 -> m1 )?
I like rebasing a lot, it really keeps the history clean. However I have a problem that I run into a lot, especially when using visual studio. If I git rebase master into my feature branch, sometimes there are conflicts. I prefer using a gui program like Visual Studio, but the terminology is always odd. "Incoming" and "current" are a little confusing when the master branch has a number of commits that you are introducing, and it seems like it interferes with every single commit. This isn't common but it does happen and it's a bit of a headache. Anyone recommend resources for better understanding rebase conflicts?
Note to self: Can first rebase in the feature branch to make sure it is compatible with the latest master, make a final commit on the feature branch detailing all changes summary and then merge squash on the master to only show the latest final feature commit. (to not over pollute with all individual feature commits).
i have a question. sometimes on feature branch, we have lots of commits. whenever we try to rebase, lots of conflicts occurs. whenever we try to solve this conflicts, it starts with first commit to solve. it is very complex process. how can we deal with it?
at 14:02 the same result can be achieved by doing a `git merge feature` right?
6 лет назад+17
Excellent explanation! Would be a good option to rebase the feature branch, and then checking out master and this time instead of rebasing master, merge feature in master?
I clean up my feature branches using interactive rebase and merge the feature branch back into development using git's default fast forward merging. This creates a very linear history which is how I like it.
This is an excellent explainer, thank you. And I know you were just using very simple examples, but nobody should rebase anything into `master` or any other common branches, ever! Rebasing should only happen in feature branches.
If the feature branch was created from the last commit they have in common (m2), then why does the m1 commit from the Master Branch show when viewing the commits from the Feature branch? Is it because all of the Master Branches history is viewable from Feature because Feature was created from Master? Thanks
I haven't worked on any public repository yet, but at my job i use "git rebase" when i want the updated code from master into my branch but i use "git merge" when i want to merge my features into master branch because i want to keep my branch clean.
This is a great video for explaining the difference between merge and rebase. The only thing that seemed "weird" to me was rebasing feature branch on master. I like to use rebase to keep a feature branch up to par with master, but then use merge to move feature changes into master (once development is finished on the feature).
When Manu switched to master and typed "git rebase feature" what he actually did was literally as he would do "git merge feature" because he just pulled the commits from feature branch into the master branch. This is why it seems weird at first glance. Actually the examples Manu showed in this video are not likely to be used in real world because no one merges directly into their master branch but it was a really nice example of how these two commands work :) I don't know if you are familiar with interactive rebasing. If you are not google how "git rebase -i " command work :)
I'm totally with you on this one. Rebasing should *never* happen on common branches like `master` or `develop`. It should only happen on feature branches.
Yea, rebasing a feature branch with master is just a bad example. It looks straightforward here without a conflict, but it can be huge pain when such rebasing results in conflicts. Not to mention the effort it would take to undo a problematic rebase. I personally use merge commits for the same exact reason, that way I can easily revert to a good commit when things go south
Quick example: 0:30
In the project: 2:00
Merge a 'summarized' new feature: 4:25
git merge --squash branch-name : 5:50
Adding the new 'merge' commit: 6:30
Second way with rebase: 8:00
git rebase master: 9:20
Explanation: 10:25
Playlist:
Git & GitHub - Managing Your Code:
@
Great comment
I’ve watched tons of git videos as I try to increase my understanding of keeping history clean when merging code. This is one of the best I’ve seen, hands down. The example was clear and you explained exactly what the different options would produce in terms of history/commits. Thank you, this is a huge help.
Thank you very much Mark!
x2. Ive been watching several videos on this and this one was the one that helped me get it. Thank you!
I’ve been trying to wrap my head around this git stuff for a month now and things like this have just alluded me. But this demonstration was perfectly and concisely clear. Thank you for opening my eyes.
Excellent. Best source (written or video) that I've ever come across that simply shows you how to use rebase to your advantage when working on a feature branch.
I think the golden rule is you should merge to master branch and rebase the feature branches
*rule ? :P
@@fexsort Corrected, thank you. :)
Abdelhak Marouane Almost... The golden rule is: Never rebase a public branch. So if your feature branch is shared... Don’t rebase that, either. (Can drop your teammate’s commits if they push while you are rebasing...) Use ‘- force-with-lease' for safety.
Also: Don’t rebase your feature branch if you’ve already merged master in. In that case, it can get very messy when you feature rebase + rebase PR merge... Rebase rewrites history, and now you might re-apply “new” commits that are actually an old state of master.
@@CourtneySchwartz I don't get this point. How does rebasing drop my teammate's commits ? Doesn't rebasing keep original commits ?
Good to know. So far I only used merge.
So when I'm on a long-living feature branch I sometimes merged the master branch from time to time in, to get the latest updates and to make merging into the master easier later. Now I will use rebase for this
Best token of the year! #lzn #Luzionprotocol
🚀 Massive 383,125.80% APY.
💯 Fully Doxed Team and KYC.
🔥 2% Auto Black Hole (Actual dEAd address)
🟢 4%-5.3% BUSD.
🔒 Audited, Safe and Secure (ZERO Team Token).😎
FINALLY someone explained it fully with examples and conflicts, rather than just reading out the commands
Today I learned about git merge --squash! Thank you!
Happy to read that Rafael :)
I’m a rebaser and proud of it :) lol, I always work with private feature branches, either taken from master or from a public feature branch. My workflow is to then rebase from the source branch prior to merging (or creating a PR). This way I can validate that my code changes, through unit and integrations tests, work with the latest code. Not saying it’s the right way that’s just how I work, wanted to share! Happy merging!
I'm not anti-rebasing or anything, but you can still validate your feature against the most recent code by doing a simple `git merge`.
This is a really good video because you slowed things down and thoroughly went through and explained stuff, repeating the key important points over and over. This is important information to understand basic of git. Thank you!
Worth mentioning that when doing 'git rebase master' while being in the feature branch, the original f1 commit was rewinded on top of the feature branch with a new commit id. Whereas when doing 'git rebase feature' while being in the feature branch, there was nothing really to be rewinded (there were no new commits on master) so master branch was just fast forwarded i.e. none of the commit ids changed.
In short,
When in feature branch with feature branch ahead, commits in master will have same ids, but feature commits will have new ids
When in master branch with feature branch ahead, commits in master will have same ids, and it will same feature commit ids to master branch
I finally "got" it .. the very "fine detail" of how rebase works start at around 10:45 of this video. Using my own way of thinking: Whichever branch you are about to issue a rebase command against another branch, the steps are:
1) Git "rewinds" both branch "timelines" until it finds the common "denominator" ( ie: common commit both branches share).
2) Git then finds all the changes that happened in the current branch past the common "denominator" and puts them "aside" - let's call this "my current branch changes" ..
3) Git will then find the changes of the other branch that happened past the common "denominator" and puts them "aside" - let's call this "the other branch changes" ..
4) Git will now re-create a new branch timeline after the common "denominator" on the current active branch we issued the rebase command using the following "formula":
"other branch changes" + "my current branch changes" and will add that timeline of events after the common "denominator" ..
So the new branch timeline on the branch we issued the rebase command will be:
.... "common denominator commit" + "commit changes of the other branch after the common denominator" + "commit changes of my current branch after the common denominator"
While now all is "crystal clear" to grasp this concept, nevertheless it took my about two days of thinking and reasoning and replaying this video several times until I got it .. Thank you for providing this video.
Thank you for this, i fing this explanation helps me to understand it a lot better
Awesome!
Super simple explanation for understanding 'squash' and 'rebase'.
Also useful in avoiding merge commits (maintaining a clear/clean history) - just use 'git pull --rebase' before pushing all local commits to repository (since git pull is effectively just a git fetch followed by git merge).
Oh I finally understand why it's called rebase, because you are effectively changing the m2 commit feature is based off of to the m3 commit. You have effectively rebased it! thanks!
It makes a lot of sense to see that you have 1M views after watching this video. This is exceptional .
I just left the video in the middle of it to say thanks so much for such a Crystal clear explaination
Glad it was helpful!
I felt like I just wanted to reach into the screen, go back in time and give this guy a great big hug 😁
Such a good explanation 👏🏾
I would be happier if this covered normal merge (with merge commit) versus rebase which usually brings more heated discussion.
I was looking for a example video to share with some devs, and this is an example of a video that complicates something that is very easy. Basically "merge" keep the history of the branch untouched and "rebase" moves your code/code that is different between branches to the tip of the branch you are rebasing and insert newer/the difference of the code before, simple like this.
Awesome explanation. As a beginner, i was struggling through it and now understood the concept of rebase just in 16 minutes
Could you please make another video when different developers touched the same file in different branches? For merging and rebase concepts. Thank you.
Simply the best explanation I saw for rebase and merge. Thank you so much!
Awesome explanation. As a beginner i was struggling through it and now understood the concept of rebase just in 16 minutes :)
The pseudo-algorithm (at 10:25) for git rebase was a very good step-by-step guide showing what is going on under the hood while execution the rebase operation.
this is one of the most clear explanations on the subject, thanks
The best `git rebase` explanation I've found so far!
Coming back to this video on a yearly basis since 2018
I am enlightened for life about merging the branches.
Excelent explanation. One of the few tutorials that actually made me get a little bit closer to understanding the difference between the two.
Glad it helped!
I'm at 2nd minute but already see that you explain everything very clearly!! Great & thanks for the video!!
wow truly helpful in understanding the rebase command I would have used in last project but somehow not confident on how things would be, now all my doubts are cleared now. Thanks for the video.
Now I understood the difference and fundamental logic behind it. Thanks for the video.
You just rebased my Git understanding. Thank you!
Straight Forward & deep dive explanation. Thanks for your effort.
Extremely helpful, I'll make sure to check out the rest of your videos
Great tutorial. Never seen the squash command being used directly on master like that. I am used to doing an interactive rebase on the branch and squashing on the branch before merging with master
Doing this flow with pull request would be nice to see. That is how we currently work at my job
Thanks! I readed other sources but didnt get it clear until now! thanks again!
oh! my! god! why didn't I get that before? I completely ignored rebase, never saw the interest in it... but the way you explained it, amazing! Also instant like on --squashed! thanks for this video, really!
Just found this video randomly. Very well explained. Thanks.
I subscribed you channel now😀.
Is it necessary to do the first rebase of the feature branch (adding the m3 to the feature branch) or can I just rebase in the master branch adding feauture to it (even if feauture stops at m2) ?
Clear explanation. If using `git log --oneline` to demo would be better.
Perfect demonstration, i have never understood this until now
Very nice. Teaching git is not only code but concepts as well . Thanks a lot !
My life is changed forever, thank you so much 😊
thanks for the really clear tutorial
pictures are worth a thousand words...... it starts well, then the diagrams disappear and there's only words
but words that make a lot of sense
I personaly mentaly quit when words coming to the party
@@rogeclash2631 show it with only diagrams would hve made a shorter video & would have been bringing more newbies
Well git is a cli utility, can't really bring the crayons for this one.
I felt the same, I'd prefer pictures and diagrams sticked around anyway and he was very clear with words anyway. Wrote down some notes for better understanding :D
Great demonstration! You are really good at explaining the concepts, similar to how Max does it. The individuals here asking for more pictures in my opinion need to work more with Git to better understand the basics. The explanations were really clear, and I only have around a year and a half experience. This is not easy stuff by any means, so if you're confused, just take a step back and practice adding, committing, branching, and merging some more.
I agree with you that doing your own examples will probably help you understand it better but I don't think that means the explanation was clear. If anything, I think the only thing the video did well was the naming convention for branches and commit messages for experimentation. That however means you understood it because you did it yourself not because the concept was clearly explained.
Tip: CMD+K clears the console in most apps, Terminal, VSCode, Webstorm, even Chrome DevTools!
Linux Terminal: Ctrl + L clears the console.
Great video! been trying to understand rebase and this was one of the most helpful explainations
8:02 someone needs to make a version control system for version control systems
git inception
git reflog, should cover the git actions history.
Just `cd .git && git init`
Awesome way of teaching🙌🙌
Excellent explanation using real time example. Thanks a lot for your effort to depict the exact git merge and rebase scenario. Loved it.
Thank YOU for your awesome feedback Thrihesh, happy to read that you liked the video!
I was deciding whether or not he had a german accent; but then he said "entwickelments" instead of developments and it all became clear to me.
Great video. Super clear explanation. Loved the idea of having the code and the commit being the same text, it makes everything so much clear.
Best explanation on reset and revert
Thank you sir this was very useful and I always wondered what the difference was between rebase and merge. Excellent explanation!!
Best Video I have seen on Git Merge Vs Rebase!!!
This was surprisingly clear. I think you did a terrific job of being very clear, with easy-to-understand examples. Also - kudos for using VS Code. I'm not much of a Microsoft fan, but VS Code rocks!
Thanks a lot Greg!
Clear video with exact points
Very helpful
I think »git merge --squash« is named wrongly, as it doesn't create a merge commit. It is actually more like a »git cherry-pick --all --squash« (name invented).
This video didn't explain what an actual merge is (other than saying "there is nothing wrong with it").
git merge --squash can have similar disadvantages as rebase when the branch you are "merging" was already public and used by someone else.
Very good video, keep up the good work. Just subscribed - thanks
This is a very challenging subject to explain with words, and you did a great job.
Thank you Aaron :)
Great Video !! Explanation was very clear and easy to understand.
Great video and the way you have explained this topic is best! i want more videos on Git thanks
Thanks for clarifying this concept 👍
WTF, it's like watching Max in someone else's body!
True
Is this deepfake?! :D
All germans are just part of the same entity. The Reich Borg.
Exactly, sounds like his younger brother. :D
LOL i had to seach the comments to find the answer so this guy he is not max LOL i was so confused
Not sure why you didn't make the terminal window taller, since the "code" window had at most 3 lines, and why you didn't use `--oneline' instead of scrolling to see the commits. I think it would have been easier to see the "whole" picture that way. Just my opinion, though.
As for the explanation and examples, superb job! Thanks.
Thanks for the hints Fernando, I'll keep these in mind for upcoming videos! And of course thanks also for your great feedback, happy to read that you liked it :)
@@academind just use the alias mentioned here: stackoverflow.com/a/9074343/2570622
Thanks for taking the time. Great explanation!
Great explanation Manu!
How would the example differ if instead, you didn't squash the merge?
exactly my question as well! would the order still have been f2 -> f1 -> m3 -> m2 -> m1 or would it have been jumbled up based on the "time" at which each commit has been made (something like f2 -> m3 -> f1 -> m2 -> m1 )?
Here is a StackOverflow answer for this:
stackoverflow.com/questions/2427238/in-git-what-is-the-difference-between-merge-squash-and-rebase
I can't thank you enough for this. Cheers for great video!
I like rebasing a lot, it really keeps the history clean. However I have a problem that I run into a lot, especially when using visual studio. If I git rebase master into my feature branch, sometimes there are conflicts. I prefer using a gui program like Visual Studio, but the terminology is always odd. "Incoming" and "current" are a little confusing when the master branch has a number of commits that you are introducing, and it seems like it interferes with every single commit. This isn't common but it does happen and it's a bit of a headache. Anyone recommend resources for better understanding rebase conflicts?
Great explanation of the rebase, thank you.
Note to self: Can first rebase in the feature branch to make sure it is compatible with the latest master, make a final commit on the feature branch detailing all changes summary and then merge squash on the master to only show the latest final feature commit. (to not over pollute with all individual feature commits).
i guess Max and You were brothers. Best Explanation :). thank u so much !!!
We are indeed close friends, happy to read that you like the video :)
Extremely clear explanation
Thank you Tom!
Awesome, Very well organised and explained, Thank you so much!
Amazing explanation very clearly understood
Very well explained. Thanks!
very beautifully explained. thank you
What does rebase do? How does it work? 10:25 - Great explanation
Thanks Manuel, well explained!
i have a question. sometimes on feature branch, we have lots of commits. whenever we try to rebase, lots of conflicts occurs. whenever we try to solve this conflicts, it starts with first commit to solve.
it is very complex process.
how can we deal with it?
Awesome explanation. THANK YOU.
Many thanks for the tutorial. This helps me a lot in understanding merge vs rebase.
Thank you for the great explanation.
Thank you for explaining clearly
Great explanation very easy to understand
m2 and m3 commit as per your example project will happen in remote master, how this will be see in local master branch?
at 14:02 the same result can be achieved by doing a `git merge feature` right?
Excellent explanation!
Would be a good option to rebase the feature branch, and then checking out master and this time instead of rebasing master, merge feature in master?
I was wondering the same thing.
Pedro, you can read this nice article which explains underwater rocks of this approach goo.gl/XPmzBk
Whats the difference?
I clean up my feature branches using interactive rebase and merge the feature branch back into development using git's default fast forward merging. This creates a very linear history which is how I like it.
This is an excellent explainer, thank you. And I know you were just using very simple examples, but nobody should rebase anything into `master` or any other common branches, ever! Rebasing should only happen in feature branches.
Thanks for the easy explanation and demo.
If the feature branch was created from the last commit they have in common (m2), then why does the m1 commit from the Master Branch show when viewing the commits from the Feature branch? Is it because all of the Master Branches history is viewable from Feature because Feature was created from Master? Thanks
In 3:11, you typed the command: git master and then it switched to master. Can you explain that command? I am not able to do that.
Very nicely explained. Thanks for the good knowledge sharing
Thank you. Perfect tutorial!
Detailed and clear. Thanks!
I haven't worked on any public repository yet, but at my job i use "git rebase" when i want the updated code from master into my branch but i use "git merge" when i want to merge my features into master branch because i want to keep my branch clean.