Need better git-fu

by Security Dude

Creating a new repo on Github

  • go to github, click ‘New Repository’ on right
  • give a name, choose public or private (requires paid account), click ‘Create’
  • In the ‘Quick Setup’ box, click ‘https’
  • If you don’t have a project to share, run ‘rails new foo’ to create one for this example.
  • $ cd foo
  • $ git init # only have to to once per project
  • $ git commit -am “initial commit” # we’ll explain this in a minute
  • $ git log # should show you five lines of output
  • $ git remote add origin https://github.com/bigsnarfdude/foo
  • $ git push -u origin master

How to add teammates:

  • Go to your repository on github (eg. https://github.com/bigsnarfdude/foo )
  • Click the ‘Admin’ tab
  • Click ‘Collaborators’ on the left
  • add their github usernames, one at a time

When added as a teammate:

  • Go to the repository on Github (eg. https://github.com/bigsnarfdude/foo )
  • Under the menu in the page, next to the button labeled HTTPS, copy the URL
  • $ git clone https://github.com/bigsnarfdude/foo.git

To save changes:

  • Edit your code as normal. For this example, edit the README to include your name.
  • $ git status # list of changed files
  • $ git diff # see all changes
  • $ git add –all # this will ‘stage’ all of your work, we’ll explain more options if we have time
  • $ git commit -m “add my name because Vincent told me to”
  • for multi-line messages, just type ‘git commit’. If you end up in vim, you can type :q to quit. To change your editor to something friendlier: git config –global core.editor “mvim”

To share your work:

  • $ git push origin master
  • If you get a warning about ‘failed to push some refs’ and ‘Updates were rejected because the tip of your current branch is behind’, it means someone else has pushed up changes that you need to pull before you can push your code.

To pull others’changes:

  • $ git pull –rebase
  • This copies down all the changes your teammates have shared, and “rebases”, replays any changes you have made on top of this.
  • Every commit points to the commit that came before it, so this edits your work and you might get a scary “merge conflict”, when git is confused because you both edited the same code.

To deal with conflicts:

  • This happens because you and someone else edited the same code, and git can’t guess whose work to keep. It is your job to examine the conflict and sort it out. You will get a big scary message. This is OK, your work hasn’t been lost, and you can read it for a cheat sheet of how to fix things.
  • $ git status # to get a list of changes and see what needs to be done
  • Edit the files, look for <<<<<, which marks conflicts
  • When you’ve fixed all of them: $ git add -a # to stage your work
  • $ git rebase –continute # to finish the merge
Advertisements