First, let's get a git client. If you are on windows, I recommend one called msysgit. It gives you access to a start menu item, known as Git Bash - this will look and feel a lot like a Linux terminal.
When you've done that successfully, you'll be confronted with a screen:
- I am starting from scratch
- I have code to import
Selecting "I have code to import" will give you a number of git commands as examples - to initialize a repository, to add your content, and to add a remote.
There are two main protocols that git can make use of - https and ssh. The https URLs look like
... and for the moment, are the simplest to understand. If you already know about SSH and SSH keys, use the other protocol.
When you add a remote, you give it a name - in this case, origin. This is just a shortcut for the bitbucket server - you can choose any name you like; however there is a widespread convention to use origin with the main repository.
For windows users,
- Git Bash - this is much like the windows command line (cmd), with a few different commands.
- Find your existing code - cd /c/path/on/your/hard/disk - note the direction of the slashes!
In Git Bash, instead of seeing a prompt like c:\>, the prompt ends in a $.
To get to your c:\ drive
$ cd /c/
To get to another path
$ cd /c/path/to/location
If you aren't sure, you can hit the TAB key repeatedly to autocomplete your filenames or show you a list of suggestions.
Once you have located the right directory with your existing code, we want to initialize a repository
$ git init
Next, add a remote called origin pointing at bitbucket.
$ git remote add origin https://email@example.com/you/repository_name.git
Tell Git to monitor the files - this is like an svn add.
$ git add .
To see the affect of git add, do
$ git status
# On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cachedYou can see the code is now being tracked. It wants you to commit.
..." to unstage) # # new file: A.xml # new file: B.java # new file: C.wsdl # new file: D.wsdl # you@yourcomputer ~/path/to/local/code (master)
So, perform your first commit:
$ git commit -m "Importing my code" -a
[master (root-commit) 0bba05d] Importing my code
4 files changed, 127 insertions(+)
All done, right? Not quite. You've made a commit, but this is only local to your repository. Think of it as the save command in a word document - it doesn't publish anything, but it lets you undo/redo changes.
From here you can do as many changes and as many commits as you want.
$ git commit -m "fix typo"
$ git commit -m "remove swearwords"
Also, you probably saw some warnings like:
*** Please tell me who you are. Run
git config --global user.email "firstname.lastname@example.org" git config --global user.name "Your Name"
It's worth doing this, as each commit is attributed to a user - you'll only have to do this once. Don't worry too much: your commit will still have succeeded.
Anyway, you can check the status again with
$ git status # On branch master nothing to commit, working directory clean
It should tell you if there are any untracked files (git add them), or uncommmited files (git commit them) - but ideally, it should look like the above.
To publish your changes, you need to push them. For simplicity, we'll also set a default destination (via -u) - the origin remote repository; master branch.
$ git push -u origin master
Password for 'https://email@example.com': Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 3.81 KiB, done. Total 6 (delta 1), reused 0 (delta 0) remote: bb/acl: you is allowed. accepted payload. To https://firstname.lastname@example.org/you/repository_name.git * [new branch] master -> master Branch master set up to track remote branch master from origin. you@yourcomputer ~/path/to/code (master)
... and check bitbucket.org - your code should be published!
Great - but what just happened? If you look at the diagram, we've done everything on the left hand side - have a local, have a remote, and pushed changes. It's now possible for someone else to clone your repo, or fork it, and pull changes.
You can see that there can be many repositories - sometimes teams will maintain a 'core' repo, and people on the outside take a 'fork'.