Introduction to GIT
Last updated
Last updated
See the comlete tutorial on Github: Create a repo
Instead of cloning the repo that you created in Github, you can also initiallize the repo using the command line/terminal by followint the Add a project using the command line
We use fork to copy an existing Github repository into out Github account We use clone to copy an existing Github repository into our laptop If we don't fork first, for sure we can clone any repository from others, but if they don't give privileges we will not be able to push the changes, that's why we always fork the repositories
To fork a repo:
Firstly you need to click the "Fork" button:
Then you should be brought to your new fork (notice how the repo title changes):
To clone a repo:
Now you can clone from your fork by copying the URL here:
The command to clone is:
Once you have your repository, and you do the first changes in the code, do the following instructions to save and push to Github your work:
git add . // track changes on files (create, remove, modify)
git commit -m “message” // save changes
git push // upload your commits from origin (your laptop) to the remote (Github) in branch master (the default)
If you are working with the terminal, before execute the commands, are you in the right repository folder? We can have different folders, each one for a different repository.
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --list
git init *project name* //initialize GIT repository in an empty directory (locally)
git add . //track changes on files (create, remove, modify)
git commit -m “message” //save changes
git remote add origin *https://github.com/yourusername/yourrepo*
git push -u origin master //upload origin (my laptop) to the server in branch
git status //show current status
git clone *url* //download files from URL with a file .git
Git has a concept of a "remote". These are other git repositories that can be connected to over the internet. You can push or pull code changes from them. Remotes have a name and a URL.
All the remotes that you will use at Migracode are hosted on GitHub, so have a github.com URL.
When you clone a repo from GitHub, the default remote is named origin and the URL is set to that of the GitHub repo.
You can view the remotes you have set up with:
Follow these instructions if you are getting an permission error when pushing your changes. If you have cloned the original repo before forking, you'll need to follow these instructions. You can check this by running git remote -v. If the output looks something like:
then you have cloned before forking. The key is that the origin remote is pointing to a CodeYourFuture URL. Don't worry, we can fix it!
The first step is to fork the original repo. Follow the first 2 steps from forking instructions above.
Now, instead of cloning the fork (you have already cloned), you need to add it as a remote.
Run:
This will add a new remote called fork that points to your new fork. To check this, run git remote -v again. You should see both the origin and fork remotes.
Now that you have your fork remote you can push to it (instead of the origin remote, which will error) by running:
You'll need to remember to add the fork every time you push.
Now all that remains is to publish your website! In your repository http://github.com/your-username/your-repository-name, you can find the settings icon in the top right corner:
2. Find the section named Github Pages and select "main branch" under 'Source', then hit "Save".
3. Wait a few minutes, then refresh the page and come back to the Github Pages section. Now you should see a green bar saying "Your site is published at http://github.com/your-username/your-repository-name". Click the link, verify that your website is there, then share it with your class!
So you've done your homework, you've committed your changes and are ready to make a PR. Congrats! 🎉🎉🎉
At this point you should have followed the instructions either to fork the original repo or added a remote to your fork. If you haven't make sure you read those sections first.
You will need to push to your fork. If you forked and then cloned (as in the how to fork instructions) then you just need to run git push. If you added a remote to your fork, then you will need to run git push fork.
Next you need to go the original repo in your browser (probably starting with https://github.com/CodeYourFuture). Next click the Pull Requests tab:
Then click the New pull request button:
Then click the "compare across forks" link:
Then click the "head fork" dropdown button:
Then find your fork in the list and click it:
Then click the Create pull request button:
Almost there! Now fill out the PR form. Give it a sensible title and an (optional) description:
And finally click the Create pull request button at the bottom of the form:
That's it! You created your PR!
You have been using git to track the changes you make to your exercises project. Each time you commit, you save a copy of your files.
When you create a new branch, you create a separate line of commits.
With branches, you can work on two copies of your project and switch back and forth.
Complete exercise 9 from the exercise project to learn how to use git branches.
If you want to go deeper, read this article on how git branching works.
Last week you used Git to create a branch so that you could work on two different copies of your project at the same time.
This week you will learn how to merge your changes in one branch back to your master branch.
Complete exercise 18 from the exercise project.
Last week you used Git to merge your changes from one branch back into your master branch.
Sometimes Git can not automatically merge one branch into another, because each branch has modified the same line of code. Git does not know which version of the line is the correct one. When this happens, we have a "merge conflict".
As a developer, you have to tell Git which version of the line of code is correct.
Complete exercise 28 from week 3 of the HTML, CSS and Git Exercises to learn how to resolve a merge conflict.
https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts
As a professional, you'll usually need to work alongside other coders to build an app or website. We use version control to coordinate changes and manage any conflicts that arise. Git is a version control system which helps us merge code that we've been working on separately into one common codebase.
To manage conflicts, we will need a common code base in which all changes are coordinated. When working on our own, we'll make our changes in branches to keep the code separate. Then we'll learn how to refresh your individual branch with the common code base, and prepare your changes to be merged.
Exercise: Get together in pairs and select a "leader". The leader should fork this repository to their GitHub account. The other person should then fork the leader's repository. Both students should then clone their own personal forks locally.
Now that you have the project set up on your computer, you need a place to safely make changes without effecting the common code base. To do this, we'll navigate to our project in the Terminal and create a new branch:
When you commit changes on this branch, your changes will be saved separately from the common code base. This way both team members can make changes at the same time.
Exercise: Add your name and a sentence about yourself to the
index.htmlfile. Thengit addandgit committo commit to your personal branch.
Now you have two branches: master and my-first-branch. These branches have diverged, which means you have changes in one that don't appear in the other. You can check this by running git checkout master, then looking at your index.html file.
When you're done, run git checkout my-first-branch to go back to the branch with your changes. Git saves your changes in both branches and lets you switch between them. That's why we call it "version control". It saves different versions so you can switch between them.
Right now, your new branch only exists on your computer. Let's push it up to GitHub so you can see it in your profile.
Now both students in each pair, the "leader" and the other student, should have branches with changes. Now let's try to merge these changes together into the "leader's" master branch.
Exercise: Browse to the "leader's" GitHub repository and open a new Pull Request. The Pull Request should ask to merge your
my-first-branchbranch into the "leader's"masterbranch. Ask a mentor for help if you have trouble figuring out how to issue a Pull Request. When both students have issued a Pull Request to the correct place, merge one of them but not the other.
Congrats, you've merged one student's changes with the common code base in the master branch. If you check the other Pull Request, you'll see you have a problem. It can't be merged automatically because there's a conflict. Why?
Conflicts emerge whenever the same file has been edited, and git can't determine what changes should be kept and what changes should be discarded. A human -- that's you -- needs to step in and sort it out. To help us, git writes into our code so we can see where it is confused. Here's an example of a merge conflict in our code:
To resolve a conflict, we decide which lines to keep and which lines to remove. When we're done, we remove the extra lines that git added (<<<<< HEAD, ======== and >>>>>>>).
Let's see how we can resolve this conflict with your branches. First we need to fetch the latest changes from the leader's master branch. If you're the leader, just do:
If you're the other student, you need to set up the remote and pull from that master:
Now everyone's master branch should include the Pull Request that was merged. Whichever student still needs to get their Pull Request merged can bring those changes into their branch like this:
You probably received a merge conflict.
Exercise: Follow the steps we discussed before about how to resolve a merge conflict by editing the file. Make sure both students changes are included in the final version. When you're done, use
git add,git commitandgit pushto share your changes with GitHub. If everything has gone correctly, you can now merge the Pull Request.
Now everyone can sync their changes. If you're the leader, just do:
If you're the other student, do this:
Exercise: As a group, discuss why the
git pullcommand is different for the leader and the other student.Exercise: Try to do the pull requests again, but this time switch the pull requests so that the other student must manage the merge conflict.
If you're feeling confused, don't worry. Version control is one of the most difficult things you'll learn and we'll be going over it again and again and again.
git fetch //fetch latest changes from origin and all branches (no merge)
git pull //fetch latest changes from origin and all branches (with merge)
git merge
Branches:
git branch test //creates a new local branch
git checkout test //move to branch test
git checkout master //move to branch master
git checkout -b test //create a new local branch and move into it
git push origin test //push the branch and all commits to the server
git branch -d test //remove a local branch
git checkout -b test origin/test
git fetch --all //to get all branches from server
