×

Wir verwenden Cookies, um LingQ zu verbessern. Mit dem Besuch der Seite erklärst du dich einverstanden mit unseren Cookie-Richtlinien.

image

Programming, Git It? How to use Git and Github

Git It? How to use Git and Github

[Music]

when it comes to development most tools

that you come across have a limited

shelf life but despite this constant

churn there's one thing that remains

consistent and that's good it's easy to

take it for granted but when you take a

step back you'll find that git has

completely revolutionized the software

world it's essentially a history book of

your code and services like github make

open source software accessible to the

world in today's video I'll show you the

basics of get along with some advanced

pro tips and I'll even invite you to

collaborate with me on a pull request on

github in exchange for a free sticker I

think that's a pretty good deal so if

you're new here like and subscribe and

I'll give you further instructions

throughout this video so what is get

exactly it's a version control system

but really what that boils down to is a

system for managing your files building

software is a series of small milestones

where each milestone is just writing

code and a bunch of different files your

app will constantly move from a state of

chaos to stability and gate gives you a

way to keep track of all of these

changes and it does so in a way that

allows you to create multiple branches

or paths that you can go down and then

merge them in later facilitating

collaboration between large groups of

developers so today I'm going to show

you how this all works by building a

piece of open source node software that

we can all collaborate on the software

itself is a command-line utility that

will allow you to encrypt your mailing

address and then add it to the github

repo so I can mail you a sticker in my

current working directory I just have an

index J s file and a package.json I'll

go ahead and click on the source control

icon and you'll notice it says no source

control provider is registered the first

thing we'll need to do is initialize get

to start tracking our files and there

are two ways we can do this we can

either do it directly in vs code or we

can do it from the command line you

should definitely try to memorize all

the commands I show you in this video

but it's often faster to run them with

vs codes integrated tooling and I'll

show you both methods throughout this

video so first we'll go ahead and run

get an it from the command line and

you'll see that initializes an empty git

repository in our current working

directory you'll notice it adds our two

files to the changes list in the source

control panel so this tells us which

files have changed since the previous

snapshot of the source code because

we're in a brand-new project both these

files have a u icon

which means untracked or that their

newly created on this working directory

now a quick pro tip when you initialize

it get repo it creates a hidden get

directory if you want to completely

uninitialized it or remove it from your

project you can just remove that

directory but be careful with that one

now a second pro tip is to install the

get lense plugin for vs code it embeds

all kinds of useful information directly

in your code and gives you this extra

panel where you can easily navigate your

git history the next important thing

when setting up a github repo is to

create a git ignore file you don't want

everything in source control for example

you definitely want to keep out any

sensitive private API keys and you'll

also want to filter out the source code

for your dependencies like your node

modules and any unnecessary log files

git will automatically look at this get

ignore file and filter out anything that

matches the file path or pattern you can

create this file manually but the pro

way to do it is to use AVS code plug-in

to automatically generate all the

defaults for your environment so that

saves us a bunch of time and now we can

move on to the next concept of how do I

take a snapshot or a commit of my

current working directory a commit is

like a page in a history book that has

its own unique ID and can't ever be

changed without get knowing about it the

first thing we want to do is stage the

files that we want included in this

commit use stage files by running git

add and you can add individual files or

the entire working directory by just

using a period and BS code makes it

really easy to stage or unstaged files

by just clicking the plus or minus

button and you can unstaged files from

the command line by running git reset

but be careful with this one because

there's a hard flag and if you use it it

will not only unstaged the files but

delete them forever so if we run that

one right now on our new project it will

delete everything and we'll have to

start over from scratch and with that

I'll give you one of my most important

pro tips which is to make many small

commits this practice will not only help

prevent catastrophic losses of code but

it will also just make your code changes

a lot easier to follow now we're ready

for our first command the first thing we

want to do is run git add to stage our

files then we run git commit with the EM

flag to add a descriptive message about

what we changed in our code a pro tip

here is to use an emoji to get more

github stars on your project because

github stars are the best way to tell

how good a software project really is

and you can also make your comments

