Created
November 30, 2017 09:21
-
-
Save eggm0n/d33fe77f69c668a24b765a7002af4677 to your computer and use it in GitHub Desktop.
git notes
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
> git init | |
Directory: | |
A folder used for storing multiple files. | |
Repository: | |
A directory where Git has been initialized to start version controlling your files. | |
> git status | |
The .git directory | |
On the left you'll notice a .git directory. It's usually hidden but we're showing it to you for convenience. | |
If you click it you'll notice it has all sorts of directories and files inside it. You'll rarely ever need to do anything inside here but it's the guts of Git, where all the magic happens. | |
Tip: | |
It's healthy to run git status often. Sometimes things change and you don't notice it. | |
> git add file.txt | |
staged: | |
Files are ready to be committed. | |
unstaged: | |
Files with changes that have not been prepared to be committed. | |
untracked: | |
Files aren't tracked by Git yet. This usually indicates a newly created file. | |
deleted: | |
File has been deleted and is waiting to be removed from Git. | |
add all: | |
You can also type git add -A . where the dot stands for the current directory, so everything in and beneath it is added. The -A ensures even file deletions are included. | |
git reset: | |
You can use git reset <filename> to remove a file or files from the staging area. | |
> git commit -m "commit message" | |
Staging Area: | |
A place where we can group files together before we "commit" them to Git. | |
Commit | |
A "commit" is a snapshot of our repository. This way if we ever need to look back at the changes we've made (or if someone else does), we will see a nice timeline of all changes. | |
> git add '*.txt' | |
Wildcards: | |
We need quotes so that Git will receive the wildcard before our shell can interfere with it. Without quotes our shell will only execute the wildcard search within the current directory. Git will receive the list of files the shell found instead of the wildcard and it will not be able to add the files inside of other directories. | |
Check all the things! | |
When using wildcards you want to be extra careful when doing commits. Make sure to check what files and folders are staged by using git status before you do the actual commit. This way you can be sure you're committing only the things you want. | |
> git log | |
More useful logs: | |
Use git log --summary to see more information for each commit. You can see where new files were added for the first time or where files were deleted. It's a good overview of what's going on in the project. | |
> git remote add origin https://github.com/username/reponame.git | |
git remote: | |
Git doesn't care what you name your remotes, but it's typical to name your main one origin. | |
It's also a good idea for your main repository to be on a remote server like GitHub in case your machine is lost at sea during a transatlantic boat cruise or crushed by three monkey statues during an earthquake. | |
> git push -u origin master | |
The name of our remote is origin and the default local branch name is master. The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do. Go ahead and push it! | |
Cool Stuff: | |
When you start to get the hang of git you can do some really cool things with hooks when you push. | |
For example, you can upload directly to a webserver whenever you push to your master remote instead of having to upload your site with an ftp client. Check out Customizing Git - Git Hooks for more information. | |
> git pull origin master | |
git stash: | |
Sometimes when you go to pull you may have changes you don't want to commit just yet. One option you have, other than commiting, is to stash the changes. | |
Use the command 'git stash' to stash your changes, and 'git stash apply' to re-apply your changes after your pull. | |
> git diff HEAD | |
In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer. | |
HEAD | |
The HEAD is a pointer that holds your position within all your different commits. By default HEAD points to your most recent commit, so it can be used as a quick way to reference that commit without having to look up the SHA. | |
> git diff --staged | |
Commit Etiquette: | |
You want to try to keep related changes together in separate commits. Using 'git diff' gives you a good overview of changes you have made and lets you add files or directories one at a time and commit them separately. | |
> git reset file.txt | |
You can unstage files by using the git reset command. Go ahead and remove file.txt | |
git reset did a great job of unstaging file.txt, but you'll notice that he's still there. He's just not staged anymore. It would be great if we could go back to how things were before octodog came around and ruined the party. | |
Files can be changed back to how they were at the last commit by using the command: git checkout -- <target>. Go ahead and get rid of all the changes since the last commit for file.txt | |
git checkout -- file.txt | |
The '--' | |
So you may be wondering, why do I have to use this '--' thing? git checkout seems to work fine without it. It's simply promising the command line that there are no more options after the '--'. This way if you happen to have a branch named octocat.txt, it will still revert the file, instead of switching to the branch of the same name. | |
> git branch branch1 | |
When developers are working on a feature or bug they'll often create a copy (aka. branch) of their code they can make separate commits to. Then when they're done they can merge this branch back into their main master branch. | |
Branching | |
Branches are what naturally happens when you want to work on multiple features at the same time. You wouldn't want to end up with a master branch which has Feature A half done and Feature B half done. | |
Rather you'd separate the code base into two "snapshots" (branches) and work on and commit to them separately. As soon as one was ready, you might merge this branch back into the master branch and push it to the remote server. | |
Great! Now if you type git branch you'll see two local branches: a main branch named master and your new branch named branch1. | |
> git checkout branch1 | |
All at Once | |
You can use: | |
git checkout -b new_branch | |
to checkout and create a branch at the same time. This is the same thing as doing: | |
git branch new_branch | |
git checkout new_branch | |
> git rm '*.txt' | |
You can finally remove all those pesky octocats by using the git rm command which will not only remove the actual files from disk, but will also stage the removal of the files for us. | |
You're going to want to use a wildcard again to get all the octocats in one sweep, go ahead and run: | |
Remove all the things! | |
Removing one file is great and all, but what if you want to remove an entire folder? You can use the recursive option on git rm: | |
git rm -r folder_of_cats | |
This will recursively remove all folders and files from the given directory. | |
The '-a' option | |
If you happen to delete a file without using 'git rm' you'll find that you still have to 'git rm' the deleted files from the working tree. You can save this step by using the '-a' option on 'git commit', which auto removes deleted files with the commit. | |
git commit -am "Delete stuff" | |
Pull Requests | |
If you're hosting your repo on GitHub, you can do something called a pull request. | |
A pull request allows the boss of the project to look through your changes and make comments before deciding to merge in the change. It's a really great feature that is used all the time for remote workers and open-source projects. | |
Check out the pull request help page for more information. | |
> git merge branch1 | |
Merge Conflicts | |
Merge Conflicts can occur when changes are made to a file at the same time. A lot of people get really scared when a conflict happens, but fear not! They aren't that scary, you just need to decide which code to keep. | |
Merge conflicts are beyond the scope of this course, but if you're interested in reading more, take a look the section of the Pro Git book on how conflicts are presented. | |
> git branch -d branch1 | |
Force delete | |
What if you have been working on a feature branch and you decide you really don't want this feature anymore? You might decide to delete the branch since you're scrapping the idea. You'll notice that git branch -d bad_feature doesn't work. This is because -d won't let you delete something that hasn't been merged. | |
You can either add the --force (-f) option or use -D which combines -d -f together into one command. | |
> git push |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment