META FRONT END DEVELOPER PROFESSIONAL CERTIFICATE

VERSION CONTROL META

LECTURE COURSE 3/9

Subscribe to more Courses.
COLLABORATOR CHANNELS
YOUCOURSE - COURSES FROM BEST UNIVERSITYS IN THE WORLD - https://www.youtube.com/@YouCourse
ARQUITECTURAS - ARCHITECTURE CHANNEL, DOCUMENTALS AND MORE - https://www.youtube.com/@ArquitecturasYT
CADESIGNERS - SOFTWARE CHANNEL AND MODELS - https://www.youtube.com/@CADesigners
UNDERGROUND - Subscribe! Free Music - Creative Commons - https://www.youtube.com/@UndergroundMC

FACEBOOK GROUPS
ARQUITECTURAS - ARCHITECTURE CHANNEL - https://www.facebook.com/groups/arquitecturasyt
YOUCOURSE - COURSES FROM BEST UNIVERSITYS IN THE WORLD - https://www.facebook.com/groups/youcourse/
CADESIGNERS - SOFTWARE DESIGN CHANNEL - https://www.facebook.com/groups/cadesignersyt
UNDERGROUND - Free Music - Creative Commons - https://www.facebook.com/groups/undergroundyt

Facebook - https://www.facebook.com/YouCourseYT
Twitter - https://twitter.com/YouCourseYT
Tik Tok - https://www.tiktok.com/@youcourseyt
Kwai - YouCourse - @yourcourse

WEEK 1 - Software collaboration
00:00 - Introduction to the course 3m
03:25 - How do developers collaborate in the real world? 4m
08:01 - What is version control? 4m
12:54 - Case study: how Meta engineers collaborate 4m
17:04 - Systems of version control and tools 3m
20:54 - A history of revisions 3m
24:30 - Module Summary: Software collaboration 1m

WEEK 2 - Command Line
26:13 - The Command line 6m
32:16 - What are Unix commands? 4m
36:35 - Using Bash on Windows 3m
40:20 - Change directories and list contents 4m
44:51 - Creating and moving directories and files 3m
48:38 - Pipes 2m
51:27 - Redirection 7m
58:53 - Grep 3m
1:02:03 - Module Summary: Command Line 1m

WEEK 3 - Working with Git
1:03:31 - What is Git and GitHub? 3m
1:06:44 - Creating and cloning a repository 4m
1:11:39 - How Git works 3m
1:15:04 - Add and commit 4m
1:19:44 - Branches 6m
1:26:23 - Remote vs. local 5m
1:31:44 - Push and pull 4m
1:36:03 - Example workflow 3m
1:39:48 - HEAD 5m
1:45:29 - Diff commands 4m
1:49:51 - Blame 6m
1:55:53 - Module Summary: Working with Git 1m

WEEK 4 - Graded Assessment
1:57:14 - Course recap: Version Control 2m
1:59:57 - Congratulations, you have completed Version Control 1m

----- SEE YOU IN THE COURSE 4 - HTML AND CSS IN DEPTH ---------

Don't forget to subscribe and like that helps me keep uploading videos

Thank's For Support!

WEEK 1 - SOFTWARE COLLABORATION

In this module, you will learn about how modern software developers collaborate across the world without messing up each other's code. This involves using version control or subversion to bring order to the chaos of massive software projects that have the potential for mistakes and bugs. You will look at the different version control systems and how to create an effective software development workflow.

Objetivos de aprendizaje

- Describe how modern software teams collaborate and work on the same codebase.

- List different version control systems and methodologies.

- Illustrate a standard software development workflow.

Course syllabus

Version Control

In this course, you will learn about how modern software developers collaborate across the world without messing up each other's code. You will look at the different version control systems and how to create an effective software development workflow. You will be introduced to some of the most commonly used Linux commands that you can use to work with files on your hard drive and create powerful workflows that will automate your work, saving you time and effort. Finally, you will see how Git can be used in software development projects to manage team files, you will create a repository that can manage code revisions.

After completing this course, you will be able to:

- Implement Version Control systems.

- Navigate and configure using the command line.

- Manage code revisions.

- Create and use a GitHub repository.