multi-line to provide a summary on the

first line and then a more descriptive

set of changes on the second line you'll

notice that that takes the files out of

the stage changes and gives us a clean

working directory and it will tell us

exactly which files were created

modified or deleted as part of this

commit now if we go into our git lens

plug-in you can see we have a history of

code changes that we can navigate

through and see exactly which lines of

code changed up until this point we've

been working on what's called the master

branch which is like the main trunk on

the tree that contains the actual source

code that you're releasing and

delivering to your customers so what

happens when you have a stable code base

and you need to fix a bug or you want to

experiment with a new feature what

you'll typically do in git is create a

new branch based on your most recent

commit and go and fix the bug on the

separate branch and then merge it back

into the master branch once it's ready

this means we can have multiple

developers working on the same code base

on their own branches without stepping

on each other's toes you can see all the

current branches in your codebase by

running git branch which for us would

just be the master you can switch

between branches and get by running the

check out command in our case the branch

hasn't been created yet so we'll go

ahead and create it by using the be flag

and we'll give it a name of feature so

now any code that we write in here will

be isolated to this branch now we can

fast forward into the future and you'll

see I've written a bunch of code in this

branch so currently this code is just

sitting in the working directory so I

need to commit it to this feature branch

this time I'll run my commit directly in

vs code and then we can switch back to

the master branch and you'll see that

all of our new files disappear and we're

back to the original state on the master

at this point I'd like to point out that

you don't necessarily have to commit

your files before switching to the

master branch there's a another

mechanism to save your work in progress

if you're working on something that's

half-finished

or experimental you can use a command

called git stash this will save all of

your current changes without committing

them and then revert back to a clean

working directory then later at some

point in the future when you want to get

back to work you can either pop or apply

the changes in that stash to your

current working directory so kind of

just like it sounds you're stashing away

your current changes to be used at some

later point

so stashing is just a handy thing to

know and an alternative to committing

your code if you're not quite ready to

do so

in our case we're all done building our

feature so what we want to do now is

merge that feature into the master

branch so now we'll go ahead and check

out the master branch and then if we run

get merged with the name of our feature

branch it will merge the latest commits

from the feature into the master and

you'll notice the commit ID is the same

for both the feature and master branch

so that was a pretty simple use case but

merging is the place you're most likely

to run into problems because you might

be working on a feature branch and then

the master branch has changes that

eventually lead to merge conflicts on

the Left we have a line of code that we

implemented in our feature branch and

then on the right we have a new change

that happened in the master branch while

we are working that affected the same

line of code so merging these files is

not possible out-of-the-box because git

doesn't know which change to use the S

code will give you some options to

resolve these conflicts for example you

might accept the current change accept

the incoming change or Bowl when you run

into a conflict you'll want to first

review it and then a lot of times it's

best to just abort the merge all

together and fix the files manually I

already mentioned that it's a good

practice to implement a lot of small

commits because it's easier to fix a

conflict on one file as opposed to a

hundred files then in the previous

example we merged a feature branch into

the master branch but a lot of times

when you're working on a feature you'll

want to merge the master branch back

into your feature to get the latest code

because if something on the master

branch changes it means someone could

have been writing code in the same place

that you're writing code or there might

be some breaking changes that changed

the way your feature is going to work so

if you're working on a feature for an

extended period of time you'll want to

merge in the master branch any time it

changes or maybe once a day if it's a

really active repo now there's one last

pro tip that I want to give you that's

related to merging a lot of times on a

feature branch you'll create a lot of

different commits and these commits are

kind of irrelevant to what's going on in

the master branch you can see here that

our feature branch is three commits

ahead of our master branch and it has a

bunch of comments about adding useless

emojis to the code instead of merging

all of these commits into the master

branch you can use the squash flag to

squash them down into a single commit

when you do your merge this will keep

the change history nice and concise on

the master branch but still preserve all

of the original commits on the feature

branch itself when you merge with the

squash flag

it won't actually change the head commit

on the master branch so you'll need to

add an additional commit on your own

that says something like merged in

feature branch and that gives us a nice

