วีดีโอ

The thing about rebase I like the most, is that it keeps your history linear and doesn't create additional merge commits. In many cases I pull quite often, so I don't want to create extra merge commit without reason, I just do git pull origin <branch_name> --rebase. Of course, if you your branch diverged a lot from main it's safer to do a merge

The premise with visualization was really good, but I have to say this feels more like a quick whirlwind tour for people who are already well-versed with the subject matter than a tutorial for people who aren't.

thanx but real code examples would be better for demonstration

I don't know who invented this st...d and confusing notation of using arrows in reverse direction. Everyone picked up and uses it. It contradicts to time flow.

Nice tut. Concerning rebase it is way simpler. You are safe to rebase unless you pushed your branch. Once you did, you should never rebase again. Anytime, anywhere. Most IDE even warns you. Cant tell if git itself warns or not as I am not a CLI master. I would explain its function a little bit different than the way you did. It will shift the whole branch with all your commits and keeps the branch. Only the "junction" will move ahead.

I always rebase. It's not problematic at all if you do it often. And if you don't, an equivalent merge commit would also introduce a bunch of merge conflicts, so it really doesn't make things more complicated. Rebasing just makes more sense to me: i.e. you're applying your changes on top of the main branch - like you wrote it - instead of an arbitrarily complex and mysterious "merge" commit. So yes, I rebase because I very much dislike merge commits.

This short video about git is really helpful

Really informative

This was actually just as good if you don't know Git at all! Thank you!

So... Do you get a waifu doing this job?

35:23 "please don't set a password, your computer is already password protected" Why would you say that? Do you also want to tell me what I should eat for breakfast or how to do my laundry? Getting political or preachy in a tech presentation is really out of place, my friend.

Man i spent so much time trying to re-find this damn video! I watched it for the first two years ago when i learned git and though to myself "nah, too complicated, i'll keep it in mind for later". Well, the day has come. And oh man did i search for this video. This. This one. A true life saver. Thanks.

i am a rebaser 😅

The reason why git bisect takes so little to work with is because it is a binary search which just means that removes half of the remaining commits on each step of the process

very useful. thanks!

Great tutorial but would be better named "git intermediate". An expert is going to know a lot more workflows and will know about things like tags, repo pruning, hooks, and ways to think about where you might find a merge conflict not detected as one.

Great presentation! Out of curiosity, what presentation/slide software do you use?

There is a workflow where rebasing is useful. Imagine you are working on a repository that has a CI/CD pipeline set up with automated tests. In order to merge your code to a protected branch, the pipeline for your branch must succeed otherwise the Git platform blocks the merge. This is a logical setup since the pipeline for a develop branch must pass before your branch can be merged into master. However, what if master has changed since you branched off some time ago in such a way that your develop branch would result in bugs after being merged in? The current setup does not protect against this case since the pipeline has only passed for develop which may have been forked from on an older commit in master. What you can do is also configure your repo such that only fast-forward merges into the protected branch are allowed. If the branch is forked from an old commit in master, the developer has to rebase their branch onto the lastest master then force push and if the pipeline succeeds then you know nothing is broken (assuming your automated tests are off a good quality) and you can fast forward merge free from any conflicts or (merge-related) bugs. Merging the master branch into your develop branch at regular intervals to keep it up to date may work theoretically but its a manual approach where you rely on the developer remembering to keep their branches up to date. The approach using rebase I outlined above will catch any such mistakes and give developers the confidence that a merge will not cause bugs.

If you don't want to stage an entire hunk with 'git add -p' and just want to stage a few lines, you can use 'git add -e' to pick and choose which lines you want to stage without using a separate tool like git-cola. Also, if you want to write a commit message with a body, you can use 'git commit -e' to type in a title in the first line followed by an empty line then write your commit message body on the third line.

The information in this video is like... NON-STOP! Constant knowledge. Had to pause it multiple times to just let it sink in. LOVE IT!!! Thank you

You totally can rename/move files without delete-create and losing edit history. This is what 'git mv' command made for.

awesome vid

