Full width home advertisement

Post Page Advertisement [Top]

 L1. Git


Git

Git is a command line tool that help us with version control in several different ways

> Keep track of changes to code
- Allowing us to keep track of changes we make to our code by saving snapshots of our code at a given point in time.
-- I might have wanted to save the old version, so I would duplicate the file and then make changes to the duplicate: MESSY

> Synchronizes code between different people
- to easily synchronize code between different people working on the same project by allowing multiple people to pull information from and push information to a repository stored on the web

> Test changes to code without losing the original
- to make changes to and test out code on a different branch without altering our main code base, and then merging the two together

> Revert back to old versions of code
- to revert back to earlier versions of our code if we realize we've made a mistake

GitHub

Github: A website that allows us to store Git repositories remotely on the web

- github.com/new: The page I go to if I want to create a new GitHub repository

> How to add some files to a repository
1. Make sure you have git installed on your computer by typing git into your terminal.
2. Click the "Clone or Download" Button on your repository's page, and copy the url. 
3. In your terminal, run 'git clone <repository url> to download the repository to your computer. 
- If you didn't create a README, *Warning: you appear to have cloned into an empty repository.*
4. Run 'ls', which is a command that lists all files and folders in your current directory. 
5. Run 'cd <repository name>' to change directory into that folder. 
6. Run 'touch <new file name>' to create a new file in that folder. You can now make edits to that file. Alternatively, you can open the folder in your text editor and manually add new files. 
7. To let Git know that it should be keeping track of the new file you've made, Run 'git add <new file name> to track that file, or 'git add.' to track all files within that directory.

git clone

> git clone: A command that we can run in order to take a repository from the internet and download it onto our own computer 
- (terminal) git clone <url>
- If I run git clone followed by the URL of the repository I want, the repository and all of its contents get downloaded onto my computer. Now I have a copy of everything that was originally inside of that Git repository. 

git add

:let us tell Git that I would like to add a file as one to track the next time I save, the next time I commit to say that I would like to take a snapshot of all these files, such that I'm able to refer back to them later. 

> git add <filename>
-> this file will be saved the next time I make a commit. 

git commit

> git commit -m "message"
- "message": later you can refer back to all your commit messages
- Git is going to save a new snapshot of a version of your code. 
 
When I ran the git clone step in order to clone the repository from GitHub, GitHub had a version of the repository, and I ran git clone it to download a copy of that repository onto my own computer. 
And when I ran git add to add the new file, or I ran git commit, I would like to save these changes, I was always making those changes only to my local version of the repository. 
I was never affecting anything that was already on GitHub. 
If I want to push those changes up to GitHub, I'm going to need some additional commands. 

git status
- What is currently happening inside of my repository. 

EX) If I run the command 'git status': Git is going to report back to me that 'I'm currently on branch master' and saying 'my branch is ahead of origin master by one commit.' 
-> My local version of the repository is ahead of the origin version of the repository. The version of the repository that's up on GitHub by one commit, that I have one commit that the origin GitHub does not have. 
- And telling me I can use the command "git push" to publish your local commits. 


git push

- git push: My changes get pushed up to GitHub, so GitHub has access to all of the commits that I have now made. 

> git commit -am " "
- to add all of the files that have been changed and commit at the same time

git pull

- When I run 'git pull', what's going to happen is the opposite of what 'git push' did. While 'git push' took my changes on my computer and pushed them up to GitHub, 
- git pull: Take the changes that currently exist on GitHub, and go ahead and pull the most recent changes down, so that I and my local version of the repository have access to the latest version of all the code that is currently on GitHub. 

EX) If I take a look at GitHub's website itself, on GitHub, I have the ability to edit files using GitHub's interface. 
If someone else working on this project, (+they can provide a commit message)

- So now the version on GitHub is different from the version on my computer. 
- So, inside my terminal, I can say 'git pull' in order to download it. 


Merge Conflicts

- A merge conflict occurs when two people attempt to change a file in ways that conflict with each other.
- When we trying to merge my changes with the changes that someone else has made, we run into a situation where suddenly Git doesn't know what to do. 
- Git is automatically going to add some metadata to the file to describe the things that it can't quite figure out. 

- Every comment gets a hash that is some sequence of numbers and characters that is likely to be unique that helps to identify any particular commit. 
- Git will automatically generate a hash every time you make a comment. 
- When I run git pull to pull in those latest changes, I'll get a message 'CONFLICT: Merge conflict in <file>', 'Automatic merge failed; fix conflicts and then commit the result.' 

git log

- Useful if you ever need to keep track of all of the changes that you've made to your code. Gives you a history of all of your commits on that repository. 
- Run the command 'git log', and Git will spit out a bunch of messages.
- For each commit, it'll tell you what the commit hash is, such that you can reference it more easily, who made the commit, the date on which that commit was made and the commit message. 

git reset

