Sourcetree Unstaged Files

Sourcetree Unstaged Files
  1. Sourcetree Unstaged Files Downloads
  2. Sourcetree Unstaged Files Search
  3. Sourcetree Unstaged Files Without Changes
  4. Sourcetree Unstaged Files Remove
  1. If a mercurial repository is opened in SourceTree, the function will appear as Shelve instead of git's Stash. To stash your changes: First, there has to be a change done to a file.
  2. The file is listed in the Unstaged files list then you should stage it and then commit and push them. If it's listed in the Staged files list then commit and push them. If you see your commit message listed on the top line (along with the 'local' icon) but you see the 'remote' icon a couple of lines down then try pushing the changes.
  3. If I go into File Status - Working Copy (left nav), I can see that my old info is still there, near the bottom of the screen, below the “Staged Files” & “Unstaged Files” sections of the screen. So I close and re-open SourceTree. (Lots of stuff gets better in SourceTree when you close and re-open it.).

Working Directory – files in a current local directory that you are working on. Staging Area (aka. Cache, index) – is a temporary area where you add files with git add command. HEAD – is a reference to a specific commit (normally to the the last commit in a local repository). Git Diff Unstaged.

This post is the first in a series of articles covering GIT for Unity Developers. GIT is a great tool for any developer, but if you’re new to it, there are quite a few concepts to cover, and I’ve found most tutorials only cover a small part. This series will focus on what’s needed to make good use of GIT with as little complication and confusion as possible. While I know many developers love using the GIT CLI, I find it to be far from user friendly, and frankly a bit of a distraction for anyone who just wants to get work done. So we won’t cover that, but we will cover the features and concepts I find most teams using day to day. By the end of the series, you’ll be a Unity3D GIT pro!

Prerequisites

Sourcetree Unstaged Files Downloads

To follow along, you’ll need Unity and SourceTree installed. Any version of Unity should work fine, I’m doing this in 5.5.

Unity – You should know what this is if you’re reading this.

SourceTree – A free visual Git client for Mac and Windows

Project Setup

First, we’ll create a new project and name it “Git Branching”.

If you’re wondering why the project is named “Git Branching”, it’s because we’ll be using this same project from the start, all the way through to branching, merging, and more.

Browse to the folder where we’ll create a new file named “.gitignore”. (The filename is blank with only an extension of gitignore)

Edit the .gitignore file with your favorite text editor (I use Notepad++ for these things).

Paste in this gist.

View the code on Gist.

Git Setup

Open SourceTree.

Click on the Clone / New button.

Select the Create New Repository tab.

Enter the destination path that matches your folder structure. Mine is located in “c:gitGit Branching”

Click Create

First Commit

The git repository will be created and you should see this.

If you see a bunch of files in the Library folder, your .gitignore file isn’t correct. Go back and double check that you have it named right and in the correct location.

Click the “Unstaged Files” checkbox to move everything into the Staged files area.

At the bottom of the screen you’ll see the Commit message area.

Type in “Project Settings and .gitignore”, then click the commit button

.

Once the commit completes, switch from viewing the “Working Copy” to viewing the “master branch” by clicking on “master”.

Here, you’ll see our first commit, with the commit message we entered.

I often see people write short commits with no information about what changed. While it will save you a couple seconds at commit time by not having to think about what you’re committing, it will generally take a lot more time for you to try to figure out when someone commited some broken change. Commit messages also serve to inform the rest of your team about what you’re doing (or remind you when you try to remember where you left off)

Serialization

When you use GIT as a source control engine, it’s recommended to use the Text serialization mode in Unity. This is helpful when you need to merge later.

Open the Editor Settings page.

In the inspector, select “Force Text” for the serialization mode.

Sourcetree unstaged files gitignoreFiles

Now go back to SourceTree.

Switch back to the “Working Copy” view b y clicking on “Working Copy”.

Stage all the changed files by clicking the “Unstaged files” checkbox.

Enter a commit message that says “Changed asset serialization mode to force text”.

Click Commit.

The reason all of these .asset files are ‘changed’ and ready to be commited is that they were initially saved in a binary format. When we switched to ‘force text’ mode, they were re-saved as human readable text files.

If you look at the “master” branch again, you should see two commits now.

Okay, you’ve commited 2 things already, but haven’t done anything in the engine yet.

Let’s change that now.

Creating the TallBox

In Unity, create a cube

Sourcetree Unstaged Files Without Changes

Name it “TallBox”.

Set the scale to (1, 2, 1) .

Making the Prefab

Sourcetree Unstaged Files Remove

Create a folder for prefabs.

Drag the “TallBox” into the prefabs folder to make it into a prefab.

Save the Scene

Save your scene in a folder named “Scenes” and name it “TestScene”.

Commiting the Prefab

Idethia harvey. Switch back to SourceTree.

In your “Working Copy” you should see 6 changed files.

Select the 3 that are related to the TallBox prefab. You can batch select them and hit space or check them individually.

Your “Staged files” area should now contain the 3 TallBox related changes while your “Unstaged files” area still has the Scene changes.

Type in the commit message “Created TallBox prefab”, then click commit.

Why didn’t we do the other files?

The reason we only commited the prefab and not the scene is to keep our changes logically grouped. Since the scene change isn’t directly related to the prefab it’s good to let it have it’s own commit. For this example it may seem like overkill, but as your project grows, you’ll want to be able to occasionally undo a commit. The less that’s in each commit, the easier it is to deal with them. There are of course limits, but a general rule of thumb is to group all of the files for a single change or feature into a commit.

Commit the Scene

Select 3 the scene related files and commit them.

Your master branch should now contain 4 commits.

Checking Out

Before we move to more advanced things like branching, let’s cover what the checkout command does.

In the “master” branch, right click on the first commit “Project settings and .gitignore”, then select checkout.

Commits are in order from newest to oldest. The first commit would be at the bottom of the list.

You’ll be presented with a confirmation dialog that talks about your detached HEAD. Don’t worry about it, check the “Clean” box and hit OK.

Detached head means you are no longer on a branch, you have checked out a single commit in the history – ralphtheninja

Go back to Unity and you’ll see that everything is gone. That’s because we’ve checked out a commit from before the prefab was created or the scene was saved.

Not worry though, our changes are in GIT.

To get back to them, select the most recent commit “Created Test Scene”, right click, and Checkout.

Go ahead and try this with the different commits and check Unity, you’ll see that you can get back to any state.

Question

With GIT, you have fast, clean, bookmarked history. And that’s just the start.

Remember that how clean and how well bookmarked it is completely depends on you keeping your commits separated and well described.