Great presentation tho, good coverage and clear explanation. Thanks for putting this together.

I must have misunderstood the meaning of a noob/newbie.

Thank you so much. I was tought using git with source tree, but really, all these buttons without eyplanation are very confusing. I will from now on just use the shell and be happy :D

Great git walkthrough. No fluff, good pace and clear explanations with visuals.

Thanks for the tutorial. A question: I ran into a problem of headless state after I checked out a specific commit inside the branch to make a pr on top of the specific commit. My manager told me don't checkout commit, alway checkout branch. I just don't understand this, what's the thing with headless state, and why it's a bad practice to checkout a commit?

The best git tutorial I've seen so far, thank you. EDIT: sound volume little to low, imo

Fantastic video, exactly what I needed.

How did you make that gun move around with main player and shoot 😮

Very well done, many thanks!

I've never used Git before and you don't need to be a rocket science engineer to understand this .... Don't overthink your subject sir!

this was awesome, thanks for sharing :)

the four points he mentioned under who this talk is for? I literally thought he was talking about me.

Question about that... What would you say is the "bar" for required knowledge before entering a Game Jam? Or is it less about the 3rd partner's lack of experience and more about how much power to give them for the direction of the project? When the team prioritizes creating something on time, then perhaps that can clearly cause this partner to need to focus on what they need to learn and allow the experienced people to move forward uninhibited. I hear a lesson in letting experience lead and finding a way for inexperience to contribute without causing timeline issues.

He said you should use a mergetool with 4 windows. can someone suggest a mergetool like that?

This is the most helpful git tutorial I've watched, thank you for breaking it down into the basics so clearly.

Excellent presentation

great explanation

I really thought git playground was a thing, but got to know that its simple setup for practice.

Thank you so much for the video!!!

Perfection

Great presentation! Very clear and concise with some nice graphs. Thank you for this!

note to self: try git add -p (interactive add) and try to setup editor for git merge

Can i get access to slides, please?

Any tips on how to get used to diff syntax? Comming from vscode highlighting, diff output is ... complex to say the least.

Thats alooooot, after many years now i feel like i understand git, (at the time of writing the comment im still at 8:47)

6:30 I thought you said this wasnt a basic talk about git, when do we get to the non basic stuff?

Definitely on team rebase / push often / trunk based, stay current and don’t diverge from the one source of truth. Got onto this team after working in slow moving Gerrit-review horror gits from barely working orgs that post code freezes introduce an unreadable history with merges upon mergers where mental strain of trying to understand what happened is unacceptable. If the project is simple enough I’d prefer just banning merges and set the remote to fast forward only. Forces team members who want to merge to get their things working and easily understandable locally. Work from head not a feature branch, rebase and push often. For the projects that are able to work on trunk/main/master and not diverge into feature branches / merges / … it makes life in git and cooperation easier.

I've never been working in a way such that there may be multiple persons commiting on a same branch, in this situation the git fetch operation makes sense because you don't necessarily want to resync with the remote branch right away. In a workflow where 1 feature branch = 1 active person, you would just fast-forward merge the develop branch with origin by using the git pull operation then eventually do a 3-way merge with your feature branch. git format-patch and git am are the enhanced git stash and git stash pop except it takes commits themselves not just their content (you can save the last three commits, then reapply the three commits in a row later on). ex: git format-patch abc123^..HEAD --stdout > tmp.patch git reset --hard abc123~1 git am tmp.patch # solve potential conflicts with git am --show-current-patch, then git add, then git am --continue Reasons you would want to use merge instead of rebase to resync your feature branch with its parent: - We can see in the feature branch commit history when we resynced the feature branch with develop, and also see others commits along with ours in the same timeline - Even after pusing, we can still revert the merge (via a revert commit or with a reset --hard + push -f) - We preserve commits original intention (modifications that were applied to a specific version of the product, when we hadn't synced with the develop since n days, etc..) - We can troubleshoot bugs with git bisect (which wouldn't make sense after a rebase since new commits are inserted at the beginning of our branch's, so if the cause was from a resync with develop you would never know)