The modules and resources that you will work through and explore in this course will help you to prepare for the Exam:

Below is an outline of the modules that will be covered in this course:

Module 1: Software Collaboration

In this module, you will learn about using version control or subversion to bring order to the chaos of massive software projects that have the potential for mistakes and bugs. You will look at the different version control systems and how to create an effective software development workflow.

After completing this module, you will be able to:

1. Describe how modern software teams collaborate and work on the same codebase.

2. List different version control systems and methodologies.

3. Illustrate a standard software development workflow.

Module 2: Command Line

In this module, you will learn how to use the command line to execute commands in Linux. You will be introduced to some of the most commonly used commands that traverse, create, rename, and delete files on your hard drive. You will learn how easy it is to use piping and redirection to create powerful workflows that will automate your work, saving you time and effort.

After completing this module, you will be able to:

1. Describe how the command line is and how it is used.

2. Practice traversing your hard drive via the command line.

3. Create, rename and delete files and folders on your hard drive using Unix commands.

4. Use pipes and redirection.

Module 3: Git

This module will help you to develop a strong conceptual understanding of the Git technology and how it is used in software development projects to manage team files. You will install Git, create a local repository, create a commit, create a remote repository and push commits to a remote repository.

After completing this module, you will be able to:

1. Outline the Git principles.

2. Use a GitHub repository.

3. Describe the steps in a standard GitHub workflow.

4. Create branches and merge different branches and sources.

5. Describe how code goes from local development to version control and then to live production.

Module 4: Graded Assessment

In the final module, you'll learn about the graded assessment. After you complete the individual units in this module, you'll synthesize the skills you gained from the course to manage a project on GitHub.

You'll also have to opportunity to reflect on the course content and the learning path that lies ahead.

After completing this module, you will be able to:

1. Recap on all of the topics covered throughout the course.

2. Apply all the skills you have learned in a graded project.

Practical Exercises

We encourage you to complete the practical exercises in this course. By completing these exercises you will have a more practical understanding of how to explore Version Control.

How to be successful in this course

Taking an online course can be overwhelming. How do you learn at your own pace and successfully achieve your goals?

Here are some general tips that can help you stay focused and on track.

Set daily goals for studying

Ask yourself what you hope to accomplish in your course each day. Setting a clear goal can help you stay motivated and beat procrastination. The goal should be specific and easy to measure, such as "I’ll watch all the videos in Module 2 and complete the first programming assignment". And don’t forget to reward yourself when you make progress towards your goal!

Create a dedicated study space

It’s easier to recall information if you’re in the same place where you first learned it, so having a dedicated space at home to take online courses can make your learning more effective. Remove any distractions from the space and if possible, make it separate from your bed or sofa. A clear distinction between where you study and where you take breaks can help you focus. 

Schedule time to study on your calendar

Open your calendar and choose a predictable, reliable time that you can dedicate to watching lectures and completing assignments. This helps ensure that your courses won’t become the last thing on your to-do list.

Tip: You can add deadlines for a Coursera course to your Google calendar, Apple calendar, or another calendar app.

Keep yourself accountable

Tell your friends about the courses you’re taking, post achievements to your social media accounts or blog about your homework assignments. Having a community and support network of friends and family to cheer you on makes a difference!

Actively take notes

Taking notes can promote active thinking, boost comprehension and extend your attention span. It’s a good strategy to internalize knowledge whether you’re learning online or in the classroom. So, grab a notebook or find a digital app that works best for you and start synthesizing key points.

Tip: While watching a lecture on Coursera, you can click the 'Save Note' button below the video to save a screenshot to your course notes and add your own comments.

Join the discussion

Course discussion forums are a great place to ask questions about assignments, discuss topics, share resources and make friends. Our research shows that learners who participate in the discussion forums are 37% more likely to complete a course. So make a post today!

Do one thing at a time

Multitasking is less productive than focusing on a single task at a time. Researchers from Stanford University found that “People who are regularly bombarded with several streams of electronic information cannot pay attention, recall information or switch from one job to another as well as those who complete one task at a time.” Stay focused on one thing at a time. You’ll absorb more information and complete assignments with greater productivity and ease than if you were trying to do many things at once. 

