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
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.
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.
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.
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
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 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!
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.
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'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
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)
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! :)
@@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.
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
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
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
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 TH-cam.
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 :)
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!
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
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)
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.
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.
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.
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!
I've certainly found that interactive rebase can be a massive pain, since sometimes you've edited somewhere in a file, and each commit that the other author made affects the same part of the same file. This means that you're continually fixing a merge conflict with the same piece of code again and again
The practice I would recommend is to always configure the rebase strategy to fast forward only. That ensures you don't forget to choose rebase instead of merge.
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.
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.
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.
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 :)
3 หลายเดือนก่อน
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.
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!
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.
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 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.
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.
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.
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.
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.
Also if you have more than one commit and both of you have worked on the same (having lots of conflicts) codebase you could do a squash (git rebase -i) to group commits if it makes sense. Normally I create multiple deployable commits throughout development but at the end squashing it into a single commit that represent a feature
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
If you get a merge conflict during a rebase, you will be dropped into the commit where the conflict occurs. You can then look at the files which conflict, manually resolve the conflict, then stage the changes with `git add -u` and continue the rebase with `git rebase --continue`.
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 was surprised with the fact this is your first video. The visualization and explanations are well done. I appreciate this concise format. There is nearly always more to say about a topic, but presenting a smaller, practical focus helps me register the information into memory. I look forward to seeing more of your work.
There's already a way to make pull use rebase by default, see the pull.rebase option. Also, there are valid times at which you'd want to merge instead of rebase, such as when updating a branch that's been in peer review for a long time. People hate it when a branch in PR changes from under them after they've already reviewed it (even if there were no merge conflicts).
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! 😊
For a first TH-cam 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
Great video and more importantly a great topic. There is a need for content like this on this topic, where the consequences of different actions/workflows are explained and solutions/options are also discussed and explained.
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.
My team has been doing a style of trunk based development in which all of our work goes onto its own branch (like a bugfix or a feature branch). Then when we are done with that work, we rebase onto the main branch and do a no fast-forward merge into it. This results I'm a really clean main branch that is only composed of clearly distinguished merge commits. Would recommend considering!
Having used all of these options and still somewhat confused on what would cause conflicts and what kind of conflict resolving I have to do, this video was very helpful in helping out with the same. Thanks!
Me encanto tu video! Solo usaba lo básico de Git hasta ahora como git pull, git merge, git push y git commit, pero me has inspirado a tratar de mejorar mi entendimiento de git. Sigue asi!
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.
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 !
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.
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.
23 วันที่ผ่านมา
Another solution: I commit my changes to my feature branch on local(let's call it A). Than I create a new branch from current main branch in remote (let's call it B). I cherry pick my commits fro A to B, and push B, then I can merge B to main and delete A.
3 หลายเดือนก่อน
Clear, to the point, useful, pretty much perfect 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
Been doing this for a while now, works great. Rebase if there are no conflicts, merge if there are. I like the merge commit when there's a conflict since it represents the real history ("yes, we did these changes separately, so let's not hide that"). There's still a gray area for "minor" conflicts, like working on unrelated functions in the same file that just happened to have a conflict up on the imports or whatnot.
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
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.
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
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
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.
Just wanted to say your presentation style is amazing! Super clear and easy to follow, as well as really engaging. Nice one!
Man came out of nowhere and started cooking
Let the man cook!
say his name
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’
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.
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.
that's a lot of production value for a first foray into youtube, very clean and to the point. good stuff !
00:38 "But theres an easy fix, ... just use *git push --force* XD
You should do force-with-lease imo
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
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.
Please do a video on interactive rebase 3:23
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!
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
To be your first video this was awesome! The animations were engaging and the minimal explanation was on point. Good work mate!
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
Great animations and actually very useful info too!
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?
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 honestly never knew what those useless commits were about, so that’s it. Thanks.
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 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.
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
Just saw this in my feed and subscribed,my guy came out of nowhere cooking git💯
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
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
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.
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
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 TH-cam.
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!
explaining git in such a simple and well produced way is a banger way to start a channel.
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!
Thanks for the video, straight to the point and without a boring intro. quick and explains with animation. I like it
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.
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"?
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.
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.
I think we all have such dreams :)
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
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!
I've certainly found that interactive rebase can be a massive pain, since sometimes you've edited somewhere in a file, and each commit that the other author made affects the same part of the same file. This means that you're continually fixing a merge conflict with the same piece of code again and again
The practice I would recommend is to always configure the rebase strategy to fast forward only. That ensures you don't forget to choose rebase instead of merge.
Now this is how you make a tutorial videos , simple , clear and straight to the point , keep it up
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.
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.
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.
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 :)
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.
This is why I always do a fetch and pull BEFORE making any commit(s).
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!
I love the simplicity in the explanation.
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.
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.
Very helpful, Congratulations on your 1st post. Keep posting!!
this video is AWESOME! Animations, audio, narration, everything.
Great content, I will share with my subs too. Good luck and success for you!
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.
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.
We need someone that does those kind of videos these days
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!
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.
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 👍
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.
Really high quality video and clear explanations! Keep it up! 👏🏻👏🏻👏🏻
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.
Pretty banger start to your TH-cam career, I must say. Good luck 👍
Also if you have more than one commit and both of you have worked on the same (having lots of conflicts) codebase you could do a squash (git rebase -i) to group commits if it makes sense. Normally I create multiple deployable commits throughout development but at the end squashing it into a single commit that represent a feature
oh this is your first video, is really high quality, congrats
Homeboy here, in a nutshell, is saying, _"Never use _*_git pull_*_ ... Instead use _*_git pull ... ... --rebase_*_ "_
Rebased.
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
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 👊
First video!? Excellent start! Can't wait to see more nice work.
First ever video on TH-cam, and a whopping 189k views already, Kudos !
Nice crisp, clear and concise video though !
I always, always rebase. But at times merge commits are nice to see what changed.
If you get a merge conflict during a rebase, you will be dropped into the commit where the conflict occurs. You can then look at the files which conflict, manually resolve the conflict, then stage the changes with `git add -u` and continue the rebase with `git rebase --continue`.
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
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❤
I was surprised with the fact this is your first video. The visualization and explanations are well done. I appreciate this concise format. There is nearly always more to say about a topic, but presenting a smaller, practical focus helps me register the information into memory. I look forward to seeing more of your work.
There's already a way to make pull use rebase by default, see the pull.rebase option. Also, there are valid times at which you'd want to merge instead of rebase, such as when updating a branch that's been in peer review for a long time. People hate it when a branch in PR changes from under them after they've already reviewed it (even if there were no merge conflicts).
Well explained, precise and straightforward video, thanks for the info and please keep it that way.
Nice visualization, helps make it easier to understand ❤
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! 😊
For a first TH-cam 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
Great video and more importantly a great topic. There is a need for content like this on this topic, where the consequences of different actions/workflows are explained and solutions/options are also discussed and explained.
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.
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!
My team has been doing a style of trunk based development in which all of our work goes onto its own branch (like a bugfix or a feature branch). Then when we are done with that work, we rebase onto the main branch and do a no fast-forward merge into it. This results I'm a really clean main branch that is only composed of clearly distinguished merge commits. Would recommend considering!
Having used all of these options and still somewhat confused on what would cause conflicts and what kind of conflict resolving I have to do, this video was very helpful in helping out with the same. Thanks!
Me encanto tu video! Solo usaba lo básico de Git hasta ahora como git pull, git merge, git push y git commit, pero me has inspirado a tratar de mejorar mi entendimiento de git. Sigue asi!
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.
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 !
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.
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.
Another solution: I commit my changes to my feature branch on local(let's call it A). Than I create a new branch from current main branch in remote (let's call it B). I cherry pick my commits fro A to B, and push B, then I can merge B to main and delete A.
Clear, to the point, useful, pretty much perfect 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
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 😁
Been doing this for a while now, works great. Rebase if there are no conflicts, merge if there are. I like the merge commit when there's a conflict since it represents the real history ("yes, we did these changes separately, so let's not hide that"). There's still a gray area for "minor" conflicts, like working on unrelated functions in the same file that just happened to have a conflict up on the imports or whatnot.
Holy crap, Great first video! I loved the visuals, and understood it really well even though i dont use github much. Great work!