Unlock Git collaboration with CLONE, PUSH & FETCH

The better way to learn Git:
learngit.io/
Git branching video: • Git's most perplexing ...
Newsletter readers get my videos early: newsletter.themoderncoder.com/
Reach out! [e-mail]
----
In this video tutorial we deep dive into Git's remote tracking branches in order to gain a deeper understanding of clone, fetch, push and pull. The key to Git collaboration and syncing is Git's remote repositories, and how remote tracking branches (ex. origin/main) work when changes are synced (i.e. fetched, pushed, and cloned) between Git collaborators. Aside from exploring branch theory, this video tutorial covers the basic usage of "git pull", "git push", and "git fetch".
CHAPTERS
0:00 Intro
0:49 Remote repository theory
3:17 Git clone
4:36 Git push
6:04 Git fetch & merge
7:38 Review cheat sheet: clone, fetch, push, log, status
8:10 Going further
MY TECH
www.themoderncoder.com/wfh-ny...
MUSIC
Music from Uppbeat (free for Creators!):
uppbeat.io/t/danijel-zambo/st...
License code: BN9M9SI8VKMVVJWQ
#git #github #learngit #mergeconflicts #github #gitmerge #gitrebase #stackoverflow #development #softwareengineering #programming #coding #versioncontrol #developer #technology #tutorial #stepbystepguide #gitrepository #vcs #programmingtips #codersofinstagram #codingcommunity #learnprogramming #softwaredevelopment #codingtutorial #gitexplained

[@Aramoonstaz]

Thank you for this video!!!! :D Currently trying to educate myself and git comfortable with learning Git for work. Twas very esthetically pleasing and straight to the point!

[@themoderncoder]

Glad it was helpful!

[@dayasagarpatil]

Excellent videos, have been using git but I had lot of confusion about many basic concepts, luck i came across your videos with very crisp explanation with awesome graphical representation which makes it very easy to understand. Keep up the good work, looking forward for more informative videos..

[@themoderncoder]

Appreciate you saying that! If you're looking for something new, my video on fetching/pulling (kzbin.info/www/bejne/imKWmHd4jcaloJI) is essentially a follow up to this one.

[@shrfrn2114]

Hi, good stuff! I enjoy your other videos as well. Especially those about rebasing which really helped me. Thanks. I would definitely like to learn some more about the two topics you mention at the end of the video - diverging branches and setting up remote tracking branches manually. All the best.

[@kobi219040]

Same here! great videos man, really clear and helpful, thanks a lot!

[@themoderncoder]

Appreciate it guys!

[@prashant6804]

Thanks for explaining with graphics!

[@johncerpa3782]

Excellent video

[@matk2283]

all gold you are teaching here my dear friend. I can not thank you enough. your animation make all the difference in the world. my gratitude to you. Mathew. K from Colorado

[@MohammadLsk]

Next level content🔥Keep it up

[@bournvita382]

Thanks. I really like your contents..

[@lookingforbino]

Great tutorial. Thanks My question: Context: one of the weekends, I made tons of progress for the codebase, I changed 10 files. Let's say I am only allowed to make a PR that includes changes from 2 files. I don't want to make PRs during the weekends, and I am going to make 5 prs on Monday, and they all depend on each other, meaning I need to divide all my progress into at least 5 PRs. Question: What is your git stratagy to handle this situation?

[@themoderncoder]

You'd probably need to do something like this (newsletter.pragmaticengineer.com/p/stacked-diffs); however, limiting PRs to only 2 files doesn't really make sense. If all the code changes are related to a single feature they shouldn't be split up. At the very least, I'd suggest grouping the files together based on functionality, but if one PR depends on another to function, they should probably be in the same PR.

[@lookingforbino]

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?

[@themoderncoder]

