git workflow OS X

git-workflow.md

First, you have to get your repository. Use git clone to get the repository into your current directory form the terminal

git clone https://github.com/craigbeck/git-workflow-demo.git

The above will create a directory git-workflow-demo in the current directory that contains the "repo" (assuming a real repository, the above URL is just a made-up example). Change to this new directory with cd git-workflow-demo. Your newly cloned repo should look something like this:

$ ls -la
total 24
drwxrwxr-x 4 cbeck cbeck 4096 Apr  1 09:20 .
drwxrwxr-x 8 cbeck cbeck 4096 Apr  1 09:08 ..
drwxrwxr-x 8 cbeck cbeck 4096 Apr  1 09:22 .git
-rw-rw-r-- 1 cbeck cbeck  628 Apr  1 09:13 .gitignore
-rw-rw-r-- 1 cbeck cbeck    0 Apr  1 09:13 index.js
drwxrwxr-x 3 cbeck cbeck 4096 Apr  1 09:14 node_modules
-rw-rw-r-- 1 cbeck cbeck  255 Apr  1 09:14 package.json

Now get to work!

Okay, so the repo has been clones and you need to make some changes to add a new feature/whatever. The general workflow shuld look like this:

1. ensure you are in master branch git checkout master & git pull to make sure you are up-to-date
2. create a new branch from master for your changes with git branch or the short cut git checkout -b (the -b means create new branch). You are now working with your own branch of the master code

Now you are ready to make changes and "push" changes back to the "origin" repository (eg. BitBucket). To commit your changes you can use git add to add new files or stage exiting files for commit, then use git commit to commit the changes to the repo. This step can be much easier to do with a GUI tool like GITx to do the staging/unstaging of files.

Git is a distributed version control system so your local git repo is a 100% legit fully first-class repository just like the ones hosted on BitBucket or Github. To get your changes to your team you have to "push" your changes to these other repositories (typically called "origin" in git-speak). Pushing your changes can be done with git push origin, and this may be easier done from a GUI.

If you're using the terminal and the git command you may run into issues like this:

$ git push origin
fatal: The current branch feature-A has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature-A

So that push didn't work, but git tries to be helpful and often gives a example of the command to run to accomplish what you want. In this case there is some configuration that git needs, so following the suggestion results in success:

$ git push --set-upstream origin feature-A
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 343 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/craigbeck/git-workflow-demo.git
 * [new branch]      feature-A -> feature-A
Branch feature-A set up to track remote branch feature-A from origin.

You can continue to work like this -- making changes, committing, pushing -- as long as you want. To get these changes back into the "master" branch in the origin repo means "opening" a "pull request" in BitBucket/Github. This can be done at any time after pushing your branches to origin. You can continue to work/push etc and the pull request provides a unified view of the ongoing work and remains separate until it is "merged" into master branch but "closing" the pull request.