git ± intro – Clients – Getting Things Done



git ± intro – Clients – Getting Things Done

1 1


Git-Intro

A gentle introduction to Git.

On Github ZoogieZork / Git-Intro

git ± intro

Wed Oct 22 2014 :: Mike Imamura

8-step program forbetter source control

  • Speed
  • Reliability
  • Flexibility
  • Scalability
  • Extensibility
  • Fairness
  • Openness
  • Tool Integration

Clients

TortoiseGit (Windows) Command-Line GitHub For Windows GitHub For Mac

Installing Git

Debian / Ubuntu apt-get install git RedHat / Fedora yum install git Arch Linux pacman -S git Gentoo emerge dev-vcs/git

Tell Git a Little About Yourself

Git uses email addresses to identify users.
git config --global user.name "George P. Burdell"
git config --global user.email gburdell@example.com
These can be per-repository — just leave off the --global

GitHub

Free repository, issue tracker, wiki, and simple website for Open Source projects.

git clone

Make your own personal copy of the repository.
git clone https://github.com/ZoogieZork/Git-Intro.git

Getting Things Done

Get the latest changes:
git pull
Make some changes, then stage them:
git status  # List changes
git add new_file.html modified_file.html
git rm deleted_file.html
git checkout file.html   # Undo modifications

Commit staged files:

git commit

Getting Things Done, cont'd

Before publishing your changes,get everybody else's changes first:
git pull

Publish your changes:

git push

Getting Things Done (faster)

Stage all changes:
git add -A .
Commit all modified and deleted files(but not new files):
git commit -a

.gitignore

Add a .gitignore file to exclude files from the shortcut commands (e.g. git add -A).
# Ignore files in this directory and all subdirectories.
*.class
*.pyc

# Ignore specific files and directories
# (relative to this directory)
/target/
/test/output/*.xml

Getting Things Done (smarter)

Stage only part of a file:
git add -p file.html
Show your changes in the commit editor:
git commit -v
Temporarily save what you're working on…
git stash
… do something else …
… then pick up where you left off:
git stash pop

Branches

Create a new local branch:
git checkout -b fixes

Create a local branch based on a published branch:
git checkout --track origin/fixes

Switch between branches:

git checkout mastergit checkout fixes

Merging

Merge "master" to your branch:
git checkout fixes   # Switch to your branch.
git merge master     # Merge changes from master
Merge your branch back into "master":
git checkout master  # Switch back to master.
git merge fixes

All done with the branch, delete it:

git branch -d fixes

Sharing Branches

Publish your branch:
git push -u origin fixes
Delete a published branch:
git push origin --delete fixes
Or "git push origin :fixes" if you're sufficiently oldschool and/or hardcore. You know who you are.

Pull Requests

GitHub
Review & discuss changes before merging

Pull Request

Gather your changes in a branch. Publish the branch. Create a Pull Request on GitHub.

intermediate ± git

Here be bobcats

Rewriting History

Optimist: If you haven't pushed it yet, you can still change it
Pessimist: If you change a pushed commit, bad things happen
History is written by the victors, and we're all winners here.
(don't change published history)

Oops, I made a typo…

Stage your fixes like usual...
Then amend the previous commit instead of creating a new one:
git commit --amend

pull + rebase

Pull in other people's commits, but move your unpushed commits to the end.
git pull --rebase
Some teams prefer this since it results in more linear history.
Which is easier to read if you're trying to get from point A to point B, the turn-by-turn directions from Google Maps or the London tube diagram?

Rebase Whole Branches

Move all of the commits in your local branch to the end of the branch it split off from:
git checkout mybranch
git rebase master

Rewind History

Undo the previous commit:
git reset HEAD~
Undo the previous two commits:
git reset HEAD~2
There's also the --soft and --hard modes, but we won't get into those here, since it can get a bit involved. If you're really curious, and like diagrams, then try this detailed explanation.

Heavy-Duty History Rewriting

Reorder, edit, reword, drop, split, combine history.
git rebase -i
This is interactive — it will open an editor with a list of your commits along with instructions.
Y'know, for winners.

Repository Maintenance

Save disk space by clearing out stuff that's no longer important.
Clean out old deleted upstream branches:
git remote prune origin
Clean out abandoned commits, recompress files, and much more:
git gc
There's also the --aggressive option to gc for those who are truly desperate to reclaim as much space as possible.

Question Time

Fork ThisPresentation

Advanced ± Topics

Also known as "further reading".

If you've found this section, then congratulations! You're in for a magical world of refspecs, indexes, and... er...

Actually, no, this is more of just an overview of advanced topics for another time that I threw in at the last minute.

Bringing Repositories Together

Submodules

git submodule add repo dir
Embeds a separate repository as dir.
The repository is kept separate.

Bringing Repositories Together

Subtree

git subtree add --prefix dir repo branch
Merges a separate repository as dir.
The full history of the repository is pulled in, as if it had always been a part of your project, living at that directory.

Find That One Bad Commit

Given a good commit and a later bad commit, interactively find the commit that caused all the trouble:
git bisect start
git bisect good good-commit
git bisect bad bad-commit

Bisect Through History

Run your tests and either mark the current revision as good:
git bisect good
… or bad:
git bisect bad
… until there are no more revisions to check and Git tells you which commit was the culprit.

End the Bisect Session

git bisect reset