The Version Control with Git course provides you with a solid, hands-on foundation for understanding the Git version control system. Git is open source software originally created by Linus Torvalds. Git manages team files for large and small projects. This allows the team to continuously improve its product. It is used by most major technology companies, and is assumed knowledge for many modern programming and IT jobs. It is a core component of DevOps, continuous delivery pipelines and cloud-native computing. You could also use Git to manage the many continuously improving revisions of that book that you are writing. In this course, you will not learn everything there is to know about Git, but you will build a strong conceptual understanding of the technology, and afterward will be able to confidently dig deeper on any topic that interests you. This course assumes no previous knowledge of Git, but if you do have experience with it, you may find this course to be both useful and challenging. This is especially true if you currently "know just enough Git to be dangerous". There are two paths in this course. Both rely heavily on hands-on labs. One path assumes that you have experience using a command line interface, and the other path uses the Sourcetree graphical client. If you are not experienced with a command line, we highly suggest that you go through the Sourcetree path. Eventually, you might want to go through both paths, so that you can decide which tool to use for specific tasks. Besides, repetition is good for learning :) You can watch the videos and take the quizzes from your phone if you want, but the hands-on labs require you to have a Windows or Mac computer. If you use the command line path through the course, you can also use Linux. This course uses Bitbucket (bitbucket.org) as the hosted provider for remote Git repositories. Bitbucket is free for teams of up to 5 people, including private repositories. However, most of the knowledge that you gain in this course applies to Git itself, and you can apply this knowledge to other hosted Git providers (such as GitHub). This course tries to be as concise as possible. It will probably take you about 5-10 hours to go through one of the two paths, but your mileage may vary.
DevOps and Git in a Nutshell
Loading...
Del curso dictado por Atlassian
Version Control with Git
199 calificaciones
De la lección
Our First Repository
This module gets you started using Git. It provides the foundation for the rest of the course. You will install Git and/or Sourcetree, create a local repository, create a commit, create a remote repository and push commits to a remote repository. You have the option of doing the hands-on labs using the Sourcetree graphical Git client and/or using a command line.
Conoce a los instructores
Steve ByrnesInstructional Designer
In this video, we will discuss how DevOps and Git are related.
If you're not familiar with DevOps,
it basically means modern software development practices.
If you're not familiar with the Git version control system,
then you're in the right place, because that's what this course is about.
We will start by discussing continuous improvement in general and
then see how Git is used to continuously improve your project.
DevOps has a few fundamental principles that most modern software projects follow.
One of the key principles is to continuously plan, build and
release small improvements to your product.
This is contrasted with what might be called the waterfall approach,
In which many features are planned, developed and released as one batch.
Continuous small changes to a product,
also known as small batch sizes leads to continuous improvement.
On left you'll see a product with a single bug,
on the right the only difference is that the single bug is removed.
Even though the change is small these are different versions of the product.
Small batch size also applies to features.
The version of the product on the left contains only blue icons.
The product on the right adds a single feature,
the ability to have multicolor icons.
Now that we know that modern products are continuously improved,
we will look at how Git helps manage the many versions of the product.
Let's say that our product is an application that currently contains 50
files of code.
We will call this our project.
We want to continuously improve this project.
We will now look at how Git helps to do that.
Git manages versions of products forming a project history.
Each version of a project is called a commit.
In this example the first version of the project is represented by commit A and
contains a bug.
The second version of the project is represented by commit B which differs from
commit A only in that the bug has been fixed.
Assuming the bug fix involves a change to only one of the 50 files,
Commits A and B only differ by that single file.
This is how small improvements can continuously be made to the product.
Git is really good at managing small changes like this.
A question that you may have right now is, is Git efficient?
We know that each commit is a snapshot of the entire project at
a given point in time.
With many small changes to the project,
you might think that Git stores many copies of the same file.
This is not how Git works however.
Behind the scenes, Git is very efficient at storing commits.
Each unique file is stored only once.
For example, after commit A, Git has stored 50 files.
Commit B only adds one file for Git to store, the file that contains the bug fix.
So after commit B, there are a total of 51 files stored.
We will learn more about how this works later.
The collection of commits contain the history of the project.
At any time you can review the projects history and
undo changes by going back to the previous version of the project.
In this example, commit A is the version of our product with only blue icons.
Commit B adds the multicolor icon feature to the product.
Let's say that customers don't like that feature for some reason, or worse,
adding that feature introduced some problems that you didn't foresee.
You can easily go back to a version of the product without the feature.
Either by going back to commit A, or
by adding a new commit that undoes the work of commit B.
Now that we've seen how commits helped managed the many versions of
a continuously improving project.
We will look at an important feature of Git called branches.
All commits belong to a branch.
A branch can be thought of as an independent line of development
of the project.
By default, there is a single branch and it's called master.
In this example, commits A, B, and C all belong to the master branch.
How do you maintain a stable project at the same time that you are working on it?
You can create a separate branch and work on it independently of the master branch.
Here a featureX branch was created, and
commit C includes content that is unique to the featureX branch.
In this case, the master branch does not know that the featureX branch exists.
The master branch thinks that the latest commit is B, even though separate work has
been done on commit C.
We've seen that branches can be used to independently work on the project without
disrupting the rest of the project.
Here the master branch sees the project as 50 stable files.
This commit has usually been tested, approved and
maybe the version of the product that is currently in production.
The featureX branch sees the same 50 files plus maybe one file that was added for
the new feature.
The independence of branches allow teams to scale their work.
In this example, the project can be in production at commit B and
separate development can be done on featureX, bugY, and featureZ.
Commit B on the master branch is not aware of or impacted by the other branches.
So far we've discussed the importance of many small changes to continuous
improvement.
We've seen that Git can manage the many versions of projects with commits and
that the project can be worked on independently using branches.
Finally, we'll discuss merging independent branches using pull requests.
When a branch is ready to become part of the master branch,
it can be merged into the master branch.
A merge combines the work of separate branches.
There are a few ways to merge in Git, which we'll discuss later.
In this example, before the merge,
featureX is implemented on its own branch which is also called featureX.
Before the merge, the master branch has no knowledge of the featureX branch.
After the merge, there's a single master branch with the latest commit,
including the code that implements featureX.
Before you merge content into the master branch,
how do you know that your changes are good?
A pull request is a request to merge your branch into another branch.
This request is usually made by developer of the branch when the feature, bug fix or
other change is complete.
In this example, the pull request is a request to merge the commit
that includes featureX into the master branch.
During a pull request team members can discuss, review, and approve your changes.
You can also require that automated test pass before
the merge is allowed to happen.
This helps ensure that the changes introduced by the merge don't
cause problems for the customer.
If the pull request is accepted, your version of the project is merged and
becomes the latest commit on the master branch.
You can feel good about the quality because the changes were reviewed and
automated tests have passed.
We have seen some of the ways that Git is fundamental to DevOps and
modern software development.
Git manages many small improvements to the project using commits,
it also allows simultaneous stability and development through branches.
And improves product quality using pull requests which can include review and
testing.
Explora nuestro catálogo
Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.
Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.
© 2018 Coursera Inc. Todos los derechos reservados.