compact change history on the master so

now that we know how to do all this get

stuff locally let's see how we can do it

remotely with github pushing a repo to

github is actually really easy first we

just need to create a repository on

github and then it will give us the

commands to run to push our code to this

location the first command is get remote

which connects your local code to this

remote repository and the second command

is get push which will actually push the

files to the remote repository so if we

run the commands and then refresh the

page we should see our code is now on

github that was super easy but the next

thing I want to show you is how to take

someone's existing code fork it create

some changes and then create a pull

request to merge your code into another

person's project and that's exactly what

you'll need to do to get the free

sticker so this is the typical pattern

that you'll see when contributing to any

open-source project

step one is to fork the existing project

forking will copy the code from the

source and make it a repo under your own

github account after you fork it you'll

then want to clone your fork to your

local machine so you can start making

changes to it the git clone command just

allows you to copy the code from a

remote repository to your local computer

once you have that cloned you can open

it up in vs code and in this case serial

first want to run npm install to install

the dependencies then you can run git

checkout flag be with my sticker as the

branch name which again will create and

move you into this new branch and then

i've added a special command to this

repo called npm run address and that's

going to prompt you for the information

that i need for your mailing address

when you're done with that it will print

out an encrypted base64 string from

there you'll go into the stickers

directory and create a new file that's

your github username dot txt

then you'll copy and paste this encoded

string into that file so just a side

note on security your address is going

into a public repo but it's encrypted

with the RSA algorithm this means that

you are able to encrypt data with the

public key but I'm the only one with the

private key that can decrypt it I have

the private key on a thumb drive which

I'll destroy after this giveaway and

hacking the private key by brute force

is essentially impossible

unless someone physically steals the

private key your address should be safe

in this public format but I do feel

obligated to give you that disclaimer

first now go ahead and save the text

file then run get ad and get commit with

whatever message you want to put in

there now we have all of the necessary

changes committed on our local machine

we'll need to push this branch to our

remote fork for that we can just say git

push origin with the branch name and

that will push the branch to github then

on github you'll see the option to

create a new pull request a pull request

is just like a merge but it has the

additional step of needing to pulling

the remote changes in other words a pull

request is like saying pulling my remote

changes and then merge them into the

master branch so that's how you

contribute to an open-source project I'm

gonna go ahead and wrap things up there

hopefully that leaves you with some of

the basic tools needed to contribute to

open source software there's a whole lot

more that can be covered on this topic

so let me know what you want to see next

in the comments and if you want to get

really good at this kind of stuff

consider becoming a pro member at

angular firebase com thanks for watching

and I'll talk to you soon

Learn languages from TV shows, movies, news, articles and more! Try LingQ for FREE

Git It? How to use Git and Github Git|||||||Github Git It? Wie man Git und Github benutzt Git It? How to use Git and Github ¿Git? Cómo utilizar Git y Github ギット・イット?GitとGithubの使い方 Git It? Jak korzystać z Git i Github Git It? Como utilizar o Git e o Github Понял? Как использовать Git и GitHub Git It? Git ve Github nasıl kullanılır? git 吗?如何使用 Git 和 Github git 吗?如何使用 Git 和 Github

[Music]

when it comes to development most tools jeśli chodzi o rozwój większości narzędzi когда дело доходит до разработки большинства инструментов

that you come across have a limited ||come|||| z którymi się spotykasz, mają ograniczoną liczbę с которыми вы столкнулись, имеют ограниченный

shelf life but despite this constant shelf||||| shelf life but despite this constant okres przydatności do spożycia, ale pomimo tej stałej срок годности, но, несмотря на этот постоянный

churn there's one thing that remains constant change||a single element|||remains churn there's one thing that remains churn, pozostaje tylko jedna rzecz

consistent and that's good it's easy to Reliable|||||| spójny i dobrze, że łatwo

take it for granted but when you take a assume / accept|||granted||||| darlo por sentado, pero cuando to coś oczywistego, ale kiedy

step back you'll find that git has step back you'll find that git has cofnij się, przekonasz się, że git ma