Take breaks

Resting your brain after learning is critical to high performance. If you find yourself working on a challenging problem without much progress for an hour, take a break. Walking outside, taking a shower or talking with a friend can help you to re-energize and even give you new ideas on how to tackle the project.

Your learning journey starts now! 

While preparing for the module quiz or working on achieving your learning goals you're encouraged to:  

- Work through each lesson in the learning pathway. Try not to skip any activities or lessons unless you are certain that you already know this information well enough to move ahead.   

- Take the opportunity to go back and watch a video or read all the information provided before moving on to the next lesson or module. 

- Complete all the knowledge and module quizzes and exercises.

- Read the feedback carefully when answering quizzes, as this will help you to reinforce what you are learning. 

- Make use of the practical learning environment provided by the exercises. You can gain substantial reinforcement of your learning through the step-by-step application of your skills.

Version Control Git terminology

A history of version control

As you know by now, version control is a system that records changes to a file or set of files over time so that you can access specific versions later. In software development, Version Control Systems (VCS) allows developers to manage changes to their code and track who made each change. But how did this software come about?

Version Control has a long history going back to the 1980s. In fact, version control systems were created before the Internet!

One of the first significant Version Control Systems was the Concurrent Versions System (CVS). It was first developed in 1986 by Walter F. Tichy at Purdue University and released publicly in 1990.

CVS stores information about every file in a folder structure, including the name of the file, its location in the folder structure, who last modified it, and when it was last modified. The CVS also stores information about folders, including their names and who created them.

It was popular for many years; however, it has some significant flaws in its design. CVS does not include integrity checks which means your data can become corrupted. When you update or submit changes to the system, if an error occurs, the system accepts the partial or corrupted files. Additionally, the system was designed mainly for text files, not binary files such as images or videos.

The main successor to CVS was Subversion (SVN).

CollabNet developed Subversion in 2000 and solved many of the issues present in CVS. To ensure data integrity, it included integrity checks in its design. It also supported the versioning of binary files better than CVS. Thanks to these improvements, SVN became popular in the open-source community with free hosting being offered for open-source projects by Google and SourceForge.

However, Subversion used a centralized VCS model. This means that all operations have to be done using a centralized server. If the server were down or slow, this would impede development.

In 2005, two new projects were started to develop distributed version control systems; Mercurial and Git. Both projects were created in response to an event involving the Linux kernel development.

Previously, the Linux kernel was using a proprietary VCS known as BitKeeper. BitKeeper was one of the first distributed version control systems initially released in 2000. BitKeeper had originally provided a free license to Linus Torvalds to support Linux’s development. However, in 2005, the license was revoked. This controversy led to the creation of the Mercurial and Git projects.

Mercurial was developed by Olivia Mackal. It is developed as a high-performance distributed VCS. Many platforms offering Subversion hosting began to offer Mercurial hosting too. It became popular as Subversion users found it easy to transition to a Mercurial repository, thanks to the hosting providers and its small learning curve.

Git was developed by Linus Torvalds to host the Linux kernel’s source code. Like Mercurial, it is a distributed VCS. Its first public release came in 2007.

Git became popular in the open-source community due to its distributed VCS design and Github offering free Git hosting for open-source projects. Git has since become the selected version control system for many open-source and proprietary software projects.

Version control in professional software development

Version Control plays a crucial part in software development. As a developer, you’ll work with other developers on projects to deliver software to customers. Depending on the role, you could be working with a small team of 2 or 3 developers in a single project or a large team spanning multiple projects. In either scenario, Version Control will be a crucial tool to help your team succeed.

However, Version Control must be complemented by other tools and procedures to ensure quality and efficiency throughout the software development process. In this lesson, we’ll explore some of the common tools and strategies developers use in conjunction with Version Control.

Workflow

Using Version Control without a proper workflow is like building a city without traffic lights; without appropriate management, everything will turn into chaos.

For example, let’s say you’re working on a big project and editing a file. Another developer also starts editing a file. Both of you submit the file to the VCS at the same time. Now there’s a conflict! How should the conflict be resolved? A good workflow will have a process for resolving conflicts.

