Adam LaBarge from Hyperarts introduced us to Git and GitHub: installing Git on Windows and Mac, cross-platform GUI clients for Git, repositories like GitHub, GitLab, and BitBucket, deploying from Git to WP Engine, and other useful tools for developers.
Notes from Adam’s Git Presentation
Git was invented by Linus Torvalds.
What’s different about Git? It takes snapshots of your data as your file changes. Git manages the version you see when you open the file.
Everything is local: all the changes and history are on your machine, so you can work without a network connection. If a teammate’s repo is destroyed, you’ll still have everything.
Git is an “add-only” program–it ‘s very hard to get it to delete anything.
WordPress updates are a key reason to use Git. You don’t want to overwrite working code.
You only want working code on stage and master.
Git is amazing for managing your team code efforts…though it IS possible to overwrite your co-workers’ code, so you have to do it right.
You will thank yourself for having a Git workflow and sticking to it.
Git is basically a command-line app. There is a terrible default GUI, and some other GUIs, but some things HAVE to be done on the command line.
The GitHub app gives you a good introduction, but it has some drawbacks, especially if you’re dealing with a huge number of files.
Repositories are a place to save your code but they also offer additional services.
Git by itself is just versioning, not user management. For user management you need a Git server, either one you create yourself or a hosted server like GitHub.
Fetch gets code from a remote repo, but without merging it into your local repo.
Branches: there should be at minimum master (production), stage (for the staging server, to test), and whatever working branches you want. When you’ve finished testing, merge locally, then push to repo.
Git does not have a pre-defined workflow, so you have to create one for yourself and your team. Don’t MAKE changes on the stage or master branch. Make them in a branch and merge.
SourceTree will let you know if someone else has made changes that you need to pull down. (A pull notification means there’s something you need to pull down.) Ideally, you won’t have two people working on the same branch at the same time, but let’s face it, it will happen. If you’re both working on the same branch and you get a pull notification, stop what you’re doing, merge your changes, fork the staging branch, pull down the changes. Merge his changes to your branch, and if they work, back to stage.
“If you’re not sure what’s going on, make a fork of what you’re working on.”
You can force push your changes and re-set the repository.
Whether you create a readme file and a .gitignore file on GitHub depends on whether you’ve already got them on your local.
GIT DEPLOY TO HOSTING
WP Engine Git Deploy only goes one way, so you really want EVERYTHING in your local Git repo. (Or, well, the repo where you’re keeping stuff, which could be on GitHub or wherever.)
It’s easier to use the HTTPS version than the SSH, because with SSH you have to generate keys. Alas, both WP Engine and SiteGround require SSH keys. There seems to be an assumption you’re going to be working from GitHub so you can generate keys there.
If your code is already on a host, you can push the code from your host to GitHub and then pull it to your local install. (Assuming you have SSH access, of course.)
WORKING WITH GIT
Don’t be scared to delete Git and start again.
Revert is a pain. Switching branches is easier.
If you don’t commit a change, there won’t be any record of it, so if you want it saved for posterity, commit it!
Before you do anything else, “git status” to find out where you are and what’s pending
The head is the last point of the current branch.
If you find a conflict, humans have to intervene: contact your colleague and decide whose version to use. You have to tell Git you resolved the conflict by re-adding the files.