> Revert back to a previous commit using the command 'git reset' in one of two ways
- 'git reset --hard <commit>': Reverts your code to exactly how it was after the specified commit. To specify the commit, use the commit hash associated with a commit which can be found using 'git log' as shown above. 
- 'git reset --hard origin/master: Reverts your code to the version currently stored online on GitHub. Use when I want to take my current version of the repository and reset it back to whatever is on GitHub. 

So run git reset, followed by a commit hash(git reset --hard 57656c6), and that will reset the current state of the repository back to whatever state it was in previously. 

Making Changes / Branching

- Make my first commit, make some changes and additional changes, start working on a new feature, then continue working on that new feature. But there was bug in the original code that I made way back <more changes>. I want to go back and fix that bug, but I'm in the middle of working on a new feature. The problem is that this structure is very linear. 

> Branching: Git's way of working on different parts of the repository at the same time. 

- Create a new branch, start working on our new feature, and then keep working on that new feature. 
- If I realize later on down the road, there was a bug, then I can go back to the commit 'more changes' and create a new branch, where I go ahead and fix that bug. 
- Now I have two different branches, each of which might have different code on it, one of which I've been fixing a bug, one of which I've been working on a new feature on. 
- Generally, each of those branches is going to have a name. Master branch is the default branch, which is generally going to contain the up-to-date, stable version of the code. And as I'm working on newer things, newer additional features, I might have some feature branch, where I'm working on some other feature. 
- My focus is only on one of these two branches, what the current state of my repository is, is designated by something we call the head. 
- HEAD is pointing to master, that means my repository is working on the master branch, where you fixed the bug.  
- I can change the head, I can switch what branch I want to look at. I can begin working on these different branches by switching where my head is, switching from one branch to another, and then back again. 
- When the bug is fix, we can merge those changes back together, so that everything comes back onto this unified master branch that now has all of the latest code. 

EX) How we actually implement branching in our git repositories: 
1. Run 'git branch' to see which branch you're currently working on, which will have an asterisk to the left of its name. => *master
2. To make a new branch, run 'git checkout -b <new branch name>' and commit any changes to each branch. => - Switched to a new branch 'new branch name'
- But if I'm switching to a branch that already exists, I can just say 'git checkout master', for example, to switch my current branch from the style branch to the master branch.  
4. If run 'git branch' again => master *'new branch name'
3. When we're ready to merge our two branches together, we'll check out the branch we wish to keep(almost always the master branch) and then run the command 'git merge <other branch name>'. This will treated similarly to push or pull, and merge conflicts may appear. 
- EX) 'git merge style': I'd like to take what I was working on in the style branch and merge it into this current version of the repository on my master branch. In order to do that, run 'git merge'. Attempt to merge it into my current branch whatever is on the style branch. 
But there's a merge conflict. This won't happen all the time when you merge. Sometimes Git will resolve those merge conflicts automatically. But in this case, both my style branch and my master branch made changes to the same line of code. The conflict is in my version on the master branch. I remove the punctuation mark, whereas in the version on the style branch, which we can see here by the word "style"
- Get rid of these style markers or the conflict markers. I would like for the updated version not to have either. 
-I have resolved the merge conflict and now I can commit. Run 'git commit -am "Fix merge conflicts"'

More GitHub Features

Forking

- If you find a Git repository that you would like to contribute to, or if you want other people to be able to contribute to your repository. 
- As a GitHub user, you have the ability to fork any repository that you have access to, which creates a copy of the repository that you are the owner of. 
- Click the "Fork" button in the top-right. 

EX) Bootstrap's repository, while it is public, doesn't allow anyone to just push to it. That would be probably unsafe if anyone in the world could just update Bootstrap's master code, but what you can do is copy the code, make a fork of it, make changes to it on your own, push and pull to it. 

Pull Requests

- Once you've forked a repository and made some changes to your version, you may want to request that those changes be added to the main version of the repository. 
- When you've made a contribution that you would like to send back to Bootstrap, you can open what's called a pull request, that you are requesting that your code be pulled in to Bootstrap's code. 
- This is one of the key benefits of open-source software, the ability for multiple people to be working on the same piece of code, and for a community to be able to collaborate on finding bugs on figuring out what changes to make, on figuring out how to improve upon an existing repository and make it better moving forward. 

GitHub Pages 

- GitHub Pages is a simple way to publish a static site to the web, and a free way that GitHub provides to be able to quickly take a website with HTML, CSS, and maybe even a little bit of JavaScript. 

1. Create a new GitHub repository. 
2. Clone the repository and make changes locally, making sure to include an index.html file which will be the landing page for your website. 
3. Push those changes to GitHub. 
4. Navigate to the Settings page of your repository, scroll down to GitHub Pages, and choose the master branch in the dropdown menu. 
5. Scroll back down to the GitHub Pages part of the settings page, and after a few minutes, you should see a notification that "Your site is published at:..." including a URL where you can find your site. 




댓글 없음:

댓글 쓰기

Bottom Ad [Post Page]