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.
(Command Line) Pull Requests I
Loading...
來自 Atlassian 的課程
Version Control with Git
300 個評分
從本節課中
Git Workflows
This module covers topics on how teams work with Git. Git is flexible enough to work with many types of projects and teams. The better you understand Git's capabilities, the more effectively to can use it in your projects. Topics include pull requests, centralized workflows, feature branch workflows, forking workflows and Gitflow workflows. This module concludes with a project in which you use Git with a Gitflow workflow.
與講師見面
Steve ByrnesInstructional Designer
This is the first of two videos on pull requests.
We will start with a pull request overview.
Pull requests are a feature of Git hosting sites such as Bitbucket and GitHub.
The ultimate goal of a pull request is to merge a branch into the project.
Pull requests enable team communication related to the work of the branch.
Notifications, related to the pull request, can be sent to team members.
Those team members can provide feedback or comments, and ultimately can a have
a say in approving the content, this can act as a form of code review.
There are two basic repository configurations related to pull requests.
The first one is a single remote repository, a pull request in a single
repository configuration is a request to merge a branch of the repository.
The second configuration involves two remote repositories,
in this configuration, a pull request is a request to merge a branch from
a forked repository into the upstream repository.
The fork approach is common if the submitter doesn't have write access to
the upstream repository.
You can create a pull request, which is also called opening a pull request,
anytime during the life of the branch.
You can open a pull request when you create the branch,
this enables the team to begin discussion on the work of the branch immediately.
You can also open a pull request when you want comments on the branch.
For example, you may be stuck implementing something and
want to ask the team for help.
And finally, you can open the pull request when you think the branch is ready for
review and merging.
As you can see,
a pull request can be opened at any time after the related branch is created.
Next we will discuss single repository pull requests.
Before making a pull request, you need to prepare to make the request.
To prepare to make the pull request, first you create a feature branch.
This is the branch that we hope will eventually be merged
into a longer running branch.
You can work on the future branch before opening a pull request, but
to start the team discussion,
you can also open a pull request immediately after creating the branch.
You then push the branch to the remote repository.
Let's look at an example of preparing for a pull request.
We start by creating and checking out a branch named featureX,
the -b option of the git checkout command creates the branch.
Then we do some work on the branch by creating a file named fileA.text,
we add the file to the staging area, we then commit the file.
Finally, we will execute the git push command,
pushing the featureX branch to the remote server.
The set-upstream option ensures that we set up a local tracking branch.
When we execute the git push command,
we can see a helpful message about creating a pull request for the branch.
That bitbucket URL can be used to open a pull request directly from your browser.
To open a pull request you can log into bitbucket,
navigate to your remote repository and click on Pull requests.
Here you can create or view any pull request related to the repository.
Let's create a pull request by clicking the create a pull request link.
You are presented with a pull request form to fill out.
You title your pull request, add a description of work done on the branch,
optionally specify specific reviewers of the pull request,
and then click Create pull request.
When a pull request has been submitted to you, you will see the pull request in your
Bitbucket dashboard, which is part of the Overview tab.
You can see here that we have no pull requests waiting for our review and
you can see the pull requests that we created.
When you are reviewing a pull request, you can see the full context of the request.
You can review the information of the pull request itself, you can see what has
change in the project, and you can see the comments that were made.
This is where you can add your own comments.
You can click Approve to add to the count of approvers of the pull request.
Your project might require a certain number of approvals before the merge is
allowed.
A person doing the merging of the pull request can gain confidence depending
on how many people approve it, and by who specifically approves it.
Click Decline to reject or remove the pull request.
Be careful if you do this because it cannot be undone.
Click Edit to update the pull request, you do not need to do this if you add a commit
to the branch, the pull request will automatically be updated.
Click Merge to begin the process of merging the branch,
remember that merging is the ultimate goal of the pull request.
You will then be asked to select a merge strategy.
You can create a merge commit or
you can squash, a squash will reduce the entire branch to one linear commit.
You don't have to use one of these strategies to perform the merge,
you can use your local client to merge the branch just as usual.
When you push the merge to the remote repository the pull request will
be closed.
After the merge, you can then delete the remote branch label.
Here we execute git push with the -d option to delete the featureX branch
label.
Here is a review of what we've discussed in this video.
Pull requests are opened using an online Git host such as Bitbucket of GitHub.
The ultimate goal of a pull request is to merge a branch, but
they also facilitate team discussion and approval.
You can open a pull request any time after creating the branch,
you do not need to edit the pull request if you add a commit to the branch.
You can merge the pull request using an online Git host or
by pushing the merge from your local client.
Now it's time to work on the topics discussed in this video,
separate hands on instructions are provided.
