Explore
For Enterprise
Join for Free
Log In

Гуманитарные науки и искусства
Бизнес
Компьютерные науки
Наука о данных
Информационные технологии
здоровье
Математика и логика
Личное развитие
Естественные и технические науки
Социальные науки
Изучение языков
Степени и сертификаты

Полный обзор Coursera

Обзор
Поиск
Для организаций
Войти
Присоединиться бесплатно

(Command Line) Merging

Loading...

Version Control with Git

4.7 (оценок: 443) | Зарегистрировано учащихся: 21K

Просмотреть программу курса

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.

Получаемые навыки

Version Control, Github, Bitbucket, Command-Line Interface

Рецензии

4.7 (оценок: 443)

5 stars
343 ratings
4 stars
88 ratings
3 stars
8 ratings
2 stars
1 ratings
1 star
3 ratings

LO

Jun 04, 2018

This course did a great job of stepping me through GIT concepts. The videos and exercises were helpful - I feel comfortable applying what I learned in this course to other projects.

TS

Nov 23, 2018

I am excited about this course! The information set out clearly, in details, with quality basics. There are also advices how to work with git in real world) Very nice ^^

Из урока

Branching and Merging I

This module discusses to of the key concepts involved with Git: branching and merging. It starts with foundational knowledge on Git's commit graph model, Git IDs and references. Branching and merging are then covered, including the difference between fast-forward merges and using merge commits.

(Sourcetree) Merging13:33

(Command Line) Merging13:20

Преподаватели

Steve Byrnes
Instructional Designer

In this video we will discuss merging.

We will start with the merging overview.

Merging combines the work of independent branches.

Usually, this involves merging a topic branch, such as the featureX branch,

into what is called a base branch, such as the master branch.

The base branch is usually a longer running branch than the topic branch.

In this example, the work of the two branches is combined into a single commit

named M, which we will see later is called a merge commit.

Prior to the merge, the master branch didn't know about the featureX branch.

After the merge, the work of featureX is included in the master branch.

Notice that after the merge commit, commit B is part of the featureX branch and

the master branch.

If we trace back from commit M to the initial commit,

we can see that there's a path that includes commit B.

If we trace the path of the featureX branch,

we can see that it contains commits B and A.

If we trace the two paths of commit M,

we can see that all of the commits are included.

In fact, we could color commit B half green since it belongs to both branches.

For simplicity, in the rest of this course we will keep the commits a single color.

But keep in mind that a commit often belongs to more than one branch.

There are four main types of merges, fast-forward merge,

merge commit, squash merge, and rebase.

We will talk about the first two in this video and the last two later.

Next we will discuss fast-forward merges.

A fast-forward merge moves the base branch label to the tip of the topic branch.

In the before example, on the left, we can see that we have a base branch

called master and a topic branch called featureX.

Commit A was made to the master branch and then a featureX branch was created.

Commits B and C were created on the featureX branch.

If at this point, the featureX branch is ready to be merged into the master branch,

a fast-forward merge can be executed.

As you see on the right, a fast-forward merge simply involves moving the master

label from commit A to commit C.

After the fast-forward merge,

both branches contain exactly the same commits, C, B, and A.

All three commits are exactly the same as they were before the merge,

only the master branch label was moved.

The master branch now contains the work of featureX and the merge is complete.

A fast forward merge is possible only if no other commits have been made to

the base branch since the topic branch was created.

If any commits have been added to the base branch,

it will not allow you to perform a fast-forward merge.

In this example, a fast-forward merge is not possible

because commit D was created after the featureX branch was created.

If git had allowed a fast-forward merge, the master

branch label would move to commit C, and the work of commit D would be bypassed.

Whoever did the work of commit D would not be very happy with that, so

the merge is not fast-forwardable.

Here are the basic steps to performing a fast-forward merge.

Start by checking out the base branch, which in this case is the master branch.

Then use the git merge command, specifying featureX as an argument.

A fast-forward merge is the default way that git will attempt the merge.

Assuming the merge is successful, you can then delete

the featureX branch label using the -d option of the git branch command.

The diagram on the right shows the state after the fast-forward merge.

Let's perform a fast-forward merge,

first we use the git log command to view our current commit graph.

We can see that there are two commits,

the oldest commit includes the master branch label.

The most recent commit includes the feature 2 branch label.

Let's say that we are finished with feature 2 and

are ready to merge with the master branch.

The first thing we do is check out the master branch,

the feature 2 branch will be merged into this branch.

We then execute the git merge command,

passing the feature2 branch level as an argument.

You can see that git replied that this was a Fast-forward merge.

Git will always try to perform a fast-forward merge unless you tell

it not to.

Now we can view our commit graph again, and

see that the latest commit contains both the master and feature2 labels.

The fast-forward merge simply moved to the master branch label to the latest commit.

We can then delete the feature2 branch label using the git branch command with

the -d option.

One last view of the commit graph shows that we have a nice clean history with

the master branch containing the work of feature2.

As we have just seen, after a branch has been merged,

its branch label can be deleted.

This prevents a continuous increase in the number of merged branch labels

as the project grows.

Dealing with an ever increasing number of feature branch labels can be confusing.

If you'd like to retain the knowledge of where the feature work occured,

you can include this information in the feature's commit messages.

Or you can add a tag that permanently marks the feature work.

Even though we have deleted the merged branch label here, whether or

not you should delete the branch label's after a merge is a decision that your

