| title | author | date |
|---|---|---|
Working with Git |
Steph Locke |
15 September 2018 |
Source control is a system for tracking changes to files over time.
What's the point?
- No version hell
- Why did I do that?
- Satisfy auditors
- UNDO, UNDO, UNDO!!
What techs are there?
- Central systems like SVN
- Distributed systems like Git
- Hybrid systems like TFS
Why GitHub?
- Git is awesome
- Public / private models
- Great UX
- Great integrations
- Repository: Your project and it's history
- Remote: The (TFS/GitHub/VSO etc) server
- Clone: Take a linked copy of a repository
- Fork: Take an unlinked copy of a repository
- Pull: Update your copy of a repository
- Add: Include a file in a change
- Commit: Make the latest state of all the added files the new default state
- Push: Update the central copy of the repository with your commits
- Git https://git-scm.com/downloads
- VS Code https://code.visualstudio.com/
- Hugo https://gohugo.io/getting-started/installing/
- Github https://github.com/
- Netlify http://netlify.com
- Local info
git config --global user.name "John Doe"
git config --global user.email [email protected]
Gists https://gist.github.com is source control without the git being obvious.
Upload or write one or more files and let it track changes for you. You can share gists and folks can fork them and change their copy.
These have git under the hood so you can see what changes were made and when, and even work with a gist locally if you want.
- Google for some git resources
- Create a gist that contains a
GitHelp.mdfile - Add the links you found using the format:
# Git links
- [description](url)
- [description](url)- Navigate to https://gist.github.com/stephlocke and fork my latest gist
- Add resources you found, to your copy of my gist
Gist: Gist is a simple way to share code snippets and pastes with others. It is used when you need to share a sample piece of code or technique with your co-workers or friends.
And
GitHub GitHub, on the other hand, provides a platform to share an entire project as a repo among a team(private repo) or to the whole world(public repo).
With Git, we keep an online (remote) version of our projects (repository). This is the source of truth and folks can take copies of this version to work on things. They can often also install based on the code online.
We take a copy (clone) of the remote version and make our changes to it. We can be making lots of changes independently of everyone else.
Once we've made changes we're happy with, we can confirm locally they're OK by saying which things you changed are worth keeping (add). Then we can say why we changed these files (commit) so that we get a record of what changed, when, and why.
Once we've got some changes locally that we're happy with, we need to send our code (push*) back to the online copy. This makes our code available to everyone else.
If someone has made some changes since we took our copy, we might need to integrate their changes into our copy. We do this by getting the updates (pull) from the online copy.
If we have been working on the same lines of code as others have, then we need to decide how our code gets combined (merge conflict). Once we've incorporated the changes, we then need to confirm we're happy (add and commit) and then send (push) our sorted version to the online copy.
If folks are installing from our online copy and we're making changes that they either shouldn't be getting yet or we're not quite certain of, then we probably need to put our code somewhere else.
How we do this in git is by adding a space we can work on our code in (branch). We can then keep track of all our changes (commit) and once we're happy with all our code, we can then add everything back into the core version (merge).
If we want to be extra safe, we could take our own full copy of the code (fork) before working on things so we can't screw up our important copy.
GitHub etc. gives us an extra safety mechanism for when we want to make changes either via a working space (branch) or a seperate copy (fork) that enables code review and approval processes. This is a pull request, frequently shortened to PR, where all our changed code can be discussed reviewed and changed. Once people are happy, the code can then be accepted (merge) into the core version (or even a branch).
- Make a repository on github with a README
- Use the online editor to add some info into the README file.
- Must include a gif
!
- Must include a gif
- Get a local copy
- Open folder in VS Code
- Change the gif
- Commit your change
- Use emoji in your commits!
- Online, also change the gif to something different
- Push your local change
- You should get an error
- Pull the online changes
- Fix the merge conflict and commit the change
- Push to github
This is an extended exercise to get your comfortable with working with git.
Fork the repo https://github.com/sourcethemes/academic-kickstart and follow the README instructions to get a local copy.
Navigate to netlify and make a new site with your github repo. Give it a better name. Now everytime we make a change to our repo it'll deploy automatically.
Add this new url to the first line of the config.toml file. Give it some seconds and refresh your website to see what impact your change had.
Now start, making some changes to the values in the various files. If you installed Hugo, you can use hugo serve to see changes locally as you make them.
You should have a WIP website about yourself that you can use to build up your skills and your portfolio.
Enjoy!