Conference hashtag: #devsigner
Session evaluation: devsignercon.com/eval
Conference hashtag: #devsigner
Session evaluation: devsignercon.com/eval
Conference hashtag: #devsigner
Session evaluation: devsignercon.com/eval
(or use my USB drive)
https://www.sourcetreeapp.com/download
(or use my USB drive)
https://github.com/danmuzyka/time-travel-parallel-universes-git
You are going to make a copy of what we call the repository and put the copy into your own GitHub account.
A repository consists of the files that Git tracks for you.
Click the button to Fork my repository into your GitHub account.
Copy the URI for the repository.
Clone into SourceTree:
Paste the URL into the Source URL field. You can leave the default values in the other fields.
Click the button to reveal the selected file in the folder where it lives.
Then, open that file in a text editor.
Read what's in the story so far - it is a metaphor about Git.
Now let's travel back in time to a previous moment in the story. Select My hotel room from the list, then click the Checkout button.
Click OK.
Accept the warning and click OK.
Normally you wouldn't do things this way, but we're doing it now for demonstration purposes.
Notice that HEAD is now at "My hotel room." HEAD is just where you currently are.
Close, then re-open the story in your text editor. You should see that the story now stops at a previous point in time.
Now let's jump forward in time, to one of several possible futures. You can see several possibilities branching off from where you are.
Let's switch to the branch (the parallel universe) named Down-the-Hall.
Click on Down-the-Hall.
Click Checkout then click Checkout New Branch.
In the drop-down, select origin/Down-the-Hall. Click OK.
Now the branch (parallel universe) that existed on GitHub also exists on your computer.
You can compare what is different between two revisions (known in Git as "commits").
Close and reopen the story. You should now see the version of it that lives in the Down-the-Hall branch.
Now you have uncommitted changes.
Go ahead and save a snapshot of this version of your story by committing your changes.
Your changes are now "staged."
Staging is a way to identify which changes you want to package together in this snapshot of your project ("commit" in Git terminology) and which changes you want to leave out of the snapshot.
In our case, we only have one file, so we can't include some changes and leave out others.
Click Commit . This tells Git that you want to make a snapshot of all of your staged changes.
Now you can enter a commit message (the "photo caption" in the story) to describe the changes.
The new commit now appears. It is ahead of "origin" (GitHub) because it only exists on your computer right now.
Suppose you are in the middle of making changes but aren't ready to commit them, yet.
Then, you need to switch gears and work on unrelated changes. What is a good way to do that?
You have changes in the Down-the-Hall branch, but you need to pause that work and make some changes to the Window branch.
Click the Stash button.
Optionally enter a message, then click OK.
The changes disappear, but they are tucked away in a stash for later retrieval.
Switch to another branch:
Now you can make whichever changes you need on your Window branch.
When you're finished, switch back to the Down-the-Hall branch.
You could check out existing this time because you have previously copied down the branch from origin (GitHub) to your computer.
Now right-click on your stash and select Apply Stash, then click OK.
At this point, either undo your changes, or commit them.
Having separate branches allows you, or an entire team, to work on different parts of a project at the same time.
When the work in a branch is finished, you need to be able to merge it in with your other changes. Merging code is a powerful feature of Git.
Let's merge some changes into the root of the project, also known as the master branch.
Start by checking out the master branch by following the same procedures we have been using.
Click the Merge button , then select the Prank-call branch and click OK.
Your local copy of master now has the content of the Prank-call branch merged in.
Notice that your version of master is now different from the one on origin (GitHub).
Let's merge in another branch: Window.
Click Merge , click Window, and click OK.
We have merge conflicts. That's OK! We can resolve that issue.
To resolve the merge conflict, open the file, and find the lines that Git added:
<<<< HEAD
=========
>>>> Window
The part between <<<< HEAD and ==== is what was in your branch before.
The part between ==== and >>>> Window is the text from the branch that you tried to merge in.
The blocks of text between these lines represent what is different between the branches that Git couldn't merge automatically.
Usually, Git can figure out how to merge the branches automatically, but sometimes it needs help.
Usually, the number of conflicting lines that Git can't resolve automatically is fairly small.
This example has larger merge conflicts than this speaker typically experiences.
To resolve the conflict, just manually edit the document to include the specific content you want from each branch.
Save your changes.
Click Commit to commit the changes you just made and complete the merge.
Select the file in the Unstaged files section, then click Add to stage the changes you made. Click Commit.
You have successfully merged the branch into master!
Now that you've made some changes, you're ready to share them with the world. You can push them up to GitHub so that others can get your changes.
Click the Push button.
Select the remote location where you want to push. In this case, we only have one, GitHub, which is nicknamed origin.
Select the branches you want to push to the remote. Click OK.
Your changes are now on GitHub. :-)
You've worked on this project on your own, but now you're ready to merge in the work of a teammate.
Normally you and your team members would be pushing and pulling from the same remote, but in this case you'll pull from the remote of someone else in this workshop.
Turn to another person in this workshop and ask for the clone URL of his or her GitHub repository.
In SourceTree, select Repository > Add Remote...
Paste in the other person's clone URL in the URL/path field.
Just as your GitHub remote is nicknamed origin, your collaborator's remote needs a nickname.
For example, you could use the person's first name.
In the Remote name field, give this remote a nickname.
Click OK.
Click OK again.
Your friend's remote is now available.
To pull down and merge the changes from your friend's version of the master branch, click the Pull button.
Select your friend's remote.
Select the master branch of your friend's remote.
Click OK.
If there are any merge conflicts, resolve them using the same process as we did earlier.
You have successfully merged in the master branch from your friend's remote.
Conference hashtag: #devsigner
Session evaluation: devsignercon.com/eval
Conference hashtag: #devsigner
Session evaluation: devsignercon.com/eval