Another example is when a new junior developer is joining your team. If the project code is used for a critical system, it is risky to allow them to submit code changes directly. To solve this, many developers use a peer review system where another developer must review code before it can be merged in.

Workflows are essential to ensure code is managed correctly and reduce mistakes from happening. Different projects will have different workflows. In this course, you’ll learn some common workflows using the Git Version Control System.

Continuous Integration

Continuous Integration, or CI, is used to automate the integration of code changes from multiple developers into a single main stream. Using a workflow whereby small changes are merged frequently, often many times per day, will reduce the number of merge conflicts.

This process is widespread in test-driven software development strategies. CI is often used to automatically compile the project and run tests on every code change to ensure that the build remains stable and prevent regressions in functionality.

Continuous Delivery

Continuous Delivery is an extension of Continuous Integration. Once the changes have been merged into the main stream, a Continuous Delivery system automatically packages the application and prepares it for deployment. This helps avoid human error when packaging the application.

Continuous Deployment

Continuous Deployment is an extension of Continuous Delivery. The goal of Continuous Deployment is to deploy and release software to customers frequently and safely. The strategy commonly involves automatically deploying to a test (also known as staging) environment first to validate the deployment package and software changes. Once validated, it can automatically deploy to the live (also known as production) environment for customers.

Conclusion

With these tools and procedures, it is possible to understand how software starts from a developer writing code to being deployed live for customers to use. Of course, there is much more to running a live software service, but that is a lesson for another day.

Staging vs. Production

Development Environments

Every development team prior to releasing their new features or changes needs to verify that the code they do release is not going to cause any issues or bugs. In order to achieve this, they normally set up multiple environments for different ways to test and verify. A common practice is for teams to have a developer environment, a UAT or QA environment, and a staging environment. The main purpose of this flow is to find any potential issues that may arise due to changes or new features being added to the codebase. The more ways to test the changes the less likely bugs will be introduced.

Staging

The staging environment should mimic your production environment. The reason for this is because you want to test the code in an environment that matches what you have in production. This allows teams to spot or find any potential issues prior to them getting to production. The closer the staging environment is to your production, the more accurate your testing is going to be. Staging environments can also be used for testing and verifying new features and allow other teams including QA or stakeholders to see and use those features as a pre-trial. Staging should also cover all areas of the architecture of the application including the database and any other services that may be required. Areas that benefit from staging environments include:

New Features

Developers submitting new features along with feature flags for turning them on and off should always do a testing round in a staging environment. They allow teams to verify that the feature works, it can be turned on and off via configuration flags and also that it does not break or interfere with existing functionality.

Testing

As the staging environment mimics your production environment, it's also a great place to run tests. QA teams will normally use it to verify new features, configuration changes or software updates/patching. The types of testing covered will be Unit testing, Integration testing and performance testing. All except performance testing can also be carried out in production. Performance can also be completed in production but only at specific times - usually out of hours as it will have a drastic effect on the user experience.

Sometimes it is not always feasible to have an exact replication either due to costs or time. Certain areas can be cut back - for example, if your service is load balanced on 10 virtual machines in production, you could still have 4 virtual machines in staging. The underlying architecture is the same but the overall performance may be different.

Migrations

Staging is a perfect place to test and verify data migrations. Snapshots can be taken from production and used to test your migration scripts to confirm your changes will not break anything. If in the case it does cause an issue, you simply rollback and try again. Doing something like a migration in production is extremely risky and error-prone.

Configuration Changes

Configuration can also cause headaches for teams, especially in a large cloud-based architecture. Having a staging environment will allow you to spot any potential issues or bottlenecks.

Production

Production is live. It's out there for people to see and/or interact with. Any issues or problems you may have had should have been caught and fixed in the staging environment. The staging area gives the team a safety net to catch these possible issues. Any code that is deployed to production should have been tested and verified before the deployment itself.

Downtime

Downtime for any service especially customer facing will most likely be revenue impacting. If customers can not access or use your website or app to its full capabilities, it will most likely have a cost involved. Take for example an e-commerce company that allows users to buy goods and services online. If they release a new feature to their shopping cart which actually breaks the payment process, this will have an impact on customers not being able to buy goods online.

Vulnerabilities