completely revolutionized the software

world it's essentially a history book of świat jest zasadniczo książką historyczną o

your code and services like github make

open source software accessible to the oprogramowanie open source dostępne dla

world in today's video I'll show you the świat w dzisiejszym filmie pokażę ci

basics of get along with some advanced podstawy dogadywania się z niektórymi zaawansowanymi

pro tips and I'll even invite you to profesjonalne wskazówki, a nawet zaproszę Cię do

collaborate with me on a pull request on |||||code contribution request|| colabore conmigo en un pull request en współpracuj ze mną przy pull request na

github in exchange for a free sticker I github w zamian za darmową naklejkę I

think that's a pretty good deal so if Myślę, że to całkiem dobra oferta, więc jeśli

you're new here like and subscribe and jesteś tu nowy polub i zasubskrybuj i

I'll give you further instructions Przekażę ci dalsze instrukcje

throughout this video so what is get during all of|||||| w całym tym filmie, więc co to jest

exactly it's a version control system dokładnie jest to system kontroli wersji

but really what that boils down to is a ||||comes down to|||| but really what that boils down to is a ale tak naprawdę sprowadza się to do

system for managing your files building system do zarządzania tworzeniem plików

software is a series of small milestones ||||||Key achievements software is a series of small milestones oprogramowanie to seria małych kamieni milowych

where each milestone is just writing ||Writing benchmark||| where each milestone is just writing gdzie każdy kamień milowy jest po prostu napisany

code and a bunch of different files your |||variety of|||| kod i kilka różnych plików twój

app will constantly move from a state of aplikacja będzie stale przechodzić ze stanu

chaos to stability and gate gives you a chaos do stabilności i brama daje

way to keep track of all of these sposób na śledzenie ich wszystkich

changes and it does so in a way that zmienia się i robi to w sposób, który

allows you to create multiple branches umożliwia tworzenie wielu oddziałów

or paths that you can go down and then |routes||||||| lub ścieżki, którymi możesz zejść, a następnie

merge them in later facilitating merge them in later facilitating połączyć je w późniejszym ułatwieniu

collaboration between large groups of

developers so today I'm going to show deweloperów, więc dzisiaj pokażę

you how this all works by building a jak to wszystko działa, budując

piece of open source node software that ||||Node.js software|| kawałek oprogramowania węzła open source, który

we can all collaborate on the software wszyscy możemy współpracować nad oprogramowaniem

itself is a command-line utility that |||||command-line tool| samo w sobie jest narzędziem wiersza poleceń, które

will allow you to encrypt your mailing ||||secure your mailing|| umożliwia szyfrowanie korespondencji

address and then add it to the github a następnie dodać go do github

repo so I can mail you a sticker in my ||||send you|||physical label|| repo, więc mogę wysłać ci naklejkę w moim

current working directory I just have an bieżący katalog roboczy Mam tylko plik

index J s file and a package.json I'll plik index Js i plik package.json, który będę

go ahead and click on the source control go ahead and click on the source control śmiało i kliknij kontrolę źródła

icon and you'll notice it says no source |||||||No source found. i zauważysz, że nie ma źródła

control provider is registered the first dostawca kontroli jest zarejestrowany jako pierwszy

thing we'll need to do is initialize get ||||||Set up get| thing we'll need to do is initialize get rzecz, którą musimy zrobić, to zainicjować get

to start tracking our files and there aby rozpocząć śledzenie naszych plików i tam

are two ways we can do this we can Możemy to zrobić na dwa sposoby

either do it directly in vs code or we albo zrób to bezpośrednio w kodzie vs lub we

can do it from the command line you możesz to zrobić z wiersza poleceń

should definitely try to memorize all zdecydowanie należy spróbować zapamiętać wszystkie

the commands I show you in this video polecenia, które pokazuję w tym filmie

but it's often faster to run them with ale często szybciej jest uruchomić je za pomocą

vs codes integrated tooling and I'll vs kody zintegrowanego oprzyrządowania i będę

show you both methods throughout this pokażę ci obie metody w tym