team should make.

We can see with a fast-forward merge, the resulting commit history is linear,

there are no commits that have multiple parents.

Next, we will discuss merge commits.

A merge commit combines the work of the tips of the feature and base branches and

places the result into a single merge commit.

In this example,

the featureX branch was merged into the master branch using merge commit M.

The project M commit M will include featureX, which is included in commit C.

As well as anything else that is in commit E, the previous tip of the master branch.

A merge commit always has multiple parents.

We can see here that the commit M has two parents, commits C and E.

Because of this non-linear commit graph,

it's easy to see the branch in the commit history.

Combining the work of multiple commits may result in what's called a merge conflict,

if both branches change the same thing in different ways.

We will discuss merge conflicts later, and for now,

we will assume that the merge will be successful.

Performing a merge with a merge commit is basically the same as performing

a fast-forward merge.

The steps are to check out the base branch, merge the topic branch, and

then optionally to delete the topic branch label.

Git will automatically attempt to create a merge commit

if the merge is not fast forwardable.

While executing the git merge command,

git will open an editor showing a default merge message.

This is the commit message for the merge commit, you can accept or

modify the default merge message.

In this example, before the merge,

you have a featureX branch based off of commit A of the master branch.

Two commits, D and

E, were made to the master branch since the featureX branch label was created.

Because the master branch has moved along since the featureX branch commit was

created, this merge is not fast-forwardable.

After the merge, you have a merge commit M containing a combination of the featureX

branch and the latest master branch commit E.

All of the commits shown then belong to the master branch, and

you have a nonlinear commit graph.

Like with fast-forward merges, the feature branch label can be deleted to

prevent an ever increasing number of branch labels.

In this case, the nonlinear commit graph clearly shows the branches and merges.

In some cases, you might have a situation where a merge is fast forwardable,

but you would rather have a merge commit.

For example, your team's policy might be to

always merge feature branches using merge commits.

This is so you can clearly see the branches in the commit graph.

A no fast-forward merge means that a merge commit will always be created,

even if the merge is fast-forwardable.

The steps to perform a no fast-forward merge are similar to the steps for

the other merges.

The only exception is that you include the --no-ff option with the git merge command,

this will always create a merge commit.

In the before example on the left, the featureX branch is fast-forwardable.

Because no commits have been made to the master branch since we created

the featureX branch.

After the no fast forward merge, we have a merge commit, and

our feature branch history is easy to see.

The project files in commit M are exactly the same as the project files in commit C.

Because no other changes were made to the project on the master branch.

In this case, the difference between a fast-forward merge and a merge

commit is only in the project history information, not in the project files.

In this example, we will perform a merge using a merge commit,

even though the merge is fast forwardable.

We will ensure that a merge commit is made using the --no-ff option with the git

merge command.

We start by looking at the commit graph.

Notice that this graph is the same starting graph as in the previous example,

with the initial commit having the master branch label.

And the current commit having the feature 2 label.

Next we check out the master branch so

that we can begin the merge of the feature2 branch.

Next we will execute the git merge command, passing in the --no-ff option.

We specified the feature2 branch label as an argument.

At this point your default git editor will open with a default merge

message of merge branch feature2, we will accept the default merge message.

After saving the merge message git will perform the merge.

Merges are made with things called strategies which are ways to perform

a merge.

This strategy is called the recursive strategy.

We can then view the commit graph, you can see that the current commit is a merge

commit containing the merge message that we entered.

That commit has two parents, the first parent is the tip of the feature2 branch,

and the second parent is the initial commit.

You can see that this commit graph is similar to the one shown on the right.

Optionally, you can then delete the feature2 label.

All of the commits belong to the master branch, so

the feature2 label is not needed.

Different teams may have different policies on what to do with

fast-forwardable merges, and with merges in general.

They may require a linear history to keep things clean,

they may require merge commits to clearly see the branch history.

Or they may let the person doing the merging decide what to do.

In addition to merging topic branches into long-running branches,

some teams periodically merge long-running branches into other long-running branches.

These merges are usually easy,

because they are fast-forwardable, even if a merge commit is used.

In this example commits are made to the develop branch

as the project is worked on.

The master branch stays at commit A.

Commit A may be the most recent release that the project's customers are using.

When the develop branch is at a point where the team wants to release it,

they can perform either a fast-forward merge.

Or use a simple merge commit, as shown here with commit G.

Either way, the merge is easy because the project files in commit G

are exactly the same as the files in commit F.

Here is a review of what we've discussed in this video.

Merging combines the work of multiple branches.

A fast-forward merge moves the base branch label to the tip of the topic branch.

A merge is fast-forwardable if no other commits have been made to the base branch

since the branch was created.

A merge commit is the result of combining the work of multiple commits.

A merge commit has multiple parents.

Now it's time for you to work on the topics discussed in this video,

separate instructions are provided for you.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2019 Все права защищены.

Загрузить из App Store

Загрузить в Google Play

Coursera
О проекте
Руководство
Карьера
Каталог
Сертификаты
Сертификаты MasterTrack™
Степени
Для организаций
Для правительственных организаций

Сообщество
Learners
Partners
Developers
Beta Testers
Translators

На связи
Блог
Facebook
LinkedIn
Twitter
Instagram
YouTube
Технический блог

Еще
Условия
Конфиденциальность
Помощь
Доступность
Пресса
Контакты
Справочник
Филиалы