A few details that were mentioned in the comments (Thanks!): Of course git pull is (by default) just a fetch + merge, but I left out that detail for the sake of brevity. I'd like to explain this a bit better in a future video. Also, if you're _sure_ that nobody else is using the branch you're pulling from, it's definitely fine to pull! So the advice from this video doesn't always apply if you're using feature branches that only one dev is working on, or if you're squashing on merge. I've just seen a lot of teams that use different branching strategies (or don't have one in place at all). But it also doesn't really hurt in that case, since doing `git pull --rebase` will just do a regular pull then. A common question was: *Why should you abort the rebase?* If you already know how to fix merge conflicts during an interactive rebase, by all means, go ahead! You don't _need to_ abort, just fix the conflict. That's even better than aborting and merging. I just thought it would be a bit overwhelming for this video to _also_ explain interactive rebasing and fixing merge conflicts. I do have videos planned on resolving merge conflicts and interactive rebasing, stay tuned! One more thing people mentioned is that you can configure git pull so that it will _always_ rebase by default. I was a bit wary of recommending this to people, since it changes the default behavior of a pretty common command, which might cause confusion (especially if you forget about it a few months later). If you want to make pull rebase the default, run `git config --global pull.rebase true`. From then on, `git pull` will rebase, and `git pull --merge` will merge. In newer versions of git, it will even ask you upon first use which pull strategy you prefer. Also, this video really blew up beyond my wildest imaginations! Thank you all for your support and nice comments! Next video is in the works and will be released on Monday. If you enjoyed this one, please consider subscribing to not miss it.
It's a good intro video. But most public OSS repositories, and virtually every project I've ever worked on in company settings, require PRs before merging (or rebasing) onto main. Here, you assume people work directly on the main branch and commit to it. I'd strongly advise against that as soon as you work on something with more than one person. Furthermore, PRs give you the added benefit of reviews, discussions, and documenting your change.
@@Misteribel I think I probably should've clarified in the video better that it doesn't have to be the main branch, but it could be any branch. Of course if you use feature branches that are exclusive to a single person, that shouldn't happen, but I've seen a lot of teams where that isn't the case, where branches are shared.
I really like the brief video + the explanations in the comment. This could become a concept for your channel: A brief video with an overview plus FAQ/more details in the video description or comments.
It's not huge deal but I often don't see why some developers want a clean hist. Not like your viewing it for fun. You only look at it when there is an issue. Having the full history as it was is no big deal may also shed light on why something went wrong on post mordum. Now if you are suggesting to do this on your private branch I absolutely don't mind developers using this approach. On shared branc0hes I think it is best to leave hist as is. 🥂
for the love of jesus. nO!!! for every new feature, every new commit, make a branch, then push that branch and work on it until you have the code you require, then push
John was on my lawn as well, mowing over my work and trying to break my branch. I quickly stashed my mower in the shed, took his work and popped my mower back out and merged our lawn work. Pushed all the good work back onto the branches landscape. Alls good John.
This process is so much simpler and cleaner if you work from your own branch and use PRs. In that case, you can just rebase the PR onto main after it's reviewed. Or, if there are conflicts, use `git rebase main` locally first.
Yeah most teams will be working on feature branches, what I do depending on how long I'm working on a branch is either rebase every morning to keep my branch up to date with the main branch (or sprint branch in our case) or just do a rebase before I open a PR back to the main branch.
@@wombll Our developers do no have commit rights on the feature branches, these are locked. Developer create their own branch (based on a feature branch), make their changes and than create a PR. The PR is merged into the feature branch. Every feature branch has a maintainer who is responsible for the branch. It is the feature branch that after reaching a milestone is merged to a release branch, but usually a release consists of multiple feature branch merges. Our developers perform a single rebase just before they create the PR. In the past we have lost too much time after daily rebase operations, not to mention that you can pull in changes you were not prepared for or contain bugs...
@@ruanpingshan well for sure, if you squash them, the commits will be merged into one, so you will lose history. As a consequence, if you have a feature branch and you would continue on it after merging it into main, you have to rebase it with main first to avoid merge conflicts.
I think the problem starts at step 0, where you and John are both working on the main branch. Ideally you'd have two separate feature branches, that would be merged to main when they are finished
@@sauliustb : Which is why trunk-based development has always seemed rather weird to me. Why use a workflow where you have to come up with weird workarounds for doing this without branches, when doing this is exactly what branches are for?
@ChristianConrad because any company I've worked in that used feature branching had issues with merge/rebase, or with long-living branches that were hard to integrate when it was allowed. Trunk based makes small, production-safe commits, which reduces the chances of conflicts, as well as ensuring rigorous testing. All work must stop if branch on origin is red in the CI/CD tool(though it shouldn't ever be red...)
Unfortunately, in the real world, someone might decide they want to push code in your branch. Such people need to stay away from computers, but HRs don't allow criticism or other "offensive" behavior these days
Great first video! Short and informative and the graphics help for those of us that are differently-abled in the mental department. Much appreciated! :D
If you want to always use pull with rebase, you can configure `pull.rebase` to true to have it as the default behavior when running `git pull`. Then you can resolve conflicts and continue with the rebase with `git rebase --continue`. As a bonus, you can avoid repeated conflicts by configuring `rerere.enabled` to true, which will Reuse Recorded Resolutions from that point on.
i was going to say "wait but what if we are all making huge amount of changes to the same files so theres tons of merge conflicts" and then he explained that in that case, yeah, we are supposed to use normal git pull.
Hah! gotcha ;) Jokes aside, you can also just fix the conflict in the interactive rebase then (see my pinned comment for more details). Video on that is in the works!
@@noomadeno not really. If master has some PRs merged into it then you will likely get a conflict if a separate feature touched some overlapping files or types.
If lots of people are doing huge amounts of changes to the same files, then something is wrong, I.e., long lived branches, lack of communication, too much in a file, ...
@@michaelkhalsa i maintain some soft forks which is when i edit a lot of things in a repository but my changes are not useful for anyone upstream because they are only needed for users of my builds. one example is, there is Super Mario 64 multiplayer for Windows, sm64ex-coop, and I create and release versions of it that work on Android and can cross play with the PC version. so i have to make a lot of small android specific changes throughout the repository that the maintainers of the Windows version don't want to have to worry about or get confused by.
@@michaelkhalsa Agreed. If the coworkers in this situation aren't working on the same files then there is no reason for them to be on the same branch. If they're working on the same files and tripping over each other, then they should probably just be pairing.
3:49 an alias is not needed for ‘git merge -rebase’. Just set the global config ‘pull.rebase’ to true with the command: ‘git config --global pull.rebase true’
Ok cool! Just to clarify, have you ever done an interactive rebase before? Have you fixed merge conflicts before? If yes, what were difficult bits? Just want to make sure I focus on the right things :)
@@philomatics i’ve not done an interactive rebase. i’ve edited files to fix merge conflicts before a few times but it’s been a while. i feel like when i do like. git pull and get the merge conflict error im rarely motivated enough to deal with it the way im supposed to. im also pretty confounded by the fast forward / no fast forward / rebase thing.
Sometimes conflicts are inevitable, but having a clean git history and having all the people working on a project try to also interactive rebase their own branches as they develop to keep their own commits self-contained and clean helps prevent a ton of a crazy amount of conflict. I end up using rebase in some form at least a handful of times a day, and It's one of my favourite git commands. Beign really good at interactive rebasing will save you a ton of time and headache in the future, but it was also very confusing for me to learn at first.
Your way you presented it was brilliant. I've always used it, but only because I was told to, but I could never figure out how it worked and the conflicts involved. Thanks! Really cool, well-paced explanation
I just want to say that videos like these are super helpful and I would love a video on git rebase interactive. I'm in school right now and I was joking with classmates about how every class is making us use git now (great!), but the only teach us add/pull/status/commit, and they just repeat that over and over. They don't even bother going into any detail on the ones they do bother to teach us either. It's very clearly a required part of the curriculum but it's always an afterthought, not a core part of any of our classes.
@@philomatics I think personally, my biggest hurdle is making sure I know how to resolve conflicts without mangling whatever repo I'm dealing with. With rebase interactive, what happens when I select my code over the other persons code, does it show up as a line deletion in the new commit? I've done solo projects and it's easy to be lazy, or build bad habits. I'm concerned that I won't be familiar enough with git when it comes to multi-person projects. Working with remote repos as well. I recently started a project for a class, and I initially suggested a main branch, dev branch, and then we would each have our own dev branch, then we would work on our local personal dev branches. My classmate suggested we just use dev, and I realized that as long as we're careful about pushing to dev I didn't really have a good case for one or the other. In that sense I'd like content geared towards the why things are done the way they are. Why is using main/master branch bad, why dev branches, feature branches, personal branches, and what kinds of problems arise when you don't use them. That way I'm able to have a more informed discussion when negotiating how me and my project partners should handle git/hub. Another subject is forking on something like github (I know github is not git, but I thought I'd bring it up anyway). In the example I give above, I hosted the project on my github account. Because of that I have direct access to the dev branch. If I push from my local dev branch, it goes straight to the shared dev branch. My partner on the other hand has direct access via permissions. I considered having him fork it, but then I realized it would create asymmetric contributions (since I have direct access). I see a lot of Open Source or public projects tell people to fork the project first. In my case it's a school project, so it's not a huge deal. My question is: In industry do people fork repos, or do they have permission to push directly? It seems a lot of businesses have a "business" github account, and then all employees/contributors have individual accounts that fork/branch out of that, so there is always at least one layer of indirection. Is that for internal projects or just Open Source? Not really about git, but definitely something where I'm not sure what the best practice is. I imagine understanding something like this from the get-go would be important during hiring. I really like that this video goes over what the resulting tree looks like, it helps understand why rebase is better and not just that it is better. I've heard that rebase is better before, but I never knew why, or in this case, what makes pull worse. This video is great and I look forward to more content like this, even if it's not specifically the stuff I said above!
Really appreciate the whole explaining-through-visualisation approach. It's easy for me to understand that way. Looking forward to learning more from your channel.
I've had to search for something in git history once, perhaps twice, in my entire 20 year career. Teams of mostly 10 to 20 people. To me, personally, the ease of just fixing the conflict and merge-commiting is just easier. Not only that, but the history will actually be more accurate. The misconception is that rebasing is more accurate. It's not. Rebasing is rewriting history, for a bug or issue you might or might not have to search the history for at some point.
Same, but people as always have preferences. I for one don't mind having merge commits but some people feel that it pollutes the history... Like who is going to look At it? The only thing I think of is phpstorm select code and show history for selection
I don't think merge messes up git history but you don't use git blame? I think I use it a few times a day to figure out who I need to talk to or when something was added / how it fits into the timeline and on some occasions you will even be working with someone smart who leaves good commit messages that explain their reasoning or why a piece of code resolves some edgecase (or at least you can find the pr from that commit that does). It's a very important tool IMO or else we'd just flatten the commit history every few months to make pulls faster.
I search git history all the time, and that's why I'd rather have git history reflect what actually happened - ie not people rebasing to make the repo "clean".
I've seen effectively this exact same video by a dozen people at this point and don't understand. This is pointless OCD that maybe makes things look cleaner, but it is just worse. Waiting for tomorrow for the next vid from Jr Dev 37482929383 that learns about rebase.
I really hope you will continue with your channel, I've watched many videos on git and this one was one of the best (and it's just 4 minutes, can't even imagine if you'll do a 15-20 minutes+ video)
I've not used the "git pull" command since 2010. For a brief time, I configured repositories to make "git pull" do rebase instead of merge. That was tedious and prone to forgetting. Then I realized the fix is to stop using this stupid "pull" thing, and just do it in two commands. I don't want to fetch objects *and* muck with the local branch in a single command. First, git fetch. Then, see what you are getting into: git checkout (tells you by how many commits you and upstream are diverging). You may want to do a git log on the upstream branch to go into details, e.g. git log -p origin/master to see what has been happening: do you really want to rebase on top of all that now? And on top of all of it? Maybe there are certain older commits you want to pick up now, but avoid (for the time being) a breaking commit that will disturb your work.
Sane advice. For me there sre two global configs that helps immensely. Always do rebase instead of merge, and if there's any conflicts you can solve them and do a manual merge commit. git config --global pull.rebase true And it's always good to fetch before pulling, so a nice tree of commits helps you to quickly see the full picture. git config --global alias.tree "log --all --decorate --oneline --graph" Of course in some cases you might want to diff here and there, cherry pick something, or only rebase partially, but those are not everyday scenarios
Yup, fetch, then check what changed and decide on a case by case basis if you want to merge or rebase depending on what's happened and what will make the best history. Only thing to watch for is if you plan to rebase the history onto the latest main, or submit the changes as a sequence of independent patches. Then merges can be a bit annoying as they make rebasing, or reapplying the patches to a different branch awkward.
I still use git pull when returning to a project that others have committed to, otherwise fetch + rebase all the way. It's a nice and fast "catch me up" command
Your Video & Audio is clear and so good for a first youtube video. Content about Git also presented in a lucid way to understand. I saw your video today only. Eager to watch more videos and learn from your channel. Good Work 👍
Nothing wrong with git pull in the example you've made. In all projects I've worked on we usually followed the rule of using squash before merging any pull requests. This way it doesn't matter what kind of git history in your branch you have, it all gets squashed to a single commit and the git history of the main branch stays very clean, so you can just merge which usually way easier if you have to deal with conflicts compared to rebase (even if you use -rerere). I still use rebase from time to time but using it often gives me headache
I agree. I do think rebase keeps the history cleaner but my team basically never looks at or cares about the git history quality and it was not worth the hassle of the trickier merge conflicts when we tried to ditch merge commits.
Came here looking for this comment, I’ve converted several teams to this model too! Squash and merge prs is easy to understand and gets you a nice clean history on the main branch
@@SourceOfViews I mean, all of the I information I usually need is in PR: typically there is much more than the commit message. When you squash and merge you automatically leave the PR number so you can easily find what you're looking for. Also most commits aren't really useful on its own: "fix: lint" wouldn't probably help you to determine why this line has been changed in the first place. But whatever works for you honestly, I'm just saying my experience
These animations are *really* good, but it's also definitely good advice. I've been anti-merge-commits for a while, it's cool to see other people spreading the word! :)
I follow these 1. git fetch --prune to clean the tree of remote history , It also shows how much the remote is ahead of your local repo 2. git pull --rebase, rectify the merge conflits. 3. git push
Get out of my effing REPO! hehehe ,... This is a different approach to the problem;P (Like if people cannot talk anymore ... with each other. Holy Crypto-Bro F )
Wow! Your content is pure gold. I wish I had discovered ur channel before working with git. Ur channel should shine with elaborative explanation, especially the gorgeous animation!
In most cases you will be working on different branches/PR and the main branch is usually locked from direct push. When finishing the PR most hosts offer "squash merge" that no matter how many commits in your PR, there will be one commit in master after merging.
@@martynasbaltutis6916 unless they work on a small project, local utilities etc where there doesn't seams like the need for the extra work with PR. But of course, for larger serious projects you lock the main branch and use PR to merge to main. And for noobs like me 🙂this is great information (or when I am called in to save some ones screw ups in a git repository 🙂)
I've been using git ever since I was in 2nd year of college, it's been ~3years. I never knew we could do `git pull --rebase`. It's really clean as you mentioned!
Or just update you ~/.gitconfig to add: [pull] rebase = true To make sure you always get rebase. After this (when it 'fails') you can fix the challenges using "git mergetool". (Yes, brace yourself: it's often a UI)
Great editing. Best rebase explanation i found so far. Though I personally really abort at the first sign of a conflict and just pull regulary. I think you can make a strong point for NEVER rebasing. It just beautifies the git history, which is mostly a pointless artifact - all you are interested in 99% of cases are the results (e.g. your branches). The big upside is that no one can fuck it up. Seems like every other project someone actually rebases the wrong thing and creates some sort of mess that takes hours of developer time to resolve. If you have 100% confidence in all developers: go for it. If not: regular merges can make your lives so much easier
I never find it a good idea when two people work on the same branch in the first place. Every once in a while you should always pull in the latest main and then rebase your branch with it. This will make sure your branch keeps staying mergeable with the current main.
But sometimes you need to, usually helping someone fix an issue they couldn't on their own or dividing UI changes and business logic on a larger feature
@@gasparsigma I dont mind helping someone with ideas or reviewing their code suggesting changes here and there. But, that shouldnt require me to directly push sth on their branch. That’s too invasive for me. For the other case, it really gets down to how well you plan and size your tickets.
I don’t think its a issue with working on the same branch, eg john creates his own branch from main for his feature development and you created your own branch from main for your feature development and John finishes first and gets his feature merged, you will end up in the same situation.
@@tomiyokasensei not really. Since, john got his feature merged in main and considering main is the source of truth, its your responsibility to pull the latest main and rebase your branch with it. The idea is to consistently keep your branch mergeable with the source of truth (e.g main)
Wait until you read about trunk based development. Everybody pushing to main. And honestly much happier. Once you manage to work like this you never go back
Great video. Tip for another video: 'git rebase --interactive' - a command too few know about and use but that is super useful to handle tricky merges or just when you want to rearrange your own commits before pushing. In general great that more people try to describe and teach the concepts behind Git to make it easier for those not as experienced to understand what the different commands actually do and why they exist.
Why do you recommend running "git rebase --abort" and merging normally on conflict instead of proceeding with the rebase and resolving conflicts there? Does it have something to do with the apply backend that git rebase uses by default? Also great video btw, it's nice to see such high quality dev content on RUclips.
That's a great question! I actually do recommend proceeding with the rebase if you already know how - I just thought that also explaining rebasing _and_ resolving conflicts during rebase would've been a bit overwhelming for this video. I might do a video on rebasing in the future though. Thanks for the nice feedback, made my day :)
3:02 even when there are conflicts you should ‘rebase -pull’. You have to resolve the conflicts anyways, the only difference is you may get conflicts for each commit in your branch as each gets re-applied, but that’s also what rerere is for. This is also why we should prefer smaller changes/features and merge back to develop often.
What an amazing video, i knew about the --rebase argument but had no idea of what it did, thanks! it's also so cool to see small programming youtubers rising!
Perfect! git pull in this situation does introduce bad history. I would just do a git rebase, resolve all the conflicts, --continue, and then push.. Git rebase is better than pull in this sort of situation.
Really good intro, straight to the meat! I am leaving a comment here so that we can expand our knowledge in the world of development and operations. Good job!
Generally I agree. Couldn't this problem happen with a feature branch workflow as well? For example when multiple people are working simultaneously on the same feature branch?
@@philomatics , yes. But it won't matter because even if there are tons of merge commits on the feature branch they are all squashed into one when it is merged to the main branch.
@@gigantedocil That's a good point. I guess in the end it depends on how long the feature branch lives and how many people are working on it simultaneously. I'm honestly a bit on the fence about feature branches in general. Maybe I'll make a video on branching strategies in the future (also for my own sanity ;))
@@gigantedocil but branch history is not preserved which really sucks if you're adding major features or refactors, unless your feature branches are very small and short lived, you should likely still be rebasing and preserving history
Because this is your first video, and because this is my first time watching one of your videos, and because you provide great value, you won my subscription right from the start! 😊
@@abdullahX001--ff-only only applies changes if they're fast-forwar; ie they can cleanly merge your local work with the remote if it wouldn't cause any conflicts. You might see the words "can be fast-forward" in git status or other places in the git CLI. My workflow is to always start with git pull --ff-only, and if it fails, I'll check out why the branches are different.
This kind of videos, specifically ones about git just helps me realize again and again how complex of a software git is. Like how did people even come up with all these features, how they know that exactly THAT was needed. This blows my mind. And the fact that the whole thing was written in C is just another level.
god damn it. I thought you are a pro on video making until you say this is your first one. Your explanation is clean and concise. And short. Please make more video on git like this one.
You can configure your Git to do rebase instead of merge during the simple 'git pull' command and use this without making any alias. git config --global pull.rebase true The 'git pull' command is just a shorter command that does two other commands: 'git fetch' and then either 'git merge' or 'git rebase'. So the ultimate option is running them separately by you and not by the 'git pull' command.
Was initially going to comment "you're crazy" then I realized this video is about the exact workflow I use. `git pull --rebase origin main` is your best friend :)
For a first RUclips video, it's very well done. You're a good teacher. It was very useful, thanks. I argue with my team that only pulling creates a bunch of garbage that makes it hard for investigating when needs be. Now I have the perfect video to show them. Subscribe
I will say that some projects prefer `rebase`, actually the majority of projects that I worked on. From that perspective, I will say that your video is highly opinionated, provides no real justification, and eludes an important point. REBASING IS ALWAYS DESTRUCTIVE. It is impossible to reconstruct the work that you and your colleague had been working on, post-factum, and if the merge conflicts are resolved incorrectly (much more likely given that a rebase has to resolve conflicts for each commit) good luck trying to get anything to work. The only thing that you do avoid is ... for lack of a better word... useless merge commits. But it is a well-known fact, that you can make useful merge commits, and Linus has made a great point of demanding good merge commit messages. Don't mean to sound rude, but this guidance is at best of modest educational value.
What part of messing up your commit history did you not understand? Also, if you have multiple commits on the same lines of code, you're committing incorrectly. It's really a PITA code reviewing from people who do that. Plus it tends to not convey what the commit is doing
Very much in agreement. A "clean history" is more or less just a personal preference. I don't see a history with merge commits as messy. In my opinion, if you can't make sense of a history with merge commits, you just need more practice.
this video is AWESOME! Animations, audio, narration, everything. Great content, I will share with my subs too. Good luck and success for you!
8 месяцев назад+4
This really mostly works in simple cases where there's only one or few, mostly conflict-free commits, otherwise rebase conflicts tend to be annoying to resolve. In more complex scenarios, it's always better to have your own branch and then do squash merge. This allows you to have multiple commits on your branch and not worry too much about their description until the moment you actually want to push the changes to main branch.
Excellent video. I've sent it to several team members as we had a bunch of messy stuff like this and I'm awful at explaining things without waving my hands all over the place and drawing diagrams on whiteboards, which is hard when you work 4000km from your nearest colleague. Thanks !
thank you for this validation! I've always done this, and my coworkers thought I was crazy to use rebase. They were too scared of rebase (those wussies haha!). Also, I alias it to "pure" (PU-ll RE-base), since "pr" actually means something in git, even though it's not an actual command :). Also I like how you're keeping a "PURE" timeline by rebasing
great explanation and neat visuals, well done. thank you! edit: wrote the comment before the video ended, I'd never thought that this was your first video. keep it up, subscribed!
Really good video (information and editing), especially because it's your first. Please keep them coming, you just got a new subscriber. Wish you all the best ❤
@@philomatics I'm really glad to know that, my friend. It was an honest, unfiltered opinion. It's always so nice to meet good content creators from our field, you know? You'll undoubtedly receive more attention for your videos, because quality will always prevail and that you've proven to have. Greetings from Brazil 🙂
nice video man, my friend then did it to me and now I understand the defference between git pull and git pull --rebase! Hope I will learn for thank to you
The video is really cool and has really good content. The graphics are awesome to teach what was happening. I just don't like those titles (I'm already a dev for a while and got curious why someone would write NEVER), quite strong statement, I know there was an asterisk XD. Keep up the nice videos! It is looking really good!
Awesome video man! Been trying to find some answer around this since so long. Appreciate the effort of making me understand the simple topic with memes.
Really good video, especially for your first! I'm somewhat embarrassed to admit that I never tried to understand rebase and the benefits, and feel terrible for leaving a long line of terrible (and aviodable) git histories.I started on TFS over a decade ago and learned "just enough" to get by in git. Thanks for the quick lesson :)
I usualy don't like these very "Clickbait" Titles, but man you realy helped me understand some Git stuff better. I am a scientist so I am not used to working in large teams. So usualy my Git is just for myself. Thanks alot.
If this is your first video, then trust me, I am going to subscribe you till the end of the world! I have been trying to create a video on the exact same topic, but somehow I was unable to get the "visual" element of explaining "just right" - you nailed it, and it looks awesome! Been using `git pull --rebase` from around 4 years now - living in a "merge-commit free" world!
Thanks for the tip I've always used git pull --ff-only and if it cannot fast forward, I create a temporary branch, fetch and make a rebase before the fast-forward merge. This shortcut is doing the same process in a single command : very useful !
I haven't done a git pull in years. I have an alias to do "git fetch --all --prune" to bring down all remote heads, then I can choose how to combine my current branch work with what's on the remote, usually rebasing. I also like to set merges to be fast-forward only so a merge command will fail unless it can fast-forward, which again forces me to consider conflicts and handle them manually (usually with a rebase). git pull only really exists as an easy on-ramp for old SVN developers, but once you learn the git tool better I think you should use the more "native" workflows.
Nobody works on the same feature branch at the same time in a real life scenario. Sometimes as a reviewer, I do push changes to someone else's branch, but that actually means taking over someone's branch and finishing their work for them, not together with them. That usually happens when the task has to be cleared faster and the dev working on it is on vacation or something.
A few details that were mentioned in the comments (Thanks!):
Of course git pull is (by default) just a fetch + merge, but I left out that detail for the sake of brevity. I'd like to explain this a bit better in a future video.
Also, if you're _sure_ that nobody else is using the branch you're pulling from, it's definitely fine to pull! So the advice from this video doesn't always apply if you're using feature branches that only one dev is working on, or if you're squashing on merge. I've just seen a lot of teams that use different branching strategies (or don't have one in place at all). But it also doesn't really hurt in that case, since doing `git pull --rebase` will just do a regular pull then.
A common question was: *Why should you abort the rebase?*
If you already know how to fix merge conflicts during an interactive rebase, by all means, go ahead! You don't _need to_ abort, just fix the conflict. That's even better than aborting and merging. I just thought it would be a bit overwhelming for this video to _also_ explain interactive rebasing and fixing merge conflicts. I do have videos planned on resolving merge conflicts and interactive rebasing, stay tuned!
One more thing people mentioned is that you can configure git pull so that it will _always_ rebase by default. I was a bit wary of recommending this to people, since it changes the default behavior of a pretty common command, which might cause confusion (especially if you forget about it a few months later). If you want to make pull rebase the default, run `git config --global pull.rebase true`. From then on, `git pull` will rebase, and `git pull --merge` will merge.
In newer versions of git, it will even ask you upon first use which pull strategy you prefer.
Also, this video really blew up beyond my wildest imaginations! Thank you all for your support and nice comments! Next video is in the works and will be released on Monday. If you enjoyed this one, please consider subscribing to not miss it.
It's a good intro video. But most public OSS repositories, and virtually every project I've ever worked on in company settings, require PRs before merging (or rebasing) onto main. Here, you assume people work directly on the main branch and commit to it. I'd strongly advise against that as soon as you work on something with more than one person. Furthermore, PRs give you the added benefit of reviews, discussions, and documenting your change.
@@Misteribel I think I probably should've clarified in the video better that it doesn't have to be the main branch, but it could be any branch. Of course if you use feature branches that are exclusive to a single person, that shouldn't happen, but I've seen a lot of teams where that isn't the case, where branches are shared.
@@Misteribelcheck out trunk based development
I really like the brief video + the explanations in the comment. This could become a concept for your channel: A brief video with an overview plus FAQ/more details in the video description or comments.
It's not huge deal but I often don't see why some developers want a clean hist. Not like your viewing it for fun. You only look at it when there is an issue. Having the full history as it was is no big deal may also shed light on why something went wrong on post mordum. Now if you are suggesting to do this on your private branch I absolutely don't mind developers using this approach. On shared branc0hes I think it is best to leave hist as is. 🥂
I'd tell John to get off my branch or create a new branch and rebase it to John's.
Heh, yup, that also works :) Get off my lawn, John!
for the love of jesus. nO!!! for every new feature, every new commit, make a branch, then push that branch and work on it until you have the code you require, then push
I have the same John on my team. Keep off my lawn
John was on my lawn as well, mowing over my work and trying to break my branch. I quickly stashed my mower in the shed, took his work and popped my mower back out and merged our lawn work. Pushed all the good work back onto the branches landscape. Alls good John.
@@philomatics git push --force with commit message F* U John
Man came out of nowhere and started cooking
Let the man cook!
say his name
@@nikolacekic4244 Philomatics
Gimme nonsense!
This process is so much simpler and cleaner if you work from your own branch and use PRs. In that case, you can just rebase the PR onto main after it's reviewed. Or, if there are conflicts, use `git rebase main` locally first.
Yeah most teams will be working on feature branches, what I do depending on how long I'm working on a branch is either rebase every morning to keep my branch up to date with the main branch (or sprint branch in our case) or just do a rebase before I open a PR back to the main branch.
@@wombllanother option is CI, just keep your branches short-lived
@@wombll Our developers do no have commit rights on the feature branches, these are locked. Developer create their own branch (based on a feature branch), make their changes and than create a PR. The PR is merged into the feature branch. Every feature branch has a maintainer who is responsible for the branch. It is the feature branch that after reaching a milestone is merged to a release branch, but usually a release consists of multiple feature branch merges.
Our developers perform a single rebase just before they create the PR. In the past we have lost too much time after daily rebase operations, not to mention that you can pull in changes you were not prepared for or contain bugs...
What's the difference between what you suggested and squashing commits when merging the PR?
@@ruanpingshan well for sure, if you squash them, the commits will be merged into one, so you will lose history. As a consequence, if you have a feature branch and you would continue on it after merging it into main, you have to rebase it with main first to avoid merge conflicts.
00:38 "But theres an easy fix, ... just use *git push --force* XD
You should do force-with-lease imo
x10 developer move.
john : where tf did my commit go
Haven't you heard? Forcing is frowned upon these days, you need CONSENT!
That's why I forbid force pushes in our repos ;)
also if you have uncommitted changes you can use, `git stash` then `git pull` and finally `git stash apply`.
Visual Studio does this automatically for you now (after asking), it's a nice feature.
I configured auto-stash to always get this
git pull --rebase --autostash
I have always done this. It works
You should git stash pop instead to avoid cluttering your stash
First video? Wow! Great quality.
I always use git pull --rebase. And in case of conflict I just resolve them and do git rebase --continue.
I think the problem starts at step 0, where you and John are both working on the main branch. Ideally you'd have two separate feature branches, that would be merged to main when they are finished
not if you're doing trunk based development. then you just don't have feature branches, and you have regular merges with main branch in 2 directions.
@@sauliustb : Which is why trunk-based development has always seemed rather weird to me. Why use a workflow where you have to come up with weird workarounds for doing this without branches, when doing this is exactly what branches are for?
@ChristianConrad because any company I've worked in that used feature branching had issues with merge/rebase, or with long-living branches that were hard to integrate when it was allowed.
Trunk based makes small, production-safe commits, which reduces the chances of conflicts, as well as ensuring rigorous testing.
All work must stop if branch on origin is red in the CI/CD tool(though it shouldn't ever be red...)
@@ChristianConradIn small teams that work in different parts of the repo merge conflicts are rare and branching is overkill.
Unfortunately, in the real world, someone might decide they want to push code in your branch. Such people need to stay away from computers, but HRs don't allow criticism or other "offensive" behavior these days
Great first video! Short and informative and the graphics help for those of us that are differently-abled in the mental department. Much appreciated! :D
If you want to always use pull with rebase, you can configure `pull.rebase` to true to have it as the default behavior when running `git pull`. Then you can resolve conflicts and continue with the rebase with `git rebase --continue`. As a bonus, you can avoid repeated conflicts by configuring `rerere.enabled` to true, which will Reuse Recorded Resolutions from that point on.
Thanks for mentioning this, I've added this detail to the top pinned comment!
This is the real way. Best of both worlds.
Exactly this.
Yes! This is also how we do it at my work.
this.
This is amazing for being your first video. Very clear and concise, with nice visuals.
Just wanted to say your presentation style is amazing! Super clear and easy to follow, as well as really engaging. Nice one!
First video? Wow! Great quality, clean animations and clear narration. Congrats, dude!
Thanks man!
that's a lot of production value for a first foray into youtube, very clean and to the point. good stuff !
The best thing about this video is its on point from the very first second. no beating around the bush with bait-ism! good work.
explaining git in such a simple and well produced way is a banger way to start a channel.
i was going to say "wait but what if we are all making huge amount of changes to the same files so theres tons of merge conflicts" and then he explained that in that case, yeah, we are supposed to use normal git pull.
Hah! gotcha ;)
Jokes aside, you can also just fix the conflict in the interactive rebase then (see my pinned comment for more details). Video on that is in the works!
@@noomadeno not really. If master has some PRs merged into it then you will likely get a conflict if a separate feature touched some overlapping files or types.
If lots of people are doing huge amounts of changes to the same files, then something is wrong, I.e., long lived branches, lack of communication, too much in a file, ...
@@michaelkhalsa i maintain some soft forks which is when i edit a lot of things in a repository but my changes are not useful for anyone upstream because they are only needed for users of my builds. one example is, there is Super Mario 64 multiplayer for Windows, sm64ex-coop, and I create and release versions of it that work on Android and can cross play with the PC version. so i have to make a lot of small android specific changes throughout the repository that the maintainers of the Windows version don't want to have to worry about or get confused by.
@@michaelkhalsa Agreed. If the coworkers in this situation aren't working on the same files then there is no reason for them to be on the same branch. If they're working on the same files and tripping over each other, then they should probably just be pairing.
3:49 an alias is not needed for ‘git merge -rebase’. Just set the global config ‘pull.rebase’ to true with the command: ‘git config --global pull.rebase true’
Yes. My configuration 😊
would def be interested in a interactive rebase video or a video where you explain how to handle merge conflicts if you just do the normal git pull
Ok cool! Just to clarify, have you ever done an interactive rebase before? Have you fixed merge conflicts before? If yes, what were difficult bits? Just want to make sure I focus on the right things :)
@@philomatics i’ve not done an interactive rebase. i’ve edited files to fix merge conflicts before a few times but it’s been a while. i feel like when i do like. git pull and get the merge conflict error im rarely motivated enough to deal with it the way im supposed to. im also pretty confounded by the fast forward / no fast forward / rebase thing.
Thanks for the response! I have a video in the works on resolving merge conflicts, stay tuned :)
This seems like the answer to my problems with git :) thanks!!
Sometimes conflicts are inevitable, but having a clean git history and having all the people working on a project try to also interactive rebase their own branches as they develop to keep their own commits self-contained and clean helps prevent a ton of a crazy amount of conflict. I end up using rebase in some form at least a handful of times a day, and It's one of my favourite git commands. Beign really good at interactive rebasing will save you a ton of time and headache in the future, but it was also very confusing for me to learn at first.
Your way you presented it was brilliant. I've always used it, but only because I was told to, but I could never figure out how it worked and the conflicts involved. Thanks! Really cool, well-paced explanation
I just want to say that videos like these are super helpful and I would love a video on git rebase interactive.
I'm in school right now and I was joking with classmates about how every class is making us use git now (great!), but the only teach us add/pull/status/commit, and they just repeat that over and over. They don't even bother going into any detail on the ones they do bother to teach us either. It's very clearly a required part of the curriculum but it's always an afterthought, not a core part of any of our classes.
Thank you for your very nice feedback!
Do you have any specific details or commands you'd like to learn more about?
@@philomatics I think personally, my biggest hurdle is making sure I know how to resolve conflicts without mangling whatever repo I'm dealing with. With rebase interactive, what happens when I select my code over the other persons code, does it show up as a line deletion in the new commit? I've done solo projects and it's easy to be lazy, or build bad habits. I'm concerned that I won't be familiar enough with git when it comes to multi-person projects. Working with remote repos as well.
I recently started a project for a class, and I initially suggested a main branch, dev branch, and then we would each have our own dev branch, then we would work on our local personal dev branches. My classmate suggested we just use dev, and I realized that as long as we're careful about pushing to dev I didn't really have a good case for one or the other. In that sense I'd like content geared towards the why things are done the way they are. Why is using main/master branch bad, why dev branches, feature branches, personal branches, and what kinds of problems arise when you don't use them. That way I'm able to have a more informed discussion when negotiating how me and my project partners should handle git/hub.
Another subject is forking on something like github (I know github is not git, but I thought I'd bring it up anyway). In the example I give above, I hosted the project on my github account. Because of that I have direct access to the dev branch. If I push from my local dev branch, it goes straight to the shared dev branch. My partner on the other hand has direct access via permissions. I considered having him fork it, but then I realized it would create asymmetric contributions (since I have direct access). I see a lot of Open Source or public projects tell people to fork the project first. In my case it's a school project, so it's not a huge deal. My question is: In industry do people fork repos, or do they have permission to push directly? It seems a lot of businesses have a "business" github account, and then all employees/contributors have individual accounts that fork/branch out of that, so there is always at least one layer of indirection. Is that for internal projects or just Open Source? Not really about git, but definitely something where I'm not sure what the best practice is. I imagine understanding something like this from the get-go would be important during hiring.
I really like that this video goes over what the resulting tree looks like, it helps understand why rebase is better and not just that it is better. I've heard that rebase is better before, but I never knew why, or in this case, what makes pull worse. This video is great and I look forward to more content like this, even if it's not specifically the stuff I said above!
Really appreciate the whole explaining-through-visualisation approach. It's easy for me to understand that way.
Looking forward to learning more from your channel.
Great animations and actually very useful info too!
I've had to search for something in git history once, perhaps twice, in my entire 20 year career. Teams of mostly 10 to 20 people. To me, personally, the ease of just fixing the conflict and merge-commiting is just easier. Not only that, but the history will actually be more accurate. The misconception is that rebasing is more accurate. It's not. Rebasing is rewriting history, for a bug or issue you might or might not have to search the history for at some point.
sam,e i thinks its overrated, if you work in enterprise teams, you are screwed either way,
Same, but people as always have preferences. I for one don't mind having merge commits but some people feel that it pollutes the history... Like who is going to look At it? The only thing I think of is phpstorm select code and show history for selection
I don't think merge messes up git history but you don't use git blame? I think I use it a few times a day to figure out who I need to talk to or when something was added / how it fits into the timeline and on some occasions you will even be working with someone smart who leaves good commit messages that explain their reasoning or why a piece of code resolves some edgecase (or at least you can find the pr from that commit that does).
It's a very important tool IMO or else we'd just flatten the commit history every few months to make pulls faster.
I search git history all the time, and that's why I'd rather have git history reflect what actually happened - ie not people rebasing to make the repo "clean".
I've seen effectively this exact same video by a dozen people at this point and don't understand.
This is pointless OCD that maybe makes things look cleaner, but it is just worse.
Waiting for tomorrow for the next vid from Jr Dev 37482929383 that learns about rebase.
I really hope you will continue with your channel, I've watched many videos on git and this one was one of the best (and it's just 4 minutes, can't even imagine if you'll do a 15-20 minutes+ video)
Wow, first video! So surprised, it is of very nice quality
I've not used the "git pull" command since 2010. For a brief time, I configured repositories to make "git pull" do rebase instead of merge. That was tedious and prone to forgetting. Then I realized the fix is to stop using this stupid "pull" thing, and just do it in two commands. I don't want to fetch objects *and* muck with the local branch in a single command.
First, git fetch.
Then, see what you are getting into: git checkout (tells you by how many commits you and upstream are diverging). You may want to do a git log on the upstream branch to go into details, e.g. git log -p origin/master to see what has been happening: do you really want to rebase on top of all that now? And on top of all of it? Maybe there are certain older commits you want to pick up now, but avoid (for the time being) a breaking commit that will disturb your work.
This sounds like a good workflow, thanks for sharing.
Sane advice. For me there sre two global configs that helps immensely. Always do rebase instead of merge, and if there's any conflicts you can solve them and do a manual merge commit.
git config --global pull.rebase true
And it's always good to fetch before pulling, so a nice tree of commits helps you to quickly see the full picture.
git config --global alias.tree "log --all --decorate --oneline --graph"
Of course in some cases you might want to diff here and there, cherry pick something, or only rebase partially, but those are not everyday scenarios
Yup, fetch, then check what changed and decide on a case by case basis if you want to merge or rebase depending on what's happened and what will make the best history. Only thing to watch for is if you plan to rebase the history onto the latest main, or submit the changes as a sequence of independent patches. Then merges can be a bit annoying as they make rebasing, or reapplying the patches to a different branch awkward.
I still use git pull when returning to a project that others have committed to, otherwise fetch + rebase all the way. It's a nice and fast "catch me up" command
git checkout what?
Your Video & Audio is clear and so good for a first youtube video. Content about Git also presented in a lucid way to understand. I saw your video today only. Eager to watch more videos and learn from your channel. Good Work 👍
Nothing wrong with git pull in the example you've made.
In all projects I've worked on we usually followed the rule of using squash before merging any pull requests. This way it doesn't matter what kind of git history in your branch you have, it all gets squashed to a single commit and the git history of the main branch stays very clean, so you can just merge which usually way easier if you have to deal with conflicts compared to rebase (even if you use -rerere). I still use rebase from time to time but using it often gives me headache
I agree. I do think rebase keeps the history cleaner but my team basically never looks at or cares about the git history quality and it was not worth the hassle of the trickier merge conflicts when we tried to ditch merge commits.
git log --graph --online… Now add --first-parent, and you won't need squash anymore if you're using it for purely aesthetic purposes.
Came here looking for this comment, I’ve converted several teams to this model too! Squash and merge prs is easy to understand and gets you a nice clean history on the main branch
Why would you squash it? You're only removing information for no reason?
@@SourceOfViews I mean, all of the I information I usually need is in PR: typically there is much more than the commit message. When you squash and merge you automatically leave the PR number so you can easily find what you're looking for.
Also most commits aren't really useful on its own: "fix: lint" wouldn't probably help you to determine why this line has been changed in the first place.
But whatever works for you honestly, I'm just saying my experience
I always do interactive rebase, it's extremely simple, and working with fixups becomes really easy, keeping the git history super clean.
These animations are *really* good, but it's also definitely good advice. I've been anti-merge-commits for a while, it's cool to see other people spreading the word! :)
I follow these
1. git fetch --prune to clean the tree of remote history , It also shows how much the remote is ahead of your local repo
2. git pull --rebase, rectify the merge conflits.
3. git push
Get out of my effing REPO!
hehehe ,... This is a different approach to the problem;P
(Like if people cannot talk anymore ... with each other. Holy Crypto-Bro F )
To be your first video this was awesome! The animations were engaging and the minimal explanation was on point. Good work mate!
Wow! Your content is pure gold. I wish I had discovered ur channel before working with git. Ur channel should shine with elaborative explanation, especially the gorgeous animation!
In most cases you will be working on different branches/PR and the main branch is usually locked from direct push. When finishing the PR most hosts offer "squash merge" that no matter how many commits in your PR, there will be one commit in master after merging.
Though the same. There are barely ever cases where several people would work on the same branch locally.
@@martynasbaltutis6916 unless they work on a small project, local utilities etc where there doesn't seams like the need for the extra work with PR.
But of course, for larger serious projects you lock the main branch and use PR to merge to main.
And for noobs like me 🙂this is great information (or when I am called in to save some ones screw ups in a git repository 🙂)
I've been using git ever since I was in 2nd year of college, it's been ~3years. I never knew we could do `git pull --rebase`. It's really clean as you mentioned!
Please do a video on interactive rebase 3:23
rebasing the current git is my all time favourite , good work mate
There already is a shortcut for git pull --rebase, it's "git pull -r" ("git pr" alias is of course still shorter :^))
Oh cool, didn't know there is a shorthand, thanks for sharing!
I can't remember offhand, but I think I set the git global setting to always use the rebase strategy when using git pull.
this is great thanks
Or just update you ~/.gitconfig to add:
[pull]
rebase = true
To make sure you always get rebase.
After this (when it 'fails') you can fix the challenges using "git mergetool". (Yes, brace yourself: it's often a UI)
Wouldn't the "pr" letter combination be potentially confusing (to noobs, at least), because PR can also mean "Pull Request"?
Great editing. Best rebase explanation i found so far.
Though I personally really abort at the first sign of a conflict and just pull regulary.
I think you can make a strong point for NEVER rebasing. It just beautifies the git history, which is mostly a pointless artifact - all you are interested in 99% of cases are the results (e.g. your branches).
The big upside is that no one can fuck it up. Seems like every other project someone actually rebases the wrong thing and creates some sort of mess that takes hours of developer time to resolve.
If you have 100% confidence in all developers: go for it. If not: regular merges can make your lives so much easier
I never find it a good idea when two people work on the same branch in the first place. Every once in a while you should always pull in the latest main and then rebase your branch with it. This will make sure your branch keeps staying mergeable with the current main.
But sometimes you need to, usually helping someone fix an issue they couldn't on their own or dividing UI changes and business logic on a larger feature
@@gasparsigma I dont mind helping someone with ideas or reviewing their code suggesting changes here and there. But, that shouldnt require me to directly push sth on their branch. That’s too invasive for me. For the other case, it really gets down to how well you plan and size your tickets.
I don’t think its a issue with working on the same branch, eg john creates his own branch from main for his feature development and you created your own branch from main for your feature development and John finishes first and gets his feature merged, you will end up in the same situation.
@@tomiyokasensei not really. Since, john got his feature merged in main and considering main is the source of truth, its your responsibility to pull the latest main and rebase your branch with it. The idea is to consistently keep your branch mergeable with the source of truth (e.g main)
Wait until you read about trunk based development.
Everybody pushing to main. And honestly much happier. Once you manage to work like this you never go back
Just saw this in my feed and subscribed,my guy came out of nowhere cooking git💯
Now this is how you make a tutorial videos , simple , clear and straight to the point , keep it up
Great video. Tip for another video: 'git rebase --interactive' - a command too few know about and use but that is super useful to handle tricky merges or just when you want to rearrange your own commits before pushing.
In general great that more people try to describe and teach the concepts behind Git to make it easier for those not as experienced to understand what the different commands actually do and why they exist.
Why do you recommend running "git rebase --abort" and merging normally on conflict instead of proceeding with the rebase and resolving conflicts there? Does it have something to do with the apply backend that git rebase uses by default?
Also great video btw, it's nice to see such high quality dev content on RUclips.
That's a great question!
I actually do recommend proceeding with the rebase if you already know how - I just thought that also explaining rebasing _and_ resolving conflicts during rebase would've been a bit overwhelming for this video. I might do a video on rebasing in the future though.
Thanks for the nice feedback, made my day :)
@@philomaticsyes please do!
Wow, Best illustration, I never understood this concept this clear before!! Keep it up
@ 1:20, this might be confusing in some scenarios yes, but in general, I'm gonna have 40-something commits, so 1 "merge commit" is not a big deal.
This is the first time I watched a video from your channel and I found this video really useful. Thank you for your hard work and please keep on❤
3:02 even when there are conflicts you should ‘rebase -pull’. You have to resolve the conflicts anyways, the only difference is you may get conflicts for each commit in your branch as each gets re-applied, but that’s also what rerere is for. This is also why we should prefer smaller changes/features and merge back to develop often.
What an amazing video, i knew about the --rebase argument but had no idea of what it did, thanks! it's also so cool to see small programming youtubers rising!
do not know how many bugs i saw in people solving conflicts. Clear explanation wish you all the best on yt
Perfect! git pull in this situation does introduce bad history. I would just do a git rebase, resolve all the conflicts, --continue, and then push..
Git rebase is better than pull in this sort of situation.
Git pull --rebase is a rebase. It does a fetch and rebase instead of fetch and merge
theoretically ...
Really good intro, straight to the meat! I am leaving a comment here so that we can expand our knowledge in the world of development and operations. Good job!
Should be using feature branches and squash on merge.
Generally I agree. Couldn't this problem happen with a feature branch workflow as well? For example when multiple people are working simultaneously on the same feature branch?
@@philomatics , yes. But it won't matter because even if there are tons of merge commits on the feature branch they are all squashed into one when it is merged to the main branch.
@@gigantedocil That's a good point. I guess in the end it depends on how long the feature branch lives and how many people are working on it simultaneously.
I'm honestly a bit on the fence about feature branches in general. Maybe I'll make a video on branching strategies in the future (also for my own sanity ;))
@@gigantedocil but branch history is not preserved which really sucks if you're adding major features or refactors, unless your feature branches are very small and short lived, you should likely still be rebasing and preserving history
@@DMSBrian24 it's still preserved on the PR, if you really need it you can go there and see it.
Because this is your first video, and because this is my first time watching one of your videos, and because you provide great value, you won my subscription right from the start! 😊
I would say, never use git pull, always use git pull --ff-only instead and then handle the merge separately.
Great video by the way
What does that do?
@@abdullahX001 It prevents any merging.
@@abdullahX001--ff-only only applies changes if they're fast-forwar; ie they can cleanly merge your local work with the remote if it wouldn't cause any conflicts. You might see the words "can be fast-forward" in git status or other places in the git CLI.
My workflow is to always start with git pull --ff-only, and if it fails, I'll check out why the branches are different.
This should be the answer. No cognitive overhead, just pull and get on with your day.
Very helpful, Congratulations on your 1st post. Keep posting!!
This kind of videos, specifically ones about git just helps me realize again and again how complex of a software git is. Like how did people even come up with all these features, how they know that exactly THAT was needed. This blows my mind. And the fact that the whole thing was written in C is just another level.
If you want even more mind blowing complex explanations of git look up handmade hero introduction to git.
By people, you mean Linus Torvalds lol
Oh okay i guess he had help
@@getweirdwes Yeah of course lol
@@getweirdwes But Linus is amazing nevertheless
god damn it. I thought you are a pro on video making until you say this is your first one.
Your explanation is clean and concise. And short.
Please make more video on git like this one.
You can configure your Git to do rebase instead of merge during the simple 'git pull' command and use this without making any alias.
git config --global pull.rebase true
The 'git pull' command is just a shorter command that does two other commands: 'git fetch' and then either 'git merge' or 'git rebase'. So the ultimate option is running them separately by you and not by the 'git pull' command.
RUclips algorithm recommended this video. Congrats and I wish your grow
Was initially going to comment "you're crazy" then I realized this video is about the exact workflow I use. `git pull --rebase origin main` is your best friend :)
For a first RUclips video, it's very well done. You're a good teacher. It was very useful, thanks. I argue with my team that only pulling creates a bunch of garbage that makes it hard for investigating when needs be. Now I have the perfect video to show them. Subscribe
I will say that some projects prefer `rebase`, actually the majority of projects that I worked on. From that perspective, I will say that your video is highly opinionated, provides no real justification, and eludes an important point. REBASING IS ALWAYS DESTRUCTIVE. It is impossible to reconstruct the work that you and your colleague had been working on, post-factum, and if the merge conflicts are resolved incorrectly (much more likely given that a rebase has to resolve conflicts for each commit) good luck trying to get anything to work. The only thing that you do avoid is ... for lack of a better word... useless merge commits. But it is a well-known fact, that you can make useful merge commits, and Linus has made a great point of demanding good merge commit messages.
Don't mean to sound rude, but this guidance is at best of modest educational value.
What part of messing up your commit history did you not understand? Also, if you have multiple commits on the same lines of code, you're committing incorrectly. It's really a PITA code reviewing from people who do that. Plus it tends to not convey what the commit is doing
@@dan-bz7dz Given that you have the writing skills of a toddler, I would suggest refraining from advising people on what commits should look like.
Very much in agreement. A "clean history" is more or less just a personal preference. I don't see a history with merge commits as messy. In my opinion, if you can't make sense of a history with merge commits, you just need more practice.
this video is AWESOME! Animations, audio, narration, everything.
Great content, I will share with my subs too. Good luck and success for you!
This really mostly works in simple cases where there's only one or few, mostly conflict-free commits, otherwise rebase conflicts tend to be annoying to resolve.
In more complex scenarios, it's always better to have your own branch and then do squash merge. This allows you to have multiple commits on your branch and not worry too much about their description until the moment you actually want to push the changes to main branch.
Excellent video. I've sent it to several team members as we had a bunch of messy stuff like this and I'm awful at explaining things without waving my hands all over the place and drawing diagrams on whiteboards, which is hard when you work 4000km from your nearest colleague.
Thanks !
First video!? Excellent start! Can't wait to see more nice work.
thank you for this validation! I've always done this, and my coworkers thought I was crazy to use rebase. They were too scared of rebase (those wussies haha!).
Also, I alias it to "pure" (PU-ll RE-base), since "pr" actually means something in git, even though it's not an actual command :). Also I like how you're keeping a "PURE" timeline by rebasing
great explanation and neat visuals, well done. thank you!
edit: wrote the comment before the video ended, I'd never thought that this was your first video. keep it up, subscribed!
Really good video (information and editing), especially because it's your first. Please keep them coming, you just got a new subscriber. Wish you all the best ❤
Thanks for the super nice comment! :) Made my day!
@@philomatics I'm really glad to know that, my friend. It was an honest, unfiltered opinion. It's always so nice to meet good content creators from our field, you know? You'll undoubtedly receive more attention for your videos, because quality will always prevail and that you've proven to have. Greetings from Brazil 🙂
@@moacirsouza Obrigado!
Good vid. Thank you for creating it. Not all people using git yet appreciate reducing the number of redundant merge commits.
This video is so informative, and the animation was of such help! This doesn't look like your first video at all!
I have being trying to understand rebase for a long time, but hadnt being able to. Now I think I do finally thanks to your video!
nice video man, my friend then did it to me and now I understand the defference between git pull and git pull --rebase! Hope I will learn for thank to you
bro, this is amazing very good editing and very educational. Good shit, keep it going.
Really great video, simple and on to the point, couldn't have known if you didn't tell it was your first video. Keep it up 👍
The video is really cool and has really good content. The graphics are awesome to teach what was happening.
I just don't like those titles (I'm already a dev for a while and got curious why someone would write NEVER), quite strong statement, I know there was an asterisk XD.
Keep up the nice videos! It is looking really good!
For a first video you got the quality of well established RUclipsr, keep up the excellent work!
fastest and easiest way i've ever seen common git workaround explained, thanks!
first RUclips video? wow this was awesome! Thank you. I instantly subscribed!
Whaaat, that was your first video ever? Wow it was really professional and understanding. I will try using git pull --rebase first in the future
Awesome video man! Been trying to find some answer around this since so long. Appreciate the effort of making me understand the simple topic with memes.
I've been trying to explain this to my teammates for too long and you did really well!
Really high quality video and clear explanations! Keep it up! 👏🏻👏🏻👏🏻
Really good video, especially for your first!
I'm somewhat embarrassed to admit that I never tried to understand rebase and the benefits, and feel terrible for leaving a long line of terrible (and aviodable) git histories.I started on TFS over a decade ago and learned "just enough" to get by in git.
Thanks for the quick lesson :)
Congrats on your first yt video! This was very interesting and useful; thanks.
I usualy don't like these very "Clickbait" Titles, but man you realy helped me understand some Git stuff better. I am a scientist so I am not used to working in large teams. So usualy my Git is just for myself. Thanks alot.
That was more useful than the 6 hours tutorial I watched for git! Thaks
If this is your first video, then trust me, I am going to subscribe you till the end of the world!
I have been trying to create a video on the exact same topic, but somehow I was unable to get the "visual" element of explaining "just right" - you nailed it, and it looks awesome!
Been using `git pull --rebase` from around 4 years now - living in a "merge-commit free" world!
First ever video on RUclips, and a whopping 189k views already, Kudos !
Nice crisp, clear and concise video though !
Thanks for the tip
I've always used git pull --ff-only and if it cannot fast forward, I create a temporary branch, fetch and make a rebase before the fast-forward merge.
This shortcut is doing the same process in a single command : very useful !
This is most useful thing I’ve learnt within 4 minutes in the last 10 years. 😊
Awwww thank you, made my day!
I haven't done a git pull in years. I have an alias to do "git fetch --all --prune" to bring down all remote heads, then I can choose how to combine my current branch work with what's on the remote, usually rebasing. I also like to set merges to be fast-forward only so a merge command will fail unless it can fast-forward, which again forces me to consider conflicts and handle them manually (usually with a rebase). git pull only really exists as an easy on-ramp for old SVN developers, but once you learn the git tool better I think you should use the more "native" workflows.
Thanks for the video. Loved the clear, concise explanation and the great visual to support it. I'd love to see resolving conflicts during a rebase 😁
Nobody works on the same feature branch at the same time in a real life scenario. Sometimes as a reviewer, I do push changes to someone else's branch, but that actually means taking over someone's branch and finishing their work for them, not together with them. That usually happens when the task has to be cleared faster and the dev working on it is on vacation or something.
Congratulations on a fist video! Not many people create first video that actually has great advice.
Great work on this, hard to believe it’s your first video!
Alright alright FINE, you get a cookie for finally making me understand a concrete use case for this
This is your first YT thing? Loved your animations! Just continue!