Using Git

I have a new codebase that I want to put under source control (git), and I want to have a private repo on Bitbucket.

Creating a Git repo from existing files

git init           --This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton. 
git add <filespec> -- add your files...
git commit -m 'project commit message'

Connect Git repo to remote repository

Two popular repositories: GitHub and BitBucket. The Bitbucket Instructions for pushing your unversioned code to their repo is:

  • First initialize local dir with the above commands (git init, etc)
  • Log into Bitbucket, create new repo, then pick “I have code I want to import”
  • git remote add origin ssh://url-from-instructions
  • git push -u origin master

The gist of the above is using the built-in “remote” support of git by specifying an origin for the repo with git remote.

First Time Commit Instructions

Commiting a Durandal/Mimosa project to source control (all in mimosa-test root level)

  • git init
  • git add assets/javascripts/app
  • git add assets/font
  • git add assets/images
  • git add assets/stylesheets
  • git add bower.json
  • git add make.bat makefile
  • git commit -m “initial commit”

Next, followed the directions for commiting to bitbucket (git remote, etc)

  • git remote add origin https://dseah@bitbucket.org/dseah/inqsimtest-durandal.git
  • git push -u origin master

Updated Files

  • git add modified_files
  • git commit -m ‘commit message’
  • git status
  • git push

My first real git push!

  • checked git status
  • added *.sublime-* to .git-ignore file, because I didn’t want my sublime text projects to be included
  • I made sure there were no new files on the remote with git pull. There were none.
  • git commit -a -m "first modularized commit" to add all modified files.*
  • git status told me I was one ahead of the origin/master, recommending git push
  • git push, using default “simple” (which only pushes the current branch, not all of them)

I realized that the commit didn’t add all the new files, so…

  • git status to see what was going on
  • git add all the new files
  • git commit -a -m "modularized commit with missing files"
  • git push … yay!
  • git status reports “nothing to commit”

The clone of InqSimTest I have has now been significantly modified. I had originally grabbed it with git clone https://address.of.repo/ or something like that.

Git has the notion of your “working tree” in which files are “tracked”. Tracked files can be added to a temporary “staging area” using the git add command, which are then commited to the repository with git commit.

For adding/removing files to the staging area:

git status                  // Shows what has changed since last commit in current directory. Edit .gitignore as needed.
git add filename(s)         // Use to add new and modified to a "staged" area to commit
git rm filename(s)          // stage removal of a file. use -f to rm staged files. --cached to NOT delete from working dir
git diff                    // show exactly what changed IN the files in UNSTAGED files (not since last commit)
git diff --staged           // show

For commiting the staging area to the repository:

git commit                  // opens an editor so you can enter a commit message. all staged files will be put into repo
git commit -m "message"     // does the commit with your comment message specified as shown
git commit -a               // skip the business of staging files, and just commit everything tracked that&#039;s changed
git reset HEAD filename     // unstage a file you didn&#039;t mean to git add
git checkout -- filename    // revert a file to last commit

InqSim is officially living on a remote server, and I’m working with a clone. For working with the remote repository:

git remote                  // shows me the shortname of the server cloned from (default &#039;origin&#039;)
git remote -v               // show full name of server (url to remote)
git fetch [remote]          // pull changes but do not merge
git pull                    // pull changes AND merge from tracked repo (cloned repos are tracked by default)
git merge origin master
git push [remote] [branch]  // push changes to named server and branch (git push origin master)

Pushing changes will work  if you have permission and nobody has pushed in the meantime (which would make your 
push out-of-date, so you need to merge beforehand).

BRANCHING is cool. You can switch between entire working sets of files. MASTER is the main branch, and you can create more.

git branch [branchname]     // create a named branched
git checkout [branchname]   // switches to the named branch you just created

Before you switch again you have to commit your changes to the current branch.

git merge [branchname]      // merges changes from branchname into working directory
git rebase [base] [change]  // merges changes in [change] onto [base], then removes [change] like it was never there

git branch -d [branchname]  // remove the specified branch

Git will try to resolve multi-parented branches during merges automatically. If it can’t it will pause; use git status to determine what to fix. Once you fix the files, use git add to restage and then git commit to finalize it.

Do NOT rebase on PUBLIC branches, because people basing their work on yours will be enraged when their branch source disappears on them, stranding their work.

Forking your own Repo

This guide was most helpful. Create an empty repo on github, pull it down to your machine. Add an upstream master, then pull the upstream master, then push the origin master:

git clone https://github.com/YOURUSERNAME/forkedrepo.git
git remote add upstream https://github.com/YOURUSERNAME/originalrepo.git
git pull upstream master
git push origin master