video so first we'll go ahead and run video so first we'll go ahead and run wideo, więc najpierw pójdziemy do przodu i uruchomimy

get an it from the command line and pobrać go z wiersza poleceń i

you'll see that initializes an empty git you'll see that initializes an empty git zobaczysz, że inicjalizuje pusty git

repository in our current working repozytorium w naszej bieżącej pracy

directory you'll notice it adds our two katalog zauważysz, że dodaje nasze dwa

files to the changes list in the source pliki do listy zmian w źródle

control panel so this tells us which panel sterowania, więc to mówi nam, który

files have changed since the previous pliki zmieniły się od poprzedniego

snapshot of the source code because migawka kodu źródłowego, ponieważ

we're in a brand-new project both these

files have a u icon |||under review| pliki mają ikonę u

which means untracked or that their co oznacza, że nie są śledzone lub że ich

newly created on this working directory nowo utworzony w tym katalogu roboczym

now a quick pro tip when you initialize now a quick pro tip when you initialize teraz krótka wskazówka podczas inicjalizacji

it get repo it creates a hidden get get repo tworzy ukryty get

directory if you want to completely katalog, jeśli chcesz całkowicie

uninitialized it or remove it from your not set up|||Delete|||

project you can just remove that projekt można po prostu usunąć

directory but be careful with that one ale należy być ostrożnym z tym katalogiem

now a second pro tip is to install the Drugą profesjonalną wskazówką jest zainstalowanie

get lense plugin for vs code it embeds Pobierz wtyczkę lense dla vs kod, który osadza

all kinds of useful information directly wszelkiego rodzaju przydatne informacje bezpośrednio

in your code and gives you this extra w twoim kodzie i daje ci to dodatkowe

panel where you can easily navigate your panel, w którym można łatwo nawigować

git history the next important thing git history the next important thing historia git kolejną ważną rzeczą

when setting up a github repo is to podczas konfigurowania repozytorium github to

create a git ignore file you don't want create a git ignore file you don't want utworzyć plik git ignore, którego nie chcesz

everything in source control for example na przykład wszystko w kontroli źródła

you definitely want to keep out any Zdecydowanie należy unikać

sensitive private API keys and you'll wrażliwe prywatne klucze API i będziesz

also want to filter out the source code chcę również odfiltrować kod źródłowy

for your dependencies like your node dla zależności takich jak węzeł

modules and any unnecessary log files moduły i wszelkie niepotrzebne pliki dziennika

git will automatically look at this get git will automatically look at this get git automatycznie spojrzy na to get

ignore file and filter out anything that zignorować plik i odfiltrować wszystko, co

matches the file path or pattern you can pasuje do ścieżki pliku lub wzorca, który można

create this file manually but the pro create this file manually but the pro utworzyć ten plik ręcznie, ale pro

way to do it is to use AVS code plug-in Sposobem na to jest użycie wtyczki kodu AVS

to automatically generate all the aby automatycznie wygenerować wszystkie

defaults for your environment so that domyślne dla danego środowiska, tak aby

saves us a bunch of time and now we can oszczędza nam mnóstwo czasu i teraz możemy

move on to the next concept of how do I przejść do następnej koncepcji, jak mogę

take a snapshot or a commit of my take a snapshot or a commit of my zrobić migawkę lub zatwierdzenie mojego

current working directory a commit is bieżącym katalogiem roboczym jest

like a page in a history book that has jak strona w książce historycznej, która

its own unique ID and can't ever be własny unikalny identyfikator i nigdy nie może być

changed without get knowing about it the zmieniono bez wiedzy użytkownika

first thing we want to do is stage the Pierwszą rzeczą, którą chcemy zrobić, jest ustawienie

files that we want included in this pliki, które chcemy uwzględnić w tym

commit use stage files by running git commit use stage files by running git

add and you can add individual files or

the entire working directory by just

using a period and BS code makes it

really easy to stage or unstaged files

by just clicking the plus or minus

button and you can unstaged files from

the command line by running git reset the command line by running git reset

but be careful with this one because

there's a hard flag and if you use it it

