How to Use Git Branches Like a Pro (FastAPI Example)

Confused about Git? You’re not alone — but after this video, you’ll have a clear understanding of merging, rebasing, fast-forwarding, and when to use each. We’ll walk through a real-world example using FastAPI, so you’ll see how these concepts play out in actual projects. I’ll use GitKraken to visualize each step, explain the pros and cons of different strategies, and even touch on GitFlow vs. trunk-based development. Whether you’re just starting with Git or want to sharpen your workflow, this video will level up your Git game.

🔖 Chapters:
0:00 Intro
0:24 Step 1: initial commit
2:05 Step 2: Creating a Feature Branch
4:01 Step 3: Merging vs. Rebasing
13:13 Alternative: trunk-based development
18:35 Final Thoughts
18:59 Outro

#arjancodes #softwaredesign #python

[vikingthedude]

Always rebase. Rebase on pull, rebase on merge, rebase in the gym, rebase at home, rebase backstage, rebasing day and night. Its terrific

[JeremyLangdon]

I like squash merges on the main branch 😊

[evgeny]

Finally nice explanation on a difference between merge and rebase, merge creates a merge commit applying changes from a different branch onto the master, rebase merges master into the feature branch and re-applies commits of the feature

[axeldelsol]

I use all 3 options:
* Fast forward when I am doing a git pull (or git fetch + git merge for those who prefer this way)
* Rebase my feature branch on the main branch before creating a pull request. I also use interactive rebase before to make it easy for the team to review my code
* Squash and merge when closing a pull request

You can have a git flow and feature flags at the same time. You can merge your branch where your feature is only used if the feature is ON. I think it is a good strategy when working on sensitive part of your code because you can quickly "rollback" if needed (day 0 bug)

[gaxkiller]

Sorry I love your videos but for this one you should have stated that it was about a gui git app and not about git cli

[M_]

I think it's a pity that more focus was given to sponsored product that to the git commands and their differences.

[DenizDemirsoy]

I scrolled forward to get to the cli part, but got disappointed because all was about gitkraken. your videos are great, the amount of sponsoring was ok up to now. I hope this was an exception.

[ALERTua]

The video is ok if you account for the advertisement basis. GitKraken is also ok, but some alternatives with the same functionality are completely free. For example, Fork.

[coderider]

Squash on the pr (feature / bug story) into main branch. Nice clean history on main branch.

[saifshaikh]

Need production grade projects tutorials on FastAPI

[JoolsTurrall]

Glad you eventually got to video subject matter, shame it's really an ad for Kraken, but if anyone really wants to learn git they should just use git, in the terminal. This isn't an elitist view, it's because git has so may options available that IDEs often don't implement a button for. Git Kraken is a does a great job if providing shortcuts. But don't confuse it with git. It is a bit if a learning curve to use the terminal but nothing worth doing is ever easy.

[profskett]

I liked the explanation of the different types of branch-management strategies and pros/cons - v helpful, thanks!
However, what I still don’t understand is: why achieving a linear commit history is even considered a desirable outcome?? (For my money, it is more clear what happened and why if you keep all the merge commits, even if it looks a bit more complicated at first glance.)

[CallousCoder]

To handle the merge conflicts whilst your developing your feature by rebasing is the whole philosophy! You want to solve merge conflicts before you merge. If someone changed the same function as you did and it’s already in production, you want to adhere to that new way of working too or you’ll introduce a regression error.
So rebase frequently! And then merge.

[DrGreenGiant]

Great video but the title is misleading. It should be something like, "How to merge strategies in GitKracken, " because there was no direct use of git at all.

[JTsek]

FYI git switch -c branch-name is another way of creating a new branch

[ajflorido]

So, basically use merge to avoid strange things :D

[dr.sybren]

Yup, I always work on a feature/fix branch. Then that gets pushed back to the repository, turned into a pull request, and then the buildbots can run on Linux/Windows/macOS to see nothing broke (aka avoiding the "but it worked on my machine!" syndrome). Once that's done, for smaller things I press the "Rebase & Squash" button. For bigger changes I do an interactive rebase myself, potentially squashing several commits into one, leaving only the necessary commits. And then push to `main` in the central repo.

[sebastiannachtigall]

I totally understand why you would end on the note of 'trunc based development and feature toggles is hard. Look how messy it gets'. Its a sponsored video. Without Git Flow, or the need to use any branching strategy why use GitKraken in the first place. But for people who want to know common strategies to do feature toggles along trunc based development: its just a single prompt to your favourite LLM away ;-) Still love your videos Arjan :X

[abzrg]

Thanks! could you share your experience with different branching strategies in future videos?

[frantisekcastek]

Great explanation, nice feature tip 👍