Basic git Setup with BitBucket (for OS/X)

22 Apr 2014

Lately my sister has been working on her first php site. I wanted to tell her how to set up a git repo at BitBucket with ssh keys. Then, I realized a handful of other people have asked me about the same thing, and decided to make a blog post instead of an email. I know this is a bit scrappy, but it will at least get you started. Since this is geared at my sister, I'm assuming OS/X, but the instructions aren't too different on Linux.

Why BitBucket?

Well, it's git and has free private repositories. Use any server you want.

Why ssh?

I prefer using ssh authentication. There's no password typing.

Setting up BitBucket...

...or whatever git server you want.

  • If you don't have a BitBucket account, sign up at bitbucket.org
  • Log in
  • Create a new repository. Repositories -> Create repository
    Name should probably be one word. Private repository, Git, don't turn on issue tracking or wiki unless you want it. Language is optional, for this scenario try php if you care.
  • Do you have git installed? Run this in a shell to find out:
    which git
    If a path comes back, you have git. Otherwise, you need to install it. To install git, first install homebrew, then run:

    brew install git

  • Before git operations will succeed on the bitbucket server over ssh, it will be most convenient to add your public ssh key to bitbucket's server.
    1. If you don't have ssh keys set up yet, create them by running:
      ssh-keygen
      Use the default values and do not enter a passphrase.
    2. At bitbucket, go to Manage Account -> SSH Keys
    3. Paste in the text content of ~/.ssh/id_rsa.pub. Make extra sure to use the .pub file, because it contains your public key.
      You can try:
      cat ~/.ssh/id_rsa.pub
      And then paste the text into bitbucket
  • If you opt to use bitbucket, you'll need to get a connection string. Go to the repository you created, and look for the connection string there. You'll want to use the ssh one. A sample connection string is:
    git@bitbucket.org:user/repo.git
  • Now we're going to go to your codebase and initialize a git repo there, then push it up to the BitBucket server.

    cd /path/to/my/repo    # here, change the directory to match your project
    git init .             # initialize a local git repository
    
    # these commands can be used repeatedly to commit new changes
    git add path/to/files # add all the files that need to be in the repository
    git status             # use this command to see the state of your git repository
    git commit -m "Commit message here"
    
    # run these commands just once to set up the remote origin of the repository
    git remote add origin git@bitbucket.org:user/repo.git  # take this url from bitbucket
    git push -u origin --all # pushes up the repo and its refs for the first time
    git push -u origin --tags # pushes up any tags

  • Share the repository with your friends. On bitbucket, manage the repository, and under "Access Management" add your friends' bitbucket ids.

Basic Git stuff

If you're on OS/X, I recommend that you download the popular GUI utility, gitx, to view changes, logs, etc.

A file goes through various changes in git.

  1. It is added to the repository. This can be used for new files, or modifications to files already in the repo.
  2. Once a file is added, it will show up as staged when you run
    git status
    . Then, the file can be committed. A commit creates a new version of the local repository with the changes you selected.
  3. After changes are committed, your local branch is "ahead" of the remote branch. At this point, you can push changes to the server.
  4. I can pull your changes into my local copy of the repository.

So, for example. Let's say you make a change that you want me to have. So, first you add the file, then commit it, then push it. I pull it, fix a spelling error, add it, commit it, and push it. Now, when you pull from the server, you will receive the changes I pushed earlier!

As a rule of thumb, you should always pull before trying to push changes to the remote origin. Why? Because you don't know if someone else has already pushed changes. You'll have to figure out how to merge the changes in your local version of the repository, and only then can you push to remote.