- Make sure you have Git insalled on your computer and a GitHub account.
Quick review of what we've covered so far:
- Repository for Class: https://github.com/githubteacher/fluffy-octo-guacamole
- Gitter Q&A for class: https://gitter.im/githubteacher/fluffy-octo-guacamole
- Tour of Repository:
- Code View: Files belonging to the project
- README.md: Description of the Repository
- Issues: A place to have conversations and collaborate
- Pull requests: A place to collaborate while introducing changes to your project
- Comment on this issue to become a collaborator on the project
- Practice making an issue in the issues tab of the class repository.
- For today's activity, be sure to include your username in the title, like "YourUserName Hometown"
- In the body of the issue, we added the steps we'll take for the workflow.
- Our goal later will be to add a document with information about your hometown, like good restaurants or things to do.
- You can include markdown syntax here.
Getting access to the collaborator script: The collaborator script is open-source! You can access it here. Our training kit is also open-source. We invite you to use these and welcome contributions to both these repos!
Review of configurations:
- We determined our git version by running
git --version... version 1.9+ is recommended - If you need to, you can install it here
- If you don't already have GitHub Desktop, you can install it here
- Clone the repository by running
git clone https://github.com/githubteacher/github-for-developers-2016-04.git(Make sure you are in the directory where you want the repository to be when you run this command) - If you have trouble with your proxy server or firewall, you may need to use SSH. Instructions here.
- Set up your Git configurations by running these commands:
git config --global user.name "your name"git config --global user.email <[email protected]>git config --global core.editor <editor>(For more help associating your text editor with Git, read this GitHub Help article.- If your version is less than 2.0:
git config --global push.default simple - Windows ONLY:
git config --global core.autocrlf true - Mac and Linux ONLY:
git config --global core.autocrlf input git config --global fetch.prune true
- Check your configurations by running
git config --list
You can find that visual of the GitHub flow at this link: https://guides.github.com/introduction/flow/
Create a branch locally
- When you create a branch, you are essentially creating an identical copy of the project at that point in time that is completely separate from the master branch.
- In your terminal and in the directory for the repository, create a branch with a unique name:
git branch <username-add-bio> - Checkout to that branch to work on it:
git checkout <username-add-bio> - See what branch you're on:
git branch
####6. Working Locally Review of working locally
- Working on our new branch, create a new file:
touch <newfilename.md> - See your working/staged area
git status. This command is ❤️!
- Change your file from 'working' to 'staging' by running
git add <file-name> - Change your file from 'staging' to 'history' by running
git commit. (To avoid using the text editor, usegit commit -m "Enter commit message here") - Text editor opens: Write a 'commit message' tells a story of the changes you just made in 50 characters or less.
- List the files in your current directory by running
ls -la - We learned about 'working', 'staging', and 'history' and how commits fit into those areas using this resource.
- Create a new file and repeat steps 1 - 3 for the two stage commit. This way, we'll have two commits to work with.
- Here are some shortcuts to know about in the future:
- To automatically stage all files that have been changed, run
git add -A. Note: This will only work for files that are already being tracked, not brand new files. - Avoid the text editor in the commit by running
git commit -m "commit message"
- To automatically stage all files that have been changed, run
Review of moving from Git to GitHub
- We talked about remote, and how we can see details about it by running
git remote,git remote -v, andgit remote show origin - 'Push' our changes on the current branch to GitHub.com by running
git push -u origin <branch-name> - If you forget the
-utag, set a 'upstream branch' relationship between our local branch and the GitHub.com remote branch by runninggit branch --set-upstream-to=origin/<remote-branch-name>- This means we only have to run
git pushandgit pullin the future- git pull is the combination of git fetch and git merge
- This means we only have to run
git branchandgit branch -awill help you see what is going on with your local and remote branches- On GitHub.com, open a pull request in our class repository by clicking the green "New pull request" button.
- Make sure your pull request says
base: masterandcompare: <your-new-branch> - Give it a good title and message about the changes you introduced. Bonus points for using markdown and emojis!
- You can add labels and assignees to pull requests like we did with Issues.
- Make sure your pull request says
- Using @mention is important - you can mention people or teams to give them a notification to see your pull request to start collaboration.
Notifications
- Notifications are an important part of GitHub. You can customize these several ways.
- For GitHub in general, Settings/notificatons
- For repositories, at the top of a repository page on GitHub.com by clicking "Watch"
- For individual issues and pull requests by clicking "unsubscribe" on the right hand side of the webpage
- On the pull request page, we talked about the different tabs for 'conversation', 'commits', and 'files changed'.
- 'Conversation' is where you and your colleagues can collaborate on your changes. This view includes comments as well as notes of when changes happen.
- 'Commits' shows a history of what commits were added - this is why your commit messages matter - they tell a story.
- 'Files changed' will let you see the actual code in several different formats. You also can make line level comments from this view.
- Once you've opened a pull request, go into someone elses. Please don't merge someone else's PR.
- Look at their code, and make a comment about something you see.
Pull requests
- During class, please do not close or merge any pull requests other than your own.
- On your own pull request, if all is green and there are no conflicts, go ahead and merge your branch.
- After merging a branch, it's part of the
masterbranch and good practice is to delete it.- This is a major difference between Git and some older version control systems. In Git, branch often, merge often, and delete branches often.
- Back at the command line, we need to pull down the changes from GitHub.com in the remote repository.
git checkout mastergit pullgit branch --mergedgit branch -d <branch-name>git fetch --prune
- Configure your settings to do this by default by typing
git config --global fetch.prune true
Local Diffs
- View local diff diagram here
- Use
git logto view the history of the repository git logwill show commits from your own local repository, but also changes made by other collaborators- Experiment with different option switches to view history:
git loggit log --onelinegit log --oneline --graphgit log --oneline --graph --decorategit log --oneline --graph --decorate --allgit log --statgit log --patch
- Use the up and down arrows or press enter to view additional log entries. Type q to quit viewing the log and return to the command prompt.
- Set up an alias in configurations:
git config --global alias.<desired-alias> "the long version of the command that you want the alias to run, without git at the beginning, and with the desired flags"
- We are using the same repository as yesterday
- Clone the repository locally on your command line:
git clone https://github.com/githubteacher/fluffy-octo-guacamole.git new-fluffy-repository- Note: the extra argument at the end creates an alternate name for the repository
- CD into the new repository:
CD new-fluffy-repository - See all of the bios:
ls bios/ - Create a new branch and checkout to it:
git checkout -b new-unique-branch-name - Make changes locally to your own file in your favorite text editor. Save your changes and exit your text editor.
- Commit your changes:
git add <filename>git commit -m "enter short descriptive commit message"
Local Diffs
- View local diff diagram here
git diff: See local changes between working, staging, and history- If we have added more changes to a file that we've already created, we can see differences between them with
git diff - See differences with
git diff git diffgit diff --stagedgit diff HEAD- To see differences between branches:
git diff <branchname> git diff --stat master
- Use
git logto view the history of the repository git logwill show commits from your own local repository, but also changes made by other collaborators- Experiment with different option switches to view history:
git loggit log --onelinegit log --oneline --graphgit log --oneline --graph --decorategit log --oneline --graph --decorate --allgit log --statgit log --patch- Use the up and down arrows or press enter to view additional log entries. Type q to quit viewing the log and return to the command prompt.
- Make more changes with the steps used before.
- Add and commit those changes.
- Continue to use
git diffandgit log -5to see changes throughout the commit process - See commit differences between branches:
git log <current-branch> ^master
- In your command line, go back to the master branch:
git checkout master - Update your local repository:
git pull - Git will delete remote tracking branches that no longer exist:
git fetch --prune - See what branches have been merged into the current branch:
git branch --merged - Delete the branches locally:
git branch -d <branch-name>
- Create a new branch and checkout to the branch at the same time by typing
git checkout -b username-readme-update - Edit the
readme.mdfile with your text editor so the link on line 5 reflects your username instead ofgithubschool - Save those changes, and exit the text editor
- Type
git statusto see your current branch and current stages of each file
- Type
git add readme.mdto move your files from working to staging - Type
git commit -m "update link in readme"to move files to history - To push the changes to the remote repository in the correct branch to reflect your local branch, type
git push -u readme-update. - See your changes on GitHub.com
- Open a new pull request
- You will see there is a merge conflict!
- We are going to resolve the conflict on our branch and make sure it works out with a reverse merge. This is when you merge master into your feature branch.
- Locally, checkout to your own branch.
git merge --no-ff mastergit status- Open the README.md again. You'll look for the conflict markers. Delete the copy of the content you don't want to keep as well as the merge conflict markers. Save and close.
git add README.mdgit statusgit commit -m "enter commit message here"git statusgit push- Feel free to practice more with merge conflicts later on this repository.
git revertcreates a new commit that is the exact opposite of the selected commit. This is important to note when thinking about impact on history!- Revert a commit by typing
git revert <first-4-of-commit#>.
- See the commit history:
git lol. - Find the commit where index.html was renamed to inde.html and copy the first 4 characters of that commit ID
- Revert that commit:
git revert <first-4-characters>. - Complete the commit message in your text editor, save, and close.
- Push your local changes to the remote repository:
git push mygame. - See your working game by going to the new link in the README on your remote repository.
- Overview for conceptual understanding
- To follow along:
git checkout mastergit log --oneline --decorate -5git statusgit merge origin/mastergit log --oneline --decorate -5
- Pull requests default to fast forward merge if possible, which does not create a commit
- To force a recursive merge and a commit message, use
git merge --no-ff <branchname> - Remember, when you delete a branch, you're only really deleting a pointer to a commit.
- We made a new file, and renamed it with
git mv- Make sure your local repository is up to date:
git pull - Create a new branch and checkout to it:
git checkout -b demo-undoing-things - See the files:
ls - Move a file: git mv hello.txt bios/hello.txt
git status- git commit -m "enter commit message"
- Make sure your local repository is up to date:
- Remove files with
git rm- Delete a file and stage the deletion
git rm jt_bio.md git statusgit commit -m "demo deleting files"
- Delete a file and stage the deletion
- See the commits that have worked with a given file:
git log -- bios/hello.txt - See all of those, including renames:
git log --follow -- bios/hello.txt
- See all recent history:
git log --oneline --decorate -5 - Revert a single commit by using the first four characters of the commit ID:
git revert <first-four-chars> - This creates a new commit with a new ID and it does the opposite of everything done in the referenced commit. It is the safest way to undo changes.
- Make another change to a local file, like your bio.
- Add the changes, and make a commit.
- Make another change and add it, but do not commit it.
- To change the previous commit to include your most recent changes, type:
git commit -a --amend - It is unsafe to use this command after a commit has been pushed to a remote repository, as you are rewriting history.
git resetmoves the branch pointer along the current branch- To practice, create a new branch:
git checkout -b <demo-branch-name> - Add text to the README with:
echo 'lorem ipsum' >> README.md - Commit these changes with
git commit -am"add first dummy line - Add more files
echo 'a second line' >> README.mdgit commit -am"a second line"echo 'a third line' >> README.mdgit commit -am"a third line"
- See your recent log history:
git lga-5 - Reset soft back to one of the earlier commits:
git reset --soft <first 4 of commit ID> - See that log:
git lga -5 - Check our status to see what is staged:
git status git diff --stagedgit commit -m"add additional two lines"git reset softmoves head and moves the files back to staging- The default for
git resetisgit reset --mixed. - Try it with
git reset <first four of commit ID>- Don't forget to use
git lga -5andgit statusto see how it works
- Don't forget to use
- Now, let's use
git reset --hard <first 4 of commit ID>- Warning: If you
git reset --hardand there are uncommitted changes, they will be gone forever. :(
- Warning: If you
- See how these changes work with
git log --oneline,git status, andcat README.md
- In case you were worried that
git resethad done some damage to your commits, you should know aboutgit reflog git reflogshows every place your HEAD has been, including commits and resets.- This means you can
git resetback to the commits you just got rid of! - Warning: The commits in the reflog do not live forever!
- Reflog information exists only 30-90 days based on your settings.
- Reflog information is only local - not on the remote repository or any other collaborator's repositories
- This command,
git cherry-pickis not part of the every-day workflow git cherry-pickwill bring back specific commits that may have been undone withgit reset- It's also used to grab a single commit off of a feature branch and replay it on master.
- Practice by typing
git cherry-pick <commit-ID>of a commit that has been undone - It's important to only use
git cherry-pickwith commits that have not been pushed to a remote repository as it changes the commit ID of the same information
About Rebase
- The
rebasecommand enables you to modify your commit history in a variety of ways. - Because changing your commit history can make things difficult for everyone else using the repository, it’s considered bad practice to rebase commits you’ve already pushed to a repository.