Cyber-security should also play a big role in what gets released in production. Any updates to software such as patching or moving to the latest version should be checked and verified. This is also the same rule for not upgrading software when critical updates are released.

Reputation

Downtime or issues in production is damaging for a company as it does not instill confidence in end users. If something is down or broken it can cause the company to lose potential customers.

Additional Resources

About Version Control
https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

List of Version Control Software
https://en.wikipedia.org/wiki/List_of_version-control_software

The benefits of a distributed version control system
https://about.gitlab.com/topics/version-control/benefits-distributed-version-control-system/

What is Cloning?
https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository

WEEK 2 - COMMAND LINE

In this module you will learn how to use the command line to execute commands in Linux. You will be introduced to some of most commonly used commands that traverse, create, rename, and delete files on your hard drive. You will learn how easy it is to use piping and redirection to create powerful workflows that will automate your work, saving you time and effort.

Objetivos de aprendizaje

Describe how the command line is and how it is used.
Practice traversing your hard drive via the command line.
Create, rename and delete files and folders on your hard drive using Unix commands.
Use pipes and redirection.

Using Bash on Mac Terminal

Learning Objectives

Learners will understand how to open the command line - terminal on mac
Learners will become familiar with the most common commands.

Mac Terminal

The Terminal on Mac can be open in one of three ways, Finder, Launch Pad and Spotlight.

Finder

Scroll to the bottom on your desktop and click on the Finder icon
Click on Applications on the left hand side
Locate the folder called Utilities and expand it
The Terminal app should be visible, click it to open

Launch Pad

Press the F4 command
Launch Pad view will appear
In the search bar, click it and type the word Term - short for terminal
The Terminal icon will appear on screen
Click to open

Spotlight

Press the Command Key and the Space Bar
The Spotlight modal will appear
Type in the word Terminal or Term for short
The Terminal icon will appear
Click to open

Bash commands

Bash provides a list of commands that helps you navigate through files, view contents of files and also edit features to change or update the contents of a file. Below is a list of the most common commands:

cd: Change Directory

ls: List command used for showing the content of a directory.

rm: Remove command used for removing a file or a directory

mv: Used to move files or folders to another location

touch: Allows creating of a new empty file or to upate a timestamp on a file

cp: Used to make a copy of a file or foldler

mkdir: Make a new directory

pwd: Print work directory, shows the current location in the shell

cat: Allows reading or concatenation of a file

less: Displays the contents of a file one page at a time.

grep: Global regular expression, allows for searching contents of files or folders

Flags

Every bash command has flags which will allow you to change the output of the command itself. For example, the ls command is used to print out the list of contents inside a directory. If we wanted to show the list in a different view, we simply need to add a flag such as -l.

When the flag of -l is passed it will show the output in a different way:

Man Pages

When first starting to learn commands from bash it can feel a bit dauting. Luckily every command comes with its own manual or man pages for short. The man page will list all the flags and options that a particular command has to offer. Again, lets use the ls command to demonstrate this. Type the following:

The man pages are a great way to recall the different flags that are available and a great tool in your arsenal to becoming more fluent in bash.

Editing

To edit files in bash you have quiet a few options. The most common though is usually VI or Vim. VI stands for visual editor and it allows you to make edits and changes to a file and save them. Its very similar to what you may have used in applications like word. VIM is a better version of VI with some improvements - hense its name visual editor improved. Learning the different commands in Vim will feel a bit different coming from GUI applications but once you practice it will feel like second nature. Vim uses modes to determine the commands you can work with:

Normal mode: Default mode
Insert mode: Allows the contents of the files to be edited.
Command line mode: Normal commands begin with :

Additional Resources

Agile methodologies

https://www.planview.com/resources/guide/agile-methodologies-a-beginners-guide/

Installing git on mac and windows, detailed instructions.

https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Bash Reference Manual

https://www.gnu.org/software/bash/manual/html_node/index.html#SEC_Contents

Bash Redirections

https://www.gnu.org/software/bash/manual/html_node/Redirections.html#Redirections

Bash Cheatsheet

https://devhints.io/bash

Grep Cheatsheet

https://devhints.io/grep

Grep Manual

https://man7.org/linux/man-pages/man1/grep.1.html

History and Timeline of Unix

https://unix.org/what_is_unix/history_timeline.html

History of Vim

https://en.wikipedia.org/wiki/Vim_(text_editor)

How to work with relative and absolute paths

https://www.geeksforgeeks.org/absolute-relative-pathnames-unix/

Unix Commands Cheatsheet

https://cheatography.com/jluis/cheat-sheets/bash-and-unix-commands/

Vim Cheatsheet

https://vim.rtorr.com/

WEEK 3 - WORKING WITH GIT

Objetivos de aprendizaje

Outline the Git principles.
Use a GitHub repository.
Describe the steps in a standard GitHub workflow.
Create branches and merge different branches and sources.
Describe how code goes from local development to version control and then to live production.

Installing Git on Windows

Git works on all operating system platforms such as Windows, Mac, and Linux. On Mac or Linux, in some cases, it is installed by default. The majority of users will use Git via the command line as its syntax is very easy to understand and follow. Git also works well in development environments and integrates into IDEs and other GUI offerings.

Go to https://gitforwindows.org/ and download the latest version.

Once the download is complete, open the installation file and follow the instructions for installing.

After installation, open the Git Bash application. You can also use the windows command line.

To see what version of git was installed type git version and press the Enter key.

You should see something similar to the following output.

$ git version
git version 2.34.1.windows.1

Installing Git on Mac

Macs tend to have git installed by default, so before diving into the installation we can run a git version command to check if git is already installed. If the command returns a git version, then git is already installed. If it returns "command not found", git needs to be installed.

Install with Xcode

Install the latest version of Xcode for your Mac by downloading it from the Apple Store or going to the official website - https://developer.apple.com/xcode/

Install Git from Homebrew

Homebrew is a popular package manager for Macs. It’s easy to use and makes it simple to install new packages such as git. First, you will need to install Homebrew on your machine. Go to the Homebrew website at https://brew.sh/ and follow the install instructions for Mac. Once Homebrew is installed, open a terminal window and then type the command brew install git

Once installed run the git version command to verify the installation is complete.

Create your GitHub account

Throughout this course, you'll be using Github to practice working with repositories. In this lesson, you'll learn how to set up your Github account.

Step 1: Go to Github in your web browser

Step 2: Click the Sign-up button in the top right of the screen.

Step 3: Enter your email address

Step 4: Choose a strong password

Step 5: Enter a username

Step 6: Complete the security question

Step 7: Click Create Account

Step 8: You will then receive a confirmation email to confirm your address.

The email will contain a code. Enter this code on the confirmation screen.

Once the code is added, you will have access to your Github account!

Connecting to GitHub via HTTPS

When using Github via the Coursera platform, it is required to authenticate using a Personal Access Token over HTTPS. A Personal Access Token is a special password that you use instead of your actual account password. When you're finished using the token, you can revoke it so that it can no longer be used. It is also possible to set an expiry time for the token. This helps to keep your account secure.

Generate a Personal Access Token

We now need to set up our Personal Access Token.

Step 1: Log in to Github

Step 2: Click on the profile icon in the top right of the screen and select Settings.

Step 3: On the Settings screen, on the left-hand side click Developer Settings.

Step 4: On the Developer Settings screen, click Personal Access Tokens and then click Generate Token.

Step 5: On the New Personal Access Token page, enter a token name and an expiry time. If you wish to manually revoke the token, set the expiry time to No Expiration.

Step 6: Under scopes, select repo.

Step 7: Scroll to the end of the page and click Generate token.

Step 8: The token is now generated. Make sure to copy and keep note of the token as it will be hidden when you leave the page. This token can now be used when connecting to a repository over HTTPS.

Note: If you lose the token, you can delete the old token and create a new one.

Accessing Repositories

When accessing a repository and using HTTPS authentication, make sure to always use the HTTPS address of the repository.

Connecting to GitHub via SSH

If you plan to use Github from your local device, the recommended way to authenticate is using Secure Shell, or SSH for short. This requires the creation of keys: a public and a private key. The advantage of using SSH is that you don't need to enter in your credentials when interacting with the remote repository. The keys are generated and stored on your local machine and then the public key is copied to the Github server. After you finish setting up, every operation will be authenticated using the keys.

