| 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
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
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.
- 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
Many of these words become commands we can use in the command line, or will be the names for buttons in our GUIs.
git clone https://url/repo.git
git add file.md
git commit -m "Important bcoz 🐛"
git push- Git https://git-scm.com/downloads
- VS Code https://code.visualstudio.com/ Optional cross-platform IDE with a good git integration
- Hugo https://gohugo.io/getting-started/installing/ For the extended exercise and optional
- Github https://github.com/
- Netlify http://netlify.com For the extended exercise
- Local info
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
- SSH http://bit.ly/githubsshinstructions Optional but recommended
- 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
When working mostly by ourselves, it can be ok to use a very simple workflow that just helps keep our code associated with why we've made changes. So long as we don't mind risking commiting broken code to our core codebase online, our workflow can be pretty simple.
git clone https://url/repo.git
# make some changes using IDE to file.md
git add file.md
git commit -m "Important bcoz 🐛"
git push- Get a local copy
- Open folder in VS Code
- Change the gif
- Commit your change
- Use emoji in your commits!
- Push to github
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).
- Online, change the gif to something different
- Locally, 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!