will not only unstaged the files but

delete them forever so if we run that

one right now on our new project it will

delete everything and we'll have to

start over from scratch and with that |||begin from nothing|||

I'll give you one of my most important

pro tips which is to make many small

commits this practice will not only help

prevent catastrophic losses of code but

it will also just make your code changes

a lot easier to follow now we're ready

for our first command the first thing we

want to do is run git add to stage our want to do is run git add to stage our

files then we run git commit with the EM files then we run git commit with the EM

flag to add a descriptive message about flag to add a descriptive message about

what we changed in our code a pro tip

here is to use an emoji to get more

github stars on your project because

github stars are the best way to tell

how good a software project really is

and you can also make your comments

multi-line to provide a summary on the

first line and then a more descriptive first line and then a more descriptive

set of changes on the second line you'll

notice that that takes the files out of

the stage changes and gives us a clean

working directory and it will tell us

exactly which files were created

modified or deleted as part of this

commit now if we go into our git lens ||||||||Git extension tool commit now if we go into our git lens

plug-in you can see we have a history of

code changes that we can navigate

through and see exactly which lines of

code changed up until this point we've

been working on what's called the master

branch which is like the main trunk on ||||||Main stem|

the tree that contains the actual source ||||the specific||

code that you're releasing and

delivering to your customers so what

happens when you have a stable code base

and you need to fix a bug or you want to

experiment with a new feature what

you'll typically do in git is create a you'll typically do in git is create a

new branch based on your most recent

commit and go and fix the bug on the

separate branch and then merge it back

into the master branch once it's ready

this means we can have multiple

developers working on the same code base

on their own branches without stepping ||||Not using|placing their feet

on each other's toes you can see all the ||each other's|steps on toes|||||

current branches in your codebase by

running git branch which for us would running git branch which for us would

just be the master you can switch

between branches and get by running the

check out command in our case the branch

hasn't been created yet so we'll go

ahead and create it by using the be flag

and we'll give it a name of feature so

now any code that we write in here will

be isolated to this branch now we can

fast forward into the future and you'll

see I've written a bunch of code in this

branch so currently this code is just

sitting in the working directory so I

need to commit it to this feature branch

this time I'll run my commit directly in

vs code and then we can switch back to

the master branch and you'll see that

all of our new files disappear and we're

back to the original state on the master

at this point I'd like to point out that ||||||moment, mention||

you don't necessarily have to commit

your files before switching to the

master branch there's a another

mechanism to save your work in progress

if you're working on something that's

half-finished

or experimental you can use a command

called git stash this will save all of |version control tool|temporarily store changes||||| called git stash this will save all of

your current changes without committing

them and then revert back to a clean

working directory then later at some

point in the future when you want to get

back to work you can either pop or apply ||||||quickly return||

the changes in that stash to your the changes in that stash to your

current working directory so kind of

just like it sounds you're stashing away just like it sounds you're stashing away

your current changes to be used at some

later point

so stashing is just a handy thing to |temporarily saving changes|||||| so stashing is just a handy thing to

know and an alternative to committing

your code if you're not quite ready to

do so

in our case we're all done building our

feature so what we want to do now is

merge that feature into the master

branch so now we'll go ahead and check branch so now we'll go ahead and check

out the master branch and then if we run

get merged with the name of our feature get merged with the name of our feature

branch it will merge the latest commits

from the feature into the master and

you'll notice the commit ID is the same

for both the feature and master branch

so that was a pretty simple use case but

merging is the place you're most likely

to run into problems because you might

be working on a feature branch and then

the master branch has changes that

eventually lead to merge conflicts on

the Left we have a line of code that we

implemented in our feature branch and put into action|||||

then on the right we have a new change

that happened in the master branch while

we are working that affected the same

line of code so merging these files is

not possible out-of-the-box because git not possible out-of-the-box because git

doesn't know which change to use the S

code will give you some options to

resolve these conflicts for example you

might accept the current change accept

the incoming change or Bowl when you run the incoming change or Bowl when you run

into a conflict you'll want to first

review it and then a lot of times it's

