404 Git Procedures

Easy Git Cheat Sheet

Pre-Git setup

You can set your git up to use your editor of choice for resolving merge conflicts, rather than having to deal with ViM. If you change your default to Atom, for example, any time you get a merge conflict Atom will open and show you in colour what the conflict is. You can click a button to choose the bit of code you want to keep, then resolve the merge conflict from there. To select your default editor, type the following into your command line:

git config --global core.editor “atom”

where you replace "atom" with your personal editor.

One Golden Rule

YOU DO NOT WORK ON THE MASTER.

Any work on a new feature or ticket needs to happen on a local feature branch.

Local feature branch

When working in pairs/small teams, create a local feature branch on your machine to work on the ticket:

git checkout -b <_your_branch_name_here_>

This creates a new branch called whatever you want AND checks you out to it. If you now run:

git branch

It should tell you in green that you're on your new feature branch.

Next, create a remote branch on GitHub:

git push -u origin <your_branch_name_here>

Proceed with the ticket, making regular commits on green.

Finishing your feature and creating a pull request

When you're happy you've completed the feature and all your tests pass, push to your remote one final time. Next, go to the repository on GitHub and click 'Branches':

Next, find your feature branch and click 'New pull request':

In the next page, click the 'Choose a base repository' button and make sure our repository is selected (the one highlighted in blue):

Fill out the text box with a title and a helpful description of what functionality the feature branch adds, or what problem it fixed, then click the big green 'Create pull request' button.

Once the team has reviewed and approved the changes, possibly with comments, the team that owns the feature branch clicks the 'Merge' button.

IGNORE STUFF BELOW

First, checkout out onto your local master branch:

git checkout master

Because another team might have been working on another ticket and already completed their feature, your local master branch might be behind the remote. Run:

git pull

You may see your master branch update at this point.

Next, merge your feature branch in:

git merge <_your_branch_name_here_>

If you're lucky, the changes from the other team that may now have been added will not interfere with the merge. The merge will finish and your local master is now the most up to date version of the whole project. Now is the time to raise a pull request on GitHub. Get it reviewed.

Following a review, the team that worked on the feature can now make the merge to master. If you're lucky, there will be a big green Merge button on the pull request page. Click this, and GitHub will handle the merge from your local master to the remote repository. If you get a message like, "GitHub cannot automatically merge", you'll need to proceed manually from the command line.

If you now run:

git push

or

git push origin master

if you changed your remote, the push might magically work, and everyone now has access to the newly-updated project. You can now delete your feature branch:

git branch -d <_your_branch_name_here_>

However, if the auto-merge button was missing from the pull request page, there'll probably be a merge conflict.

Merge Conflicts

First, if you get a merge conflict and you're not happy with it, stop, hands off the keyboard, and get Luke. Do not start banging commands into the command the line to see what happens.

Don't do it.

Don't.

Merge conflicts are almost certainly going to happen. Following an attempted merge, you may get a conflict. First, if you set up your default editor as above, Git should boot you into your editor the second you encounter one.

Using Atom as an example, you will be shown something that looks like a diff, one highlighted in pink, one highlighted in blue.

At this point, stop.

It may be that both you and another team have added something like a dependency to a gemfile, and the project will need both. Go and get the other team and, between you, make each other aware of the changes that have been made. If you decide that you only need one version of the code in the file, you can now click the button that says "Use me" in one of the two highlighted boxes. If you decide that you want to keep all the code in the file, manually edit the file right there in the editor.

Note: I've never done this. If this occurs, get everyone round and we'll see what happens (Luke).

Once the correct final version of the conflicted file is ready, either use the Git integration tab in Atom to stage and commit the file (with a commit message like "Merge resolution"), or go to the command line and run:

git add .

then

git commit -m "Merge resolution"

If there was only one conflicted file, this will end the merge conflict, and the merge will finish successfully. If there's more than one conflict, each file needs to be manually edited (again, with both teams present so as to not lose any code that's important) then added after. After each edit, run:

git add <fixed_file.rb>

Once all conflicted files have been edited, make a conflict resolution commit as above.