and I will borrow some of the materials from git-scm.com and github.com There are plenty of in-depth (and better) tutorials and videos that get into a lot of the details that I may gloss over.
to go back and revert changes and recover or compare against old version ◦ Makes experimentation easier (using branches) • To Facilitate Collaboration ◦ Allows you to make modifications to files in parallel as a team and merge the result
git init # in the project's top level directory • An existing project (more common) ◦ git clone [URL] ◦ git clone https://github.com/mininet/mininet.git Note: Projects will contain a .git directory that will track will contain all changes and metadata. Also, if you don't have git installed, do this first: https://help.github.com/articles/set-up-git/
a project ◦ usually "stable" and "deployable" • topic branches ◦ best practice for changes ◦ local only, unless you push them somewhere git checkout -b my-feature master # to create git checkout master # to switch branches
a new repository with the latest code • git pull [remote] [branch] ◦ gets the latest code for the specified branch on the remote and merges it into your current local branch • git fetch [remote] ◦ updates your local metadata with the latest information about the remote repository
the same file in a conflicting way ◦ Usually manifest themselves when you do git pull • What you'll see ◦ CONFLICT (modify/delete): ... # Automatic merge failed; fix conflicts and then commit the result. • How to fix it ◦ Update the offending file(s) ◦ Stage the changes using git add [filename] ◦ Commit using git commit
project • Somewhere to push your local changes ◦ And collaborate with others on them, too! • Push your changes to GitHub ◦ git push origin [branch name] • To fork, click the "Fork" button on the upstream project page in GitHub ◦ Creates a clone of the upstream in GitHub
tracker ◦ Useful for reporting bugs, tracking new features, etc. ◦ Automatically integrated using commit messages e.g. "Closes #843" • Wiki ◦ Great place to put project documentation e.g. installation instructions, tutorials, etc. ◦ Editable by anyone with a GitHub account ◦ Versioned
certain files or patterns, like build artifacts • git stash ◦ Useful for quickly stashing local changes while pulling/updating code • git rebase ◦ Replay your branch from a new parent ◦ NEVER rebase code that's been pushed* ◦ Used heavily in Gerrit workflow