Generate SSH keys

The process is the same for both Windows and Mac. On Windows, you can use the Git Bash terminal and on Mac, the standard terminal will work.

Open the terminal
Enter the following: ssh-keygen -t ed25519 -C "your@email.com"
Replace the email with your own and press enter.
It will prompt to enter a password. Hit enter to skip setting a password and do the same for entering the same passphrase again.

Generating public/private ed25519 key pair.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in ./ssh/private_key.

Your public key has been saved in ./ssh/public_key.pub.

The key fingerprint is:

SHA256:UDQI5N1FL3QSq7Gj1o12mkr9Me7qGMZAeE1s9BWIln4 your@email.com

The key's randomart image is:

+--[ED25519 256]--+

| .o+o=+oOo. |

| o +B+.= = |

| . +++ + o . |

| o ..E+ . |

| . .S |

| o + + |

| B = = |

| + + * o |

| oo=o+ |

+----[SHA256]-----+

5. Once you have confirmed it will generate the above to confirm the keys have been created.

6. Both keys will be stored in the .ssh folder.

7. In order to add our key to Github, we need to get a copy of the public key which is always identified as .pub in your local directory.

Find the name of the key file using the below command.

ls ~/.ssh/

Then, use the below command to copy the file, replacing the <YOUR KEY> with the name of the key file on your device.

pbcopy < ~/.ssh/<YOUR KEY>.pub

Adding Your Keys to Github

We now need to add our public key to Github to grant access to the repositories we create.

Step 1: Log on to Github

Step 2: Click on the profile icon in the top right of the screen and select Settings.

Step 3: On the Settings screen, on the left-hand side under the Access section, click SSH and GPG Keys

Step 4: Click the New SSH key button in Green on the right-hand side of the screen.

Step 5: Enter a title and paste in your public key that you copied previously.

Step 6: Click the Add SSH key button.

You are now ready to access Github via SSH.

Accessing Repositories

When accessing a repository and using SSH authentication, make sure to always use the SSH address of the repository.

Resolving conflicts

Conflicts will normally occur when you try to merge a branch that may have competing changes. Git will normally try to automatically merge (auto-merge), but in the case of a conflict it will need some confirmation, the competing changes need to be resolved by the end user. This process is called merging or rebasing.

The developer must look at the changes on the server and the changes on their local and validate which changes should be resolved.

A merge conflict example is when two developers are working on their own dependent branches. Both developers are working on the same file called Feature.js. Each of their tasks is to add a new feature to an existing method. Developer 1 has a branch called feature1 and developer 2 has a branch called feature2.

Developer 1 pushes the code with the changes to the remote repository. Developer 2 pushes their changes.

Forking

In previous lessons, you have touched on workflows such as branching and how they can be used to simplify a process for a team. Forking is another type of workflow. The key difference between branching and forking is that the workflow for forking creates a new repository entirely. Branching cuts a new branch from the same repository each time and each member of the team works on the single repository.

Let's take a simple example of how forking works. In the diagram below the coolgame repo has been forked by Joe. The entire contents and the history of the repository are now stored in Joe's account on GitHub. Joe is now free to make edits and changes to the repository at his own will. You, the owner of the coolgame repository can continue to work as normal and not know about Joe's edits or changes.

Joe created a new branch on his repository and added a new cool feature that he felt was needed. In order for Joe to get his feature back into the original repository, he will need to create a PR as normal but instead of comparing with the main branch, it needs to be compared with the original repository. Essentially the two repositories are compared against each other. The owner of the original repository can then review the PR and choose to accept of decline the new feature.

Let us take a look at how you can fork an existing repository that is available on GitHub. For this example, let's fork the forking lesson repository.

Step 1: Go to https://github.com/Meta-Front-End-Developer-PC/forking-lesson

Step 2: Click on the Fork button on the top right of the page.

Step 3: It will then prompt you to fork the repository to your desired account. Choose the account you wish to fork to.

Step 4: Github will then clone the repository into your chosen GitHub account.

In a couple of steps, you have successfully forked a repository into our own GitHub account. The full repository is cloned and allows us to work directly in that repository as if it was our own.