best to just abort the merge all |||Cancel|||

together and fix the files manually I together and fix the files manually I

already mentioned that it's a good

practice to implement a lot of small

commits because it's easier to fix a

conflict on one file as opposed to a |||||"contrasted with"||

hundred files then in the previous

example we merged a feature branch into example we merged a feature branch into

the master branch but a lot of times

when you're working on a feature you'll

want to merge the master branch back

into your feature to get the latest code

because if something on the master

branch changes it means someone could

have been writing code in the same place

that you're writing code or there might

be some breaking changes that changed

the way your feature is going to work so

if you're working on a feature for an

extended period of time you'll want to

merge in the master branch any time it

changes or maybe once a day if it's a

really active repo now there's one last

pro tip that I want to give you that's

related to merging a lot of times on a

feature branch you'll create a lot of

different commits and these commits are

kind of irrelevant to what's going on in ||Not pertinent to|||||

the master branch you can see here that

our feature branch is three commits

ahead of our master branch and it has a

bunch of comments about adding useless

emojis to the code instead of merging

all of these commits into the master

branch you can use the squash flag to

squash them down into a single commit

when you do your merge this will keep

the change history nice and concise on |||clear|||

the master branch but still preserve all

of the original commits on the feature

branch itself when you merge with the

squash flag

it won't actually change the head commit

on the master branch so you'll need to

add an additional commit on your own

that says something like merged in

feature branch and that gives us a nice

compact change history on the master so

now that we know how to do all this get

stuff locally let's see how we can do it

remotely with github pushing a repo to

github is actually really easy first we

just need to create a repository on

github and then it will give us the

commands to run to push our code to this

location the first command is get remote

which connects your local code to this

remote repository and the second command

is get push which will actually push the

files to the remote repository so if we

run the commands and then refresh the

page we should see our code is now on

github that was super easy but the next

thing I want to show you is how to take

someone's existing code fork it create

some changes and then create a pull

request to merge your code into another

person's project and that's exactly what

you'll need to do to get the free

sticker so this is the typical pattern

that you'll see when contributing to any

open-source project

step one is to fork the existing project

forking will copy the code from the duplicating||||||

source and make it a repo under your own

github account after you fork it you'll

then want to clone your fork to your

local machine so you can start making

changes to it the git clone command just

allows you to copy the code from a

remote repository to your local computer

once you have that cloned you can open

it up in vs code and in this case serial

first want to run npm install to install

the dependencies then you can run git

checkout flag be with my sticker as the

branch name which again will create and

move you into this new branch and then

i've added a special command to this

repo called npm run address and that's

going to prompt you for the information

that i need for your mailing address

when you're done with that it will print

out an encrypted base64 string from

there you'll go into the stickers

directory and create a new file that's

your github username dot txt

then you'll copy and paste this encoded

string into that file so just a side

note on security your address is going

into a public repo but it's encrypted

with the RSA algorithm this means that

you are able to encrypt data with the

public key but I'm the only one with the

private key that can decrypt it I have

the private key on a thumb drive which

I'll destroy after this giveaway and

hacking the private key by brute force

is essentially impossible

unless someone physically steals the

private key your address should be safe

in this public format but I do feel

obligated to give you that disclaimer

first now go ahead and save the text

file then run get ad and get commit with

whatever message you want to put in

there now we have all of the necessary

changes committed on our local machine

we'll need to push this branch to our

remote fork for that we can just say git

push origin with the branch name and

that will push the branch to github then

on github you'll see the option to

create a new pull request a pull request

is just like a merge but it has the

additional step of needing to pulling

the remote changes in other words a pull

request is like saying pulling my remote

changes and then merge them into the

master branch so that's how you

contribute to an open-source project I'm

gonna go ahead and wrap things up there

hopefully that leaves you with some of

the basic tools needed to contribute to

open source software there's a whole lot

more that can be covered on this topic

so let me know what you want to see next

in the comments and if you want to get

really good at this kind of stuff

consider becoming a pro member at

angular firebase com thanks for watching

and I'll talk to you soon