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.
@Misteribel
4 ай бұрын
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.
@philomatics
4 ай бұрын
@@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.
@stjepanmajdak7396
4 ай бұрын
@@Misteribelcheck out trunk based development
@Carltoffel
4 ай бұрын
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.
@CJ-eq3bs
4 ай бұрын
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. 🥂
@JannisAdmek
4 ай бұрын
I'd tell John to get off my branch or create a new branch and rebase it to John's.
@philomatics
4 ай бұрын
Heh, yup, that also works :) Get off my lawn, John!
@moonchildeverlasting9904
4 ай бұрын
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
@shawncicoria
4 ай бұрын
I have the same John on my team. Keep off my lawn
@glhays6832
4 ай бұрын
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.
@romanstingler435
4 ай бұрын
@@philomatics git push --force with commit message F* U John
@keroy4588
4 ай бұрын
also if you have uncommitted changes you can use, `git stash` then `git pull` and finally `git stash apply`.
@rinner2801
4 ай бұрын
Visual Studio does this automatically for you now (after asking), it's a nice feature.
@darthwalsh1
4 ай бұрын
I configured auto-stash to always get this
@FisheyLP
4 ай бұрын
git pull --rebase --autostash
@kchemutai3483
4 ай бұрын
I have always done this. It works
@joshuakb2
4 ай бұрын
You should git stash pop instead to avoid cluttering your stash
@qwfp
4 ай бұрын
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
4 ай бұрын
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.
@ChristianConrad
4 ай бұрын
@@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?
@sauliustb
4 ай бұрын
@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...)
@ttdijkstra
4 ай бұрын
@@ChristianConradIn small teams that work in different parts of the repo merge conflicts are rare and branching is overkill.
@IqweoR
4 ай бұрын
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
@Misteribel
4 ай бұрын
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.
@wombll
4 ай бұрын
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.
@Kugelschrei
4 ай бұрын
@@wombllanother option is CI, just keep your branches short-lived
@2Fast4Mellow
4 ай бұрын
@@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
4 ай бұрын
What's the difference between what you suggested and squashing commits when merging the PR?
@SirThanksalot_1
4 ай бұрын
@@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.
@vinicchleme
4 ай бұрын
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.
@philomatics
4 ай бұрын
Thanks for mentioning this, I've added this detail to the top pinned comment!
@morosis82
4 ай бұрын
This is the real way. Best of both worlds.
@Xewl
4 ай бұрын
Exactly this.
@boriscat1999
3 ай бұрын
Yes! This is also how we do it at my work.
@nekekaminger
3 ай бұрын
this.
@x9wozz
4 ай бұрын
Man came out of nowhere and started cooking
@dj67084
4 ай бұрын
Let the man cook!
@nikolacekic4244
3 ай бұрын
say his name
@toxx1220
4 ай бұрын
00:38 "But theres an easy fix, ... just use *git push --force* XD
@fr9714
Ай бұрын
You should do force-with-lease imo
@etchbhatia
4 ай бұрын
Please do a video on interactive rebase 3:23
@br3nto
3 ай бұрын
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’
@chinmayp00
17 күн бұрын
Yes. My configuration 😊
@snivels
4 ай бұрын
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.
@Drewer
3 ай бұрын
sam,e i thinks its overrated, if you work in enterprise teams, you are screwed either way,
@SXsoft99
Ай бұрын
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
@CaptainWumbo
Ай бұрын
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.
@jgnhrw
14 күн бұрын
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".
@ashiqurrahman-nu7ik
4 ай бұрын
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.
@gasparsigma
3 ай бұрын
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
@ashiqurrahman-nu7ik
3 ай бұрын
@@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.
@tomiyokasensei
Ай бұрын
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.
@ashiqurrahman-nu7ik
Ай бұрын
@@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)
@bbravoo
Ай бұрын
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
@patrickbg110
4 ай бұрын
Just wanted to say your presentation style is amazing! Super clear and easy to follow, as well as really engaging. Nice one!
@willow2893
4 ай бұрын
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
@philomatics
4 ай бұрын
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 :)
@willow2893
4 ай бұрын
@@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.
@philomatics
4 ай бұрын
Thanks for the response! I have a video in the works on resolving merge conflicts, stay tuned :)
@zootsuitpenguin
4 ай бұрын
This seems like the answer to my problems with git :) thanks!!
@Alice-zj2gm
4 ай бұрын
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.
@tacokoneko
4 ай бұрын
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.
@philomatics
4 ай бұрын
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!
@TheStickofWar
4 ай бұрын
@@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.
@michaelkhalsa
4 ай бұрын
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, ...
@tacokoneko
4 ай бұрын
@@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.
@_topikk_
4 ай бұрын
@@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.
@minafishi
4 ай бұрын
that's a lot of production value for a first foray into youtube, very clean and to the point. good stuff !
@kazkylheku1221
4 ай бұрын
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.
@philomatics
4 ай бұрын
This sounds like a good workflow, thanks for sharing.
@sutirk
4 ай бұрын
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
@chilversc
4 ай бұрын
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.
@akison1980
4 ай бұрын
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
@g3ff01
4 ай бұрын
git checkout what?
@aakashs1806
4 ай бұрын
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
@abplayzz
4 ай бұрын
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.
@rickymort135
Ай бұрын
Git pull --rebase is a rebase. It does a fetch and rebase instead of fetch and merge
@moacirsouza
Күн бұрын
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
Күн бұрын
Thanks for the super nice comment! :) Made my day!
@moacirsouza
Күн бұрын
@@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 🙂
@darbyburbidge8976
4 ай бұрын
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
4 ай бұрын
Thank you for your very nice feedback! Do you have any specific details or commands you'd like to learn more about?
@darbyburbidge8976
4 ай бұрын
@@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!
@aleksandrpetrosyan1140
4 ай бұрын
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.
@dan-bz7dz
Ай бұрын
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
@aleksandrpetrosyan1140
24 күн бұрын
@@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.
@thethiny
4 ай бұрын
@ 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.
@redolentofmark
4 ай бұрын
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
@abdullahX001
4 ай бұрын
What does that do?
@redolentofmark
4 ай бұрын
@@abdullahX001 It prevents any merging.
@maleldil1
4 ай бұрын
@@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.
@zeeeeeman
3 ай бұрын
This should be the answer. No cognitive overhead, just pull and get on with your day.
@rerere1569
4 ай бұрын
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
@bepisdevs
4 ай бұрын
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.
@sergeyivanov3607
4 ай бұрын
git log --graph --online… Now add --first-parent, and you won't need squash anymore if you're using it for purely aesthetic purposes.
@sikhswim
4 ай бұрын
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
4 ай бұрын
Why would you squash it? You're only removing information for no reason?
@rerere1569
4 ай бұрын
@@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
@br3nto
3 ай бұрын
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.
@bennyorthner7223
4 ай бұрын
Great animations and actually very useful info too!
@Matrium0
3 ай бұрын
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
@kenneth.topp.
4 ай бұрын
explaining git in such a simple and well produced way is a banger way to start a channel.
@usoppgostoso
Ай бұрын
I honestly never knew what those useless commits were about, so that’s it. Thanks.
@etamluos4928
4 ай бұрын
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)
@MrinmoyRoy1990
Ай бұрын
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.
@residual-entropy
4 ай бұрын
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! :)
@RonnieDenzel
3 ай бұрын
Just saw this in my feed and subscribed,my guy came out of nowhere cooking git💯
@GreenClover0
4 ай бұрын
There already is a shortcut for git pull --rebase, it's "git pull -r" ("git pr" alias is of course still shorter :^))
@philomatics
4 ай бұрын
Oh cool, didn't know there is a shorthand, thanks for sharing!
@TokyoXtreme
4 ай бұрын
I can't remember offhand, but I think I set the git global setting to always use the rebase strategy when using git pull.
@AugustoCabrera
4 ай бұрын
this is great thanks
@gerke_kok
4 ай бұрын
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)
@matthijshebly
4 ай бұрын
Wouldn't the "pr" letter combination be potentially confusing (to noobs, at least), because PR can also mean "Pull Request"?
@Olodus
4 ай бұрын
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.
@Piasek16
4 ай бұрын
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 KZitem.
@philomatics
4 ай бұрын
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 :)
@Fe22234
4 ай бұрын
@@philomaticsyes please do!
@Nakabozu
Ай бұрын
Here’s what I do in this situation: git add -all git stash git fetch -all git reset -hard origin/branch-name git stash pop When you pop off the stack, your merge conflicts will appear and you can resolve them in the code before doing your commit. This prevents the extra merge commit we were trying to avoid!
@randelventura987
4 ай бұрын
To be your first video this was awesome! The animations were engaging and the minimal explanation was on point. Good work mate!
@forestcat512
Ай бұрын
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
@Aaku13
4 ай бұрын
Should be using feature branches and squash on merge.
@philomatics
4 ай бұрын
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?
@gigantedocil
4 ай бұрын
@@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.
@philomatics
4 ай бұрын
@@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 ;))
@DMSBrian24
4 ай бұрын
@@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
@gigantedocil
4 ай бұрын
@@DMSBrian24 it's still preserved on the PR, if you really need it you can go there and see it.
@shjpr2345
13 күн бұрын
That was more useful than the 6 hours tutorial I watched for git! Thaks
@VEKTOR_87
4 ай бұрын
Now this is how you make a tutorial videos , simple , clear and straight to the point , keep it up
@pratikiran
Ай бұрын
I love the simplicity in the explanation.
@netanelkomm5636
4 ай бұрын
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.
@Fe22234
4 ай бұрын
If you want even more mind blowing complex explanations of git look up handmade hero introduction to git.
@getweirdwes
4 ай бұрын
By people, you mean Linus Torvalds lol
@getweirdwes
4 ай бұрын
Oh okay i guess he had help
@netanelkomm5636
4 ай бұрын
@@getweirdwes Yeah of course lol
@netanelkomm5636
4 ай бұрын
@@getweirdwes But Linus is amazing nevertheless
@vijay_you
Ай бұрын
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 👍
@prayer4675
4 ай бұрын
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.
@StarshipTr00per
3 ай бұрын
For a first KZitem 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
@riceontopofbeans534
4 ай бұрын
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!
@gunnarthorburn1219
4 ай бұрын
It is a good idea to do git pull before creating your local commit. And it is a good idea to push your commit soon after you create it. There is still a risk that you and someone else does this is a short period of time. In that case I usually do git reset --soft HEAD~1 to undo my own local-only commit. Then git pull works. I can commit again, and push.
@Metruzanca
4 ай бұрын
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 :)
@Alice-zj2gm
4 ай бұрын
Slammed like so quickly on this one. I'm so glad people are finally starting to popularize rebase and take more care in keeping the git history clean. I've also really liked defaulting to rebase merge on PRs as the new default.
@kesarkiran5265
Ай бұрын
I use git pull via eclipse (not terminal) just before committing. Works well. But if I forget to pull and commit directly, we get the merge commits issue as explained in the video. Thank you.
@the_mastermage
4 ай бұрын
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.
@InhumanBean
Күн бұрын
Really great explanation and love all the animations too.
@hollengrhen1
4 ай бұрын
Thanks for the video, straight to the point and without a boring intro. quick and explains with animation. I like it
@abdulrahmanalamoudi9903
Ай бұрын
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❤
@davepusey
4 ай бұрын
This is why I always do a fetch and pull BEFORE making any commit(s).
@cloud3x3
3 ай бұрын
I have always done rebase because I guess that's just how I learned it. Thanks for explaining why. Something that helps with the rebasing is if you rebase your branch and squash all of your changes before doing the main branch rebase, so then it looks, for all intents, like a normal merge.
@qwertycomp9618
4 ай бұрын
Oh nice! I would usually do a git fetch + a git rebase in this situation. Good to know that’s a built in feature of git pull! Thanks!
@kdurgiya
4 ай бұрын
First ever video on KZitem, and a whopping 189k views already, Kudos ! Nice crisp, clear and concise video though !
@jamesmussett
3 ай бұрын
I prefer to configure git to always fast forward to the fetched branch and fail otherwise. Normally, I just use 'git pull --rebase' manually if it fails but I sometimes like to use 'git reset --soft' to reset my changes to the head commit, stash the changes if needed, pull the incoming changes, and then do my commit. This is useful if i need to modify my changes in any way as a result of the changes coming in, or if i need to combine all of my local changes into one commit.
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.
@lazygamer6249
4 ай бұрын
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.
@MarcinPLBlog
Ай бұрын
Really high quality video and clear explanations! Keep it up! 👏🏻👏🏻👏🏻
@JarheadCrayonEater
2 ай бұрын
I've been using the following for years, in a team environment, in the CLI. From your working branch. git pull --rebase Fix any merge conflicts (git merge --continue, after each commit merge conflict) Critical next command, before any other work, and after the previous command. git push --force, to make the remote branch the same as local. All of that assumes you're in your own working branch, where no other dev is also working in. Maybe I'm wrong. I've been programming since 1986 and using git for decades, but haven't focused on the advancements in git and the IDE's that use it for some time. So, maybe I missed something. My experience with VS goes way back to the 90's, and it's git integration has always sucked. Maybe that changed, finally.
@dragons_advocate
2 ай бұрын
Homeboy here, in a nutshell, is saying, _"Never use _*_git pull_*_ ... Instead use _*_git pull ... ... --rebase_*_ "_
@jonathanalpart7812
2 ай бұрын
Rebased.
@EThaiZone
4 ай бұрын
Thanks. It's good call. Normally I did `git fetch origin` and `git rebase origin/main` like this. Your suggestion is better. BTW for who that said this might not need becasue you did git merge + squash. Actually this is difference topic. This video is about commit history before merge. It doesn't about commit history after merge. so it's up to you. IMO this is peace of mind when you do some commit review on your branch. Your feature branch history will be quite clean and commit comparison will be easier too.
@Marenthyu
3 ай бұрын
I think it should be decided for each team (or maybe at a company-level) which strategy to use. Both are valid in my eyes. with a merge commit and the "additional branches", you "preserve" the timeline of people having, indeed, been working in parallel and then there was a point in time where those changes needed to be merged together. A rebase means you "fudge" with the timeline and each individual commit may not be a "functional state" as what you get when checking that state out may have changes in them that the developer did not have at the time of creating their commits.
@schrodinger6393
3 ай бұрын
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.
@twinjuke
Ай бұрын
I dream of a RCS where I never need to take care of these methods, never need to understand LFS and such file-format specific fluff, just want my work to be merged into THE code. I dream of a system where all stuff is done in the best way without needing me to bring technical decisions. The only thing it wants from me to resolve conflicts if there are... a system that wants me to understand only the work I do, not the underlying system behind it. A system that works for me, not wants me to work for it. The video is nice though.
@philomatics
29 күн бұрын
I think we all have such dreams :)
@huyhoang_ta
Ай бұрын
Nice visualization, helps make it easier to understand ❤
@cryticone6403
4 ай бұрын
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
@anwar7257
4 ай бұрын
Well explained, precise and straightforward video, thanks for the info and please keep it that way.
@David_Groves
3 ай бұрын
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 !
@majormoody
Ай бұрын
Squash commiting PRs has been working for us, unless you really want your super clean history with your super-awesome commits within a large PR. Then, sure go nuts with rebase and/or squashing within your branch.
@dj67084
4 ай бұрын
This is best and simplest explanation I've seen of what rebase means. Please make moar pls thx :)
@ishaankapoor933
4 ай бұрын
Very helpful, Congratulations on your 1st post. Keep posting!!
@gobi817
Ай бұрын
KZitem algorithm recommended this video. Congrats and I wish your grow
@arlindpodrimcaku7432
3 ай бұрын
We need someone that does those kind of videos these days
@olge1355
4 ай бұрын
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!
@ivanmaglica264
4 ай бұрын
Congratulations on a fist video! Not many people create first video that actually has great advice.
@xeno9585
3 ай бұрын
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
@cassiano.matos231
Ай бұрын
Awesome content, dude, and nice way of explaining stuff as well, straight to the point! You just popped out in my feed and got a new subscriber 👊
@DrunkenUFOPilot
4 ай бұрын
What I would do, if I were the software engineer on the right, is do my work on a branch, "dev-myname" or something like that. When I'm happy with my changes, commit, then switch to main or master. There, it's safe to pull (as far as I understand) then I can merge my dev-myname. Once that's done, push. Then I hope to remember to switch back to dev-myname before editing any more files - of course I "rarely" make that mistake! After 15 years of using git, I still don't understand it fully, but videos like this help with reasoning, comparing how might do things with what experts do, and seeing new alternatives.
@YT-ry5zm
4 ай бұрын
oh this is your first video, is really high quality, congrats
@alperenweb3
3 ай бұрын
I have never seen somebody explained git pull that much good 👍
@fr9714
Ай бұрын
We have master -> development branch -> people branches. This extra level helps a lot because we can squash and merge from development to master and make it all a single nice commit to master. Then we tag that without our release number.
@eriklindskog1841
3 ай бұрын
Indeed. Most of the time this is what you should be doing. One can also set this as the default behavior of pull so I think this problem is widely recognized.
@mohammedaamer73
3 ай бұрын
Courses with presentation like this will be lit 🔥🔥🔥
@rricardobs
4 ай бұрын
Wow. Please tell us more about the interactive rebase. It's very difficult to me to understand when to uso some git command and how it works but using this animation is a lot easier to learn. When you showed the animation of the git pull with with "B" and "C" I finally got it right. Please keep it up.
@gohanmineiro
4 ай бұрын
fastest and easiest way i've ever seen common git workaround explained, thanks!
@FransOilinki
3 ай бұрын
The command `git pull --rebase` running without errors is no guarantee there are no problems. Rebase works on plain text files without semantic understanding of them, so there still could be problems stemming from functionally conflicting commit mismatches. As an example, suppose you call a function somewhere in your rebased commits that is removed by the fetched commits. This is a nice example because it visibly breaks the code, but it could be less subtle. If you like to use `git pull --rebase` (which definitively is better than `git pull`) you should still spend a few seconds to check there are no functional conflicts.
@philomatics
3 ай бұрын
Good point, fully agree! Though I wonder, wouldn't that happen regardless of whether you merge or rebase?
@milkandhenny
4 ай бұрын
Why is John on my branch? Won't a rebase rehash the commits? I thought it was a bad idea to change the past if it is someone else's present i.e. You are both working on the same Branch
@FredWhosDead
4 ай бұрын
Good vid. Thank you for creating it. Not all people using git yet appreciate reducing the number of redundant merge commits.
@TokyoXtreme
4 ай бұрын
Pretty banger start to your KZitem career, I must say. Good luck 👍
@adrianswebvideos
4 ай бұрын
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 😁
@Clowndoe
4 ай бұрын
Rebase is my preferred way to go. It does mean I have to help colleagues and interns a lot, but it's worth it. It helps to know fundamentals of how Git works. For example, strictly speaking, your commits aren't added on top of the branch. That's impossible, since the parent is part of the commit's identity and thus its checksum. Rebase (or cherry-pick) makes new commits with hopefully functionally identical diffs. Obviously, that doesn't have to go in the video. It was good for the purpose of making people consider a new way of working.
@DanielDogeanu
3 ай бұрын
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! 😊
@nicejungle
4 ай бұрын
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 !
Пікірлер: 1,4 М.