هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
Create a GitHub account
In this lesson, you’ll be sharing changes on GitHub, so you’ll need a GitHub account. If you don’t already have one, you can create an account by visiting github.com and clicking “Sign up for GitHub”.
When you’re asked to choose a plan, you can choose a free plan, since we won’t be using any of the paid features in this course.
Set up Password Caching
Every time you send changes to GitHub via the command line, you’ll need to type your password to prove that you have permission to modify the repository. This can get annoying quickly, so many people like to set up password caching, which will let you type your password once and have it auto-filled on that computer in the future. To do this, follow the instructions here. If you’re using Windows and you followed our Git installation instructions earlier, you’re using msysgit, so you can follow the instructions for msysgit.
https://www.youtube.com/watch?v=I5UA_ULHnnY
Copy the HTTPS URL, not the SSH URL!
At 1:29, Caroline copies the URL to the repository. The video mistakenly shows the URL to use if the repository is accessed over SSH. The course assumes that the student will use HTTPS, not SSH. Please click on the HTTPS button and copy the URL that shows up for HTTPS. It will begin with https:// rather than git@github.com.
If you are interested in using SSH instead, you can follow the instructions here, but this is not recommended unless you are already familiar with SSH keys.
Sharing your reflections
We encourage you to be bold in sharing your reflections on GitHub. If you’re not happy with any of your responses, the best solution is to update that response in one or more new commits. The previous response will still be visible in the commit history, but updating your perspective over time is part of the learning process! Having a commit history that shows your updating perspective will reflect well on you, not poorly.
That said, if you’ve written anything in your reflections repository that you are not comfortable sharing, you can checkout the commit before you introduced that change, create a new branch at that point, and commit any other changes you are willing to share to the new branch. Then, by only pushing your new branch, you can keep the changes on your original branch private.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
Make changes on GitHub
Now that you’ve seen how to create a remote repository and push changes to it, use the GitHub website to create a new file for your lesson 3 reflections and add the below question and your thoughts on it.
If you prefer to start from the file lesson_3_reflection_prompts.txt in the Downloadables section, you can download that file, commit it locally, push to GitHub, then add your response using the GitHub website.
Reflect: Using a remote repository
Use the following reflection prompt:
When would you want to use a remote repository rather than keeping all your work local?
When you’re finished committing your changes, click “Next” to see how to pull those changes to your own computer.
المواد الداعمة
Concept Map: GitHub, Push, Pull, Remote
We’ve introduced a few new concepts since we last revisited our concept map.
- GitHub
- git push
- git pull
- remote
Previous Version
Here’s what the map looked like the last time we added new concepts.
Where Do the New Concepts Go?
There’s wasn’t a lot of screen real estate left, so we pruned off some of the concepts from last lesson that aren’t tightly entwined with the new ones that will come up this lesson, and added in nodes for the new concepts.
Which concept belongs where?
In the following quiz, write in the concept that you think belongs in each new empty node.
Remember that this map is subjective, so what we have here may not fit your mental model exactly; feel free to draw out the connections you see between the concepts and share your version on the forums!
Reflect: Manual vs. automatic pull
Now that you’ve both pushed changes to GitHub, and pulled changes from GitHub, add the following question and your thoughts on it to your reflections file:
Why might you want to always pull changes manually rather than having Git automatically stay up-to-date with your remote repository?
You may also want to commit and push your changes. When you’re finished, click “Next” and Sarah will go over what to do if you want to share your changes to a repository and you don’t have permission to modify the original.
Add a new recipe to the repository
On your own computer, add a new recipe for a food that you like and commit it on the master branch.
Push your changes
Push the master branch to your fork. If you’re having trouble remembering how to push, you may want to rewatch this video. When you’re finished, continue to the next screen to answer a question about where your commit exists at different points in time.
Where was your commit?
Before you ran git push, your change should have only existed locally via git log. Commits will not automatically be shared to remotes – you have to manually push your branch if you want to share changes.
After you ran git push, your change should have existed locally and on your fork. It should not have existed on Larry’s repository, which is the repository you forked. The reason you forked in the first place is because you don’t have permission to change Larry’s repository!
هل لديك أي أسئلة؟ اذهب إلى
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Reflect: Forks, Clones, and Branches
Now that you’ve seen how you can make a copy of a repository on GitHub by forking it, go add the the following question and your thoughts on it to your reflections file:
Describe the differences between forks, clones, and branches. When would you use one instead of another?
You may also want to commit and push your changes. When you’re finished, click “Next”.
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
Simulate Sarah’s Changes
In the Downloadables section, there is a file called sarah_changes.sh, which contains code to make it look like Sarah has modified your fork on GitHub. To run the code, download the file, then using Git Bash or your terminal, cd to the directory where you’ve saved it. Then type bash sarah_changes.sh followed by a space, followed by the url to your fork. For example, if Caroline were running the code, she would type bash sarah_changes.sh https://github.com/cbuckey-uda/recipes.git, but you should use the url for your fork, not Caroline’s fork. If you haven’t set up password caching, then you will be prompted to enter your GitHub username and password.
Which commits exist where?
The commit by Larry adding the chili recipe should have been in both places, since it was present in the original repository before you forked it. Your commit adding a new spice should only have been present locally, since you made the commit locally but didn’t push. The commit by Sarah removing cumin should only have been present on GitHub, since Sarah made the change and pushed it to GitHub, but you didn’t pull yet.
You can download sarah_changes.shhere.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
المواد الداعمة
Reflect: Local copies of remote branches
Now that you’ve seen how to update your local copy of remote branches, and how to combine conflicting changes from multiple people, add the following question and your thoughts on it to your reflections file:
What is the benefit of having a copy of the last known state of the remote stored locally?
You may also want to commit and push your changes. When you’re finished, click “Next” and Caroline will introduce a GitHub feature called a Pull Request that makes collaboration easier.
https://www.youtube.com/watch?v=jOMom5aUfDM
Instructions
Suppose you run each of the given commands in order with the local master branch checked out. Check each place (working directory, staging area, local master, or GitHub master) where the files would be changed by that command.
Sarah accidentally says that the local master is the only thing that changes when you run git pull origin master. However, the working directory and staging area will also update when you run git pull. That’s why when you run git pull, you see your files update, not just the git log output.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
Reflect: Collaboration using Git and GitHub
Now that you’ve seen how multiple people can share changes to a project using GitHub, and review proposed changes using pull requests, go add the following question and your thoughts on it to your reflections file:
How would you collaborate without using Git or GitHub? What would be easier, and what would be harder?
You may also want to commit and push your changes. When you’re finished, click “Next”.
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
You can download sarah_changes_2.sh here
Simulate Sarah’s changes
To simulate Sarah’s changes, first download the file sarah_changes_2.sh from the Downloadables section. Then, using Git Bash or your terminal, cd to the directory where you’ve saved the file. Then type bash sarah_changes_2.shfollowed by a space, followed by the url to your fork. For example, if Caroline were running the code, she would type bash sarah_changes_2.sh https://github.com/cbuckey-uda/recipes.git, but you should use the url for your fork, not Caroline’s fork. If you haven’t set up password-caching, then you will be prompted to enter your GitHub username and password.
Note: This code will not actually create a pull request. Instead, it will update the commit history on GitHub to make it look as though the pull request has already been merged. You will not need to merge a pull request. Instead, check for a commit on the master branch on GitHub with the message “Merge pull request”.
Make sure you are on the master branch
You’ll want to make sure you check out the master branch before following the steps in this video.
Make sure you are on the master branch
You’ll want to make sure you check out the master branch before following the steps in the instructions video.
Use git add on the conflicting files before committing
Just as in lesson 2, before running git commit to create the merge commit, you’ll need to use git add to add any files that had conflicts to the staging area.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
المواد الداعمة
Commit merging a pull request
After running git log -n 1, you should have seen output something like this:
commit bc368511c6406028c77e2631f77c4d22a5da16d0
Merge: 79fff84 23d1775
Author: cbuckey <caroline@udacity.com>
Date: Tue Sep 30 18:50:28 2014 -0400
Merge pull request #1 from cbuckey-uda/different-oil
Change vegetable oil to canola oil
</caroline@udacity.com>
Notice that the commit message:
- Indicates that a pull request was merged
- Gives the number of the pull request (#1 here)
- Gives the branch the pull request was merged from (cbuckey-uda/different-oil here).
- Contains the title of the pull request.
GitHub automatically creates a commit message like this whenever a pull request is merged to make it easy to see pull requests in the commit history. Even when the merge is a fast-forward merge, GitHub still creates this commit.
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
Concept Map: Fork, Fetch, Pull Request, Fast-Forward Merge
Here are the big new concepts we’ve introduced since we last revisited our concept map:
- fork
- fetch
- pull request
- fast-forward merge
Previous Version
Here’s what the map looked like the last time we added new concepts.
Where Do the New Concepts Go?
Here’s how we fit the new concepts in to the map. Which new concept belongs where?
In the following quiz, write in the concept that you think belongs in each new empty node.
Remember that this map is subjective, so what we have here may not fit your mental model exactly; feel free to draw out the connections you see between the concepts and share your version on the forums!
You can see the full final version of the concept map here, with all the nodes, including those we pruned in earlier versions.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
هل لديك أي أسئلة؟ اذهب إلى منتدياتالنقاش مع مجتمع Udacity
Reflect: When to use a separate branch
You just saw that the workflow when making changes in a separate branch is more complicated than working directly in master, especially when you need to stay up-to-date with changes others are making. Rather than simply pulling and pushing, you need to pull changes into your local master branch, merge the local master into your branch (different-oil, in our case), then push your branch to the remote before finally merging your branch into master, either locally or on GitHub.
Given that, please add the following question and your thoughts on it to your reflections file:
When would you want to make changes in a separate branch rather than directly in master? What benefits does each approach have?
You may also want to commit and push your changes. When you’re finished, click “Next” to put everything you’ve learned together by contributing to the create-your-own-adventure repository.
Fork the repository and clone your fork
Now that you’ve learned how to fork a repository, push changes to your fork, and make a pull request, you’re ready to contribute to the create-your-own-adventure story that you saw at the beginning of the lesson. To do this, first you should fork this repository. Then clone your fork, and make a branch to make your changes in.
Note: You could make your changes directly to the master branch in your fork, but when contributing to a public repository, it’s standard practice to make the changes in a non-master branch within the fork. This way, you can easily keep your master branch up-to-date with master of the original repository, and merge changes from master into your branch when you are ready.
Note for Windows Users: The story has grown so large that it exceeds Windows’ path length limit. If you encounter an error when cloning you can work around it by modifying a configuration setting. Run this command in git bash: git config --system core.longpaths true.
Make a change to the story
Next, you should actually make a change to the story. For instructions on how to do so, please read the README in the create-your-own-adventure repository.
Make a pull request
Next, you should make a pull request containing your changes to the original repository. To do this, click the “pull request” button from your branch like you did before, but this time, leave the original repository as the base.
Ask for your pull request to be merged
You don’t have permission to modify this repository, so you’ll need someone at Udacity to merge your pull request. Our helpful bot Casey may be able to merge your pull request automatically. To have your pull request automatically merged, you’ll need to follow the guidelines in the README of the repository, and in addition you won’t be able to delete or modify lines. That restriction on deletions is because Casey doesn’t want to merge a request that accidentally deletes part of the story, and she can’t tell the difference between an accidental deletion and an intentional modification. To request auto-merging, leave a comment on the pull request containing “@casey-collab”. For example “Please review this, @casey-collab”. Make sure to leave the comment on the “Conversation” tab of the pull request, not the “Files changed” tab.
There are some valid pull requests that Casey won’t be able to merge. For example, she won’t accept a pull request that fixes a typo, since that modifies a line. If you’d like to make a pull request Casey can’t merge, feel free to do so, and someone from Udacity will merge the pull request if we have time. However, we can’t guarantee a response to these pull requests.
If needed, update your pull request
If someone merges your pull request or leaves a comment, GitHub will email you and let you know. If you’re asked to make some changes, push those changes to your fork to update the pull request. Make sure you let the reviewer know that they should take another look!
If your pull request would result in a merge conflict, and you’re not sure how to resolve it, see the next video for instructions.
Congrats on completing How to Use Git and GitHub! Did you know that GitHub isn’t the only place to host your repos and collaborate with people?
There’s also BitBucket, another free Git hosting service that also has the benefit of giving you unlimited private repositories for free! You can learn more about it here and create an account here.
هل لديك أي أسئلة؟ اذهب إلىمنتديات النقاش مع مجتمع Udacity
مسار الاندرويد 