It's just that you'll have a harder time merging changes made in a headless state. Branches are really the core of Git, and a lot of mechanisms (merging, push, pull fetch, PRs) are based on branches/commits that build off of each-other in a predicable way. As soon as you check out a commit and enter a headless state, you're operating outside of a well established hierarchy of commits/branches. This means the changes you make can be easily lost, and it's harder to reconcile things afterwards. I'd view checking out a commit as a rare operation. If I understand your situation correctly: if you really need to make changes off of a specific commit maybe creating a new branch and cherry picking the commit into that branch might be easier.

[@TheSpeechkiss]

I'm a bit confused. In the first example, you did this: 1. touch config.json 2. git add . 3 git commit -m "Added configuration file skeleton" 4. git fetch origin 5. git push origin main git fetch origin - "reaches out to remote repository and pulls down any new commits that you might not have yet" . However in the second example(coffee break) you did this : 1. git fetch origin # automatically downloads the changes 2. git status # your branch is 1 commit behind 3. git merge origin/main # to incorporate those changes into your local branch - to merge your local main with origin main. 4. git status # Voilà ! I don't fully understand why did you do "git merge origin/main" in the 2nd example. In the first example just "git fetch origin" was enough to download any changes and then do a push.

[@themoderncoder]

In the first example the origin repository doesn't have any new changes, so you could actually run "git merge origin/main" after "git fetch origin" in the first example, but nothing would happen. I was trying to keep the example as simple as possible which is why I skipped the merge in the first example; however, there is no harm in running merge after every fetch. If there is nothing, then the merge will just output "Already up to date."

[@arithex]

One problem with Git, for us newbs, is that the installer asks a lot of questions we can't possibly know the answer to -- like, whether git pull should always do fast-forward, or never, or merge etc. I'm far enough along to understand the installer is just trying to "help me" set some defaults in the gitconfig .. but I'm still not sure I know what the right answer to that is, for my workflow.

[@themoderncoder]

Are you talking about the configuration options Git gives you the first time you run `git pull`?

[@arithex]

@themoderncoder No I mean literally the Git client installer .. on Windows, at least. As seen here kzbin.info/www/bejne/aqnUh6loobmiapI It asks us several inscrutable questions.. which OpenSSL and SSH to use, which credential-manager to use, how to mangle our line-endings, etc. The barrier to entry for newbs (even experienced sw engineers) is quite high. There are some videos covering some of this .. but your videos are typically much better :) so if you're looking for content ideas, there's probably some inspiration-material there.

[@themoderncoder]

@@arithex Ah I got you - thanks for linking that video.

[@adityakumarseth8934]

how is git fetch different from git pull ?

[@themoderncoder]

Fetch simply downloads the changes but doesn’t merge them. Pull is a combination of fetch and merge under the hood, so it downloads AND merges at the same time.

[@OpenDeepLearning]

First

[@themoderncoder]

Hey, my first "first"

[@vipinkoul595]

I am not able to understand what "HEAD" is, for example, I see HEAD->main and like origin/main , origin/HEAD. Can anyone help me understand this

[@themoderncoder]

HEAD is a pointer in our local repository used to indicate which branch is currently selected (i.e. checked-out). "HEAD > main" means that in our local repository the "main" branch is selected. "origin/HEAD" refers to the "HEAD" pointer in the "origin" repository. The syntax is slightly different but, "origin/main, origin/HEAD" in the logs is just indicating that the origin's HEAD pointer is referring to the main branch as well.

[@vipinkoul595]

@@themoderncoder Could you cover these fundamentals? It's very difficult to understand, please.

[@themoderncoder]

@@vipinkoul595 I'm putting together a series of in-depth fundamentals videos for LearnGit.io that covers this and other fundamentals. KZbin isn't the best platform for slow, deliberate tutorial videos. I'm still working on it, but email me ([e-mail]) and I'll send you a link to the video that covers branching and the HEAD commit.

[@vipinkoul595]

@@themoderncoder Thanks so much for the reply, grateful to you. I have sent you mail. BR

[@themoderncoder]

@@vipinkoul595 Cool, responded and sent you a link to the vid.