On the landing page of the GitHub repository, it will show directly under the repository name that it was forked from Meta-Front-End-Developer-PC/forking-lesson.

Other subtle differences in the GitHub UI on a forked branch is the top information bar above the files.

It now shows that the branch is up to date with forking-lesson:main. It also adds a Fetch upstream drop-down to allow you to pull and merge the latest changes from the original repository.

Example

Let's run through a typical flow of creating a new branch and adding some new content.

Step 1: Clone the repository.

Step 2: Create a new branch.

git checkout -b test/forking-example

Step 4: Create a new file and commit it to the repository.

touch text.txt

git add .

git commit -m 'chore: testing'

Step 5 Push the branch to your remote repository.

git push -u origin test/forking-example

Step 6: Go to Github and click the Compare & pull request button. If it's not available, click on the branch dropdown button and change it from main to the branch name of test/forking-example:

After clicking the Compare & pull request button it will now redirect to the original repository in order to create the PR.

Each repository will have its own guidelines for submitting PRs against them and usually provide a how-to contribute guide. As you can see, in order to get the changes from our forked repository, you need to compare it against the original. This gives a lot of control to the repository owners of the original and they get to decide what makes the cut to be merged in.

In this lesson you covered the basics of forking a repository, adding some changes, and then creating a PR to get it back to the original repository.

Additional Resources

GitHub: Pricing

GitHub is free to use, but it also offers different pricing models to suit the needs of different-sized teams and organizations. Check out the link below:

https://github.com/pricing

Git: An Origin Story

https://www.linuxjournal.com/content/git-origin-story

Git Cheatsheet

https://education.github.com/git-cheat-sheet-education.pdf

Git patterns and anti-patterns for successful developers

https://youtu.be/t_4lLR6F_yk

Tech Talk: Linus Torvalds on git

https://www.youtube.com/watch?v=4XpnKHJAok8

Vim Cheatsheet

https://devhints.io/vim

WEEK 4 - GRADED ASSESSMENT

In this module, you will be assessed on the key skills covered in the Course.

Objetivos de aprendizaje

Apply the skills and knowledge from this course on Version Control in a practical assessment

About this graded assessment

The purpose of the graded assessment

The main purpose of a graded assessment is to check your understanding of the key learning objectives of the course you have just completed. Most importantly, graded assessments help you establish which topics you have mastered and which topics require further focus, before you can complete the course. Ultimately, the graded assessment is designed to help you make sure that you are ready for the next course in this program.

Prepare for the graded assessment

You have encountered exercises, knowledge checks, in-video questions and other assessments as you have progressed through the course. Nothing in the graded assessment will be outside what you have covered already, so you should be well placed to succeed.

Review the graded assessment

Please review the feedback after taking the assessment and where necessary go back and work through the topics that you feel require your further attention.

Good luck!

Solution: Managing a project in GitHub

In the previous exercise, you used diff to inspect the changes to class.txt.

When you ran the command, you saw the following changes.

This output shows us the following:

Green was removed
Blue was added
Ivory was removed
Charcoal was added
Gray was removed
Purple was added

The diff command is useful for inspecting file changes. GitHub also provides online diff tools. You've seen these when submitting a pull request.

You can also historically view changes.

Go to the forked repository and click the commits.

Click on the hash of the commit you made.

This will open the online diff viewer for this specific commit.

You'll use diff tools often while managing your GitHub repository. They're very useful for reviewing file changes and investigating when bugs were introduced to code.

Next steps, after completing Version Control

Congratulations! You've completed this course and taken another step toward improving your knowledge, skills, and qualifications.

Version control is a practice that spans the whole spectrum of web and mobile development, so is therefore a valuable ability in any aspiring developers skillset.

You are now ready to move on to the next course in this program, where you will continue your journey in developing skills to build dynamic, responsive and interactive apps.

Be sure to take the next course. It’s your chance to gain further insight into the world of software development.

THANK'S FOR READING

martes, 21 de marzo de 2023

C3 - VERSION CONTROL META - COURSE 3/9

META FRONT END DEVELOPER PROFESSIONAL CERTIFICATE

VERSION CONTROL META

Foundations: Data, Data, Everywhere