Help:Contents

From Group 4
Revision as of 20:06, 8 April 2013 by Erumeldir (talk | contribs)
Jump to: navigation, search

Coding Rules

Style

Help 1: I don't know the function header conventions!
Here's a tentative version of the function header convention, with examples in italics

/* function description this current object sends a message
	parameter: description of what it does
	curSocket: the socket we'll send the message through

	What it returns 
	Returns the number of bytes it was able to send, or an error value if unable to send

	Special notes 
	ERROR CHECK the return value
*/


Memory Management

1. Every object is responsible for deleting itself (by telling the object manager to delete it).

2. Notify the object manager immediately whenever an object is created

3. All objects have a unique id that is returned by the object manager

Status Report Help

Go to Main page and click on your name (or click your name at the top).

Write your status report there =D, here's an example:

http://cse125.ucsd.edu/cse125/2012/cse125g1/?p=289


Or here's mine xD: http://cse125.ucsd.edu/cse125/2013/cse125g4/index.php/User:Hmonciva


Note, you'll have to create an account first =) (Go to Create account at the top)


Git Help

Configuration

When first starting to use git on a computer, you must configure it with your username and email:

$ git config --global user.name "username"
$ git config --global user.email username@example.com

Repository Init

To clone the repository, run the git clone command. This will pull down every version of every file to your local file allowing you to modify and edit to your hearts content before pushing again to the server. Clone the repository with git clone [url]. For our project, use either:

$ git clone https://github.com/haroniti/NinjaCoders125.git
$ git clone git@github.com:haroniti/NinjaCoders125.git

Local Repository Management

Staging Files

Files in a git directory can exist as either tracked or untracked. Tracked files can be modified, unmodified or staged (ready to be added to the next commit). To check the status of your repository, run:

$ git status

To add a new file to be tracked by git, run:

$ git add [file]

After modifying a file, git will not automatically add it to its next commit, to add the modifications you have made in your file to the next commit, run the git add [file] again. Lastly, if you make any changes to the file after you have staged it with add, you must run the git add command again to stage the new changes.

Ignoring Files

We are going to want to ignore certain files like the visual studio user files, object files in our build folder, etc. To ignore these, modify the .gitignore file found in the top directory. Here's an example .gitignore found in the git documentation:

# a comment - this is ignored
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the root TODO file, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .txt files in the doc/ directory
doc/**/*.txt
Removing Files

To remove files from git run:

$ git rm [file]

This will unstage the file for your next commit.

Moving Files

Git does not track moved or renamed files, but it provides the git mv command which moves and re-adds the file for you:

$ git mv [OLD_NAME] [NEW_NAME]
Commits

Commits in git are pretty simple. Once you have the files staged, you can run the git commit command to commit the staged changes. You should run commit with the -m option which will allow you to add a commit message without the console opening up another program:

$ git commit -m 'commit message goes here'

Alternatively if you know that you want to include all your changes in your next commit, you can add the -a option which will automatically commit all tracked files with changes. You will still need to stage any untracked files however.

$ git commit -am 'commit message goes here'

Remember that all commits are local to your machine and will always commit to your local checked out branch.

Viewing Commits

There are two main tools to look at your commit history. (Once we have a lot of branches going simultaneously this will be VERY helpful). The first is the git log command. I really like the command with the following options because it produces a history in one line format with a ASCII graph (Yay ASCII art!) on the left:

$ git log --graph --decorate --all --pretty=oneline --abbrev-commit

This is a lot to type each time so I created an alias called git hist through the git config command:

$ git config --global alias.hist 'git log --graph --decorate --all --pretty=oneline --abbrev-commit'

When using these options, you will have to press q to exit the log. The second commit hist tool is the git diff command. This will show more detailed differences in the commit history. I am not very familiar with this command so if you find useful info, feel free to add it below:

$ git diff

Branching

Branching in git is awesome. Period. Do not be afraid to create a new feature branch when you're experimenting or developing a new feature. It can always be merged back into the develop branch or deleted.

Creating Branches

To create a new branch, you checkout to a new branch. This can be done explicitly:

$ git branch new_branch
$ git checkout new_branch

or switching to it immediately:

$ git checkout -b new_branch
Switching Branches

To switch between branches, you can simply checkout the branch with:

$ git checkout branch_name

Keep in mind every time you checkout a branch, it resets your working directory to look like the snapshot that branch points to. If you have any uncommited work on your current branch you will lose it unless you run a local commit.

Merging

Say we have done a lot of work in our current branch and we want to merge back into our develop branch, first checkout the develop branch. Then run a merge with the feature branch:

$ git checkout develop
$ git merge feature_branch --no-ff

If the merge Always use the --no-ff option otherwise git will remove the history of the feature branch and merge the history into the develop branch history (or whatever branch you are merging into) making it much harder to revert to branch history if needed.

Merge Conflicts

You will never have to manually fix merge conflicts unless the changes in the branches you are merging modify the same part of the same file. In this case git will spit out an error and tag the file with <<<<<<<,======= and >>>>>>>. The version of the file in your HEAD (the currently checked out branch) will appear above the ======= and the version you are trying to merge in will appear below. You will have to open the file and fix the conflict and then remove the <<<<<<<,======= and >>>>>>> markup when you finish. You can also set up a gui conflict merge tool and use it with the command:

$git mergetool
Branch Management

A list of all branches can be shown with

$ git branch

adding the -v will add the hash and one line description of the last change to the branch. To delete a branch if references are no longer needed (ie. in after applying a hotfix, preparing a release or closing out a feature), use the command:

$ git branch -d branch_name
Remote Branches

Remote branches are references to the state of branches on your remotes. They appear in the form (remote)/(branch). If you do work on a branch and someone their own version of the branch to the server, your histories will move forward differently (essentially just two different branches). To push your own changes you must first synchronize your work locally:

$ git fetch origin

This command will fetch all data that the server has and you don't. This will move your local versions of origin/(branch) to their current positions on the server.

When you want to share a branch you run:

$ git push (remote) (branch)

If the remote branch is already tracked (for example the origin/master or origin/develop branches). You can simply run:

$ git push

You can also push a local branch to a remote branch with a different name with:

$ git push origin local_name:remote_name

That being said, let's try to keep our branch names the same for organization sake.

If the server branch positions are different than your current local branch positions, you must merge in the origin/(branch) then you are ready to push to the server:

$ git fetch origin
...
$ git checkout develop
$ git merge --no-ff origin/develop
$ git push develop

You can also pull the server copy of your current branch down with:

$ git pull 

To track a branch that someone has put up on the server, you can use the git checkout command. Either one of these methods should work (the latter works only in v1.6.2 or later):

$ git checkout -b [branch] [remotename]/[branch]
$ git checkout --track [remotename]/[branch]

Checking out the second way will automatically create a local branch with the same name as the one on the server.

If you need to delete a branch on the server (for example, we know that a feature is officially closed and all work has been moved in) you can use:

$ git push [remote] :[remote_branchname]