Hey, you!
Git Outta My Stash!
A little about me...
That's my family!
Zoni
(29 a few times)
Zander (14)
Lauralynn
(11)
Owen (15.9)
Jason
(Dirt)
- Born in Rochester, NY (on St. Patty's Day)
- Grew up in the Shenandoah Valley of Virginia
- Served an LDS mission in Boston 20 years ago
- Lived in TN for 17 years before moving to Tallahassee for 2 years
- Doing web development since 1995 with everything from PHP to Django to ASP.NET to JS (and I love JS)
Everyone's favorite subject: History!
History of VCS
A brief history: two developers started working on the same file. A fight ensued. One of the developers (the loser of the fight) started building a version control system. By the time it was implemented, the winner of the fight had quit...
VCS History: Generations
- First Generation:
- No centralization
- File-based Locks
- Some frustration, first inclination was to become a monk and leave the situation
- Examples: RCS, SCCS
- Second Generation:
- Centralized server
- Initial steps towards commit before merge
- Still some frustration, but every dark tunnel has a lighter hope
- Examples: Team Foundation Server, SourceSafe, Subversion(SVN), CVS
VCS History: Generations
- Third Generation (current):
- Distributed
- No locking, commits locally before merging with the branch remotely
- Can be used entirely without a server
- Comparatively frustration free
- Examples: Git, Mercurial (Hg), Bazaar
WHY?
Srsly, Y?
*DF (i.e. ADF, SDF, CDF, WTFDF) files are just XML code.
Multiple Content Engineers are touching these files.
There's no real history for these files, so if a change that was made last year needs to be reverted...
Let's talk Stash...
Let's talk Stash...
-
Commercial product from Atlassian
-
Git-based Distributed VCS (DVCS)
Stash Hierarchy
Projects
Repositories (Repos)
Branches/Tags
Commits
Code
DEMO TIME!
Time to Git Down
Basics of Gittin' Down
- Git is a Distributed Version Control System
- Git (contrary to popular believe) requires no server
- Most of the work you do with git stays local to your machine
- Terms to know:
- commit
- merge
- push/pull
- fetch
- alias
- origin vs. remote
Local
Most of your work is actually done locally. commit is local. checkout is usually local. merge is done locally. You pull from remote to local.
Remote
Remote is the "golden" copy of the code. About the only thing you do with remote is push your local work to it. (OK, and fetch is used to pull remote branches, but you don't use it often.)
commit
checkout
merge
pull
push
fetch
Near
Far
To the command line!
Useful Git Commands
-
git config [scope] [commands]
git config --global editor.core atom
git config --global alias.ec config --global --edit
git config --global alias.co "checkout"
git config --global alias.cob "checkout -b"
git config --global alias.cm "!git add -A && git commit -m"
git config --global alias.masterpull "!git co master && git pull"
-
git init - You will likely never actually use this, as it's for creating a new git repo locally. Typically, you'll want to create the repo in Stash first, and then clone it. Speaking of clone...
-
git clone [address to git file] - Makes a clone of the remote repository into a local folder (named the same as the remote repo)
Useful Git Commands
git fetch
Fetches all of the branches available on the remote host
git checkout [branchname]
"Checks out" the branch indicated. Note that this will use local first, and then (if not found locally) attempt to checkout from the remote host
git pull
Creates a new local branch with the name indicated
git co [branchname]
git cob [branchname]
"Pulls" the code from the remote server for the branch you're currently in
git checkout -b [branchname]
git reset --hard HEAD
Resets your current branch to the HEAD commit of the current branch. Basically, it's your ultimate Undo button.
Useful Git Commands
git add [files to add]
Adds the list of files provided to the local repository. Use -A to include all modified files.
git commit -M "Message here"
Commits all changes made (since last commit) to the local repository.
git cm "Message here"
Does both of the above with one step. (Aliases ROCK!)
git push
git push --set-upstream origin [branchname]
"Pushes" the code from the local repository for the branch you're currently in to the remote repository (The second command is required after creating a new local branch when pushing for the first time)
git stash
"Stashes" all modifications in a local cache. (FIFO)
git stash apply
Applies changes in the "stash" to the current branch.
CAUTION: Wild Merges Ahead!
A long time ago, we used to be friends...
- Merging is the number one hardest thing about git
- To merge, use git merge bra where the branchName is the name of the branch you want to merge into your current branch. Typically, this will be master.
- Merge conflicts occur when the file being merged in has modifications to the same areas as modified pieces on the current branch.
git merge [branchName]
Say WHAT?
My branch
Master branch
<item>
<id>OU812</id>
<genre>ROCKIN'</genre>
<artist>Van Hagar</artist>
</item>
<item>
<id>OU812</id>
<genre>ROCKIN'</genre>
<artist>Van Halen</artist>
</item>
Which one is right and which one is dead?
Merge Results
<item>
<id>OU812</id>
<genre>ROCKIN'</genre>
- <artist>Van Halen</artist>
+ <artist>Van Hagar</artist>
</item>
Not so fast there...
Merge conflicts are often multiple lines in multiple files, and in many cases both sets of changes will be correct.
Which one is right and which one is dead?
Resist the urge...
As hard as it may be, resist the initial urge to just accept all of your changes as correct.
Merge conflict resolution is time-consuming but will ensure the proper information is retained.
Use a tool, please
This is the one area of using git where I HIGHLY recommend you use a diff/merge tool.
Free
Not Free (but the best)
Title Text
SourceTree Demo
Merge vs. Rebase
Merge
Rebase
will create a new commit to the feature branch which merges the master and featurebranches together.
git merge master feature
git checkout feature
git rebase master
will move the entire feature branch to begin at the tip of the master branch.
Creates a bit messier log/history, but can be used for all merging (public and personal)
Creates a "prettier" log/history, but should NEVER EVER be used on "public" branches, like master.
NEVER EVER NEVER NEVER NEVER EVER on master
Is that it?
Commit Messages
- Keep them short and simple
- Make them useful (describe what that commit did)
- Have some fun!
Pull Requests
- Pull requests are not required (depending on how your remote repo is setup) but highly recommended
Gitflow (recommended, not required)
- Clone repo from remote
- Branch from master
- Make changes to your local branch
- Push those changes to remote repo (Stash)
- Create a Pull Request (a request to pull changes from your branch into the master branch)
- Pull Request is reviewed by team members and comments are made
- Once approved, pull request is merged to master
Reversions
Honestly, WAY outside the scope of this session. If you want more information about reverting commits, we should have another session. Hopefully, you won't need to. When you do, find a git guru to help!
- Revert creates a new commit with reversions of the commit reverted (merge conflicts will probably abound)
- If uncommitted, use git reset
- If committed, use git revert
git revert
git reset
If it all goes horribly wrong???
Delete the folder, reclone.
(Don't feel ashamed. Everybody who has ever used git has probably resorted to this solution at least once.)
Git Outta My Stash
By Jason Clark
Git Outta My Stash
- 1,117