Saving your code does more than make backups.

For this example, we’re going to modify an existing Android project, but all these steps also apply to a new project. We’re using our Git-backed, SourceTree monitored code from last time, but you can create a new default project in Android Studio (AS) and add it to SourceTree via File->New->New Repository->Add existing local repository.

Open up activity_main.xml and change “Hello World” to be grammatically correct by inserting a comma. Or make whatever change to the text you want. Now go to SourceTree:

Sorry it’s tiny.

There are 4 panes of content here, all designed to show us what has changed in our project. At the left is a vertical navigation bar. The top entry, File Status, has a “1” (or some other number) showing next to it. That means 1 file has unsaved changes. Click the History item.

The main top pane will change to show a graph view. If you’ve imported my project from Github, you’ll see something like the picture above, with Uncommitted changes highlighted. Below that line are 2 other entries regarding our project’s history, with blue lines and dots at the left, kinda like a subway map. This is a map of our code’s history. You can click any of those dots to view or restore the code as it was committed at that time. Since we’re using a cloned project, double-clicking an older entry will bring up some arcane message about branches, so don’t worry about that now. But feel free to single click entries and browse the file changes.

Bottom-leftish is our modified file, activity_main.xml, under an unchecked “Unstaged files” header. Any file we change will show up here. You may see random files here that you didn’t touch, like maybe in the “.idea” directory; these are changes that Android Studio made to project files for its own maintenance. Git just blindly catches all changes, regardless of who makes them.

Finally, bottom right shows our line-by-line changes. Red lines are gone, green lines are new. Go ahead and mess with any files you want, then flip back to SourceTree to see the changes.


Like many professional software tools, SourceTree has overwhelmed us with menus and windows and buttons. Let’s hone in on a couple critical features.

Saving (aka Committing)

From the leftmost navigation pane, choose File status; this’ll hide the history map pane. This is the most common view you’ll use. Under Unstaged files click the checkbox next to your altered “activity_main.xml” file. Notice that it’ll jump to the Staged files pane, like the picture below. In code, there is this weird purgatorial state for saving called “staging”, and for novices, it ends up being a headache way more often than it helps. Staging means, “I like these changes, and I want them separated from my work-in-progress changes, but not saved forever just yet.” So now we need to commit our changes, which super-duper saves everything in staging. See the bottom pane below:

In the white text input field, I’ve typed, “Add comma to ‘Hello World’”. This is the label that for our save state that’ll be associated with all the “Staged files” changes. You can type whatever you want, but for the good of Future You, resist the urge to type “Changed stuff”. Now hit the Commit button. Then, at the top-left panel, choose History again:

Hey, that’s our new commit in the history! Do another one!

Restoring

In Android Studio, make another minor change to activity_main.xml, like maybe change the text to “Hello Earth” or something. Now go back to SourceTree. On the left panel, select File status, and under Unstaged files, right-click activity_main.xml and select Reset, then hit OK on the confirmation popup.

Ha, gotcha! All your hard work of adding new text has been undone. You’ve reset the file to the last commit. Which is incredibly helpful when you decide to start messing with code, break things beyond recognition, and want to go back to the start. For real now, make some changes to files in AS and switch to “File status” view in SourceTree. Stage those files like before by checking boxes next to filenames under “Unstaged” in SourceTree, typing a commit message at the bottom, and clicking “Commit”. Then select the History view of SourceTree, and check out the little history map at the top. Here’s what I did for my next change:

I just changed the background color of “Hello World”’s container view to green, aka #0f0. The next two paragraphs are a bit technical; read them but don’t sweat the comprehension.

Couple things: In the left panel, under BRANCHES, notice that master is bold. When working in Git, your work happens on a “branch”, which is a way of siloing work. Branches are especially helpful when working with multiple coders or when you need to simultaneously maintain different versions of an app, so for newbies, the default master branch is all you need. However, if you double-click a commit earlier in the history, it’ll get “checked-out”, and you’ll see that your branch is now HEAD, which kinda means you’re not on a branch, so your work can’t be (easily) saved until you go back to the latest commit, ie sync up with your master branch. So rather than checking out (double-clicking) those old commits, you can just single click them and browse the file differences for that commit in SourceTree.

What’s even more confusing is that you have a local master branch, but there’s also the remote master branch on Github, where this code was downloaded from. In that picture above, in the history map, you’ll see blue tags labeled “origin/master” and “origin/head”, where “origin” is the original source of this code. This shows us where the internet version of the code ends and ours begins.

If you do end up with random settings files, like ones that start with “.idea/”, in unstaged changes, go ahead and stage and commit them. You’re likely working from a single computer, so having Android Studio settings in your codebase is no biggie.


A common use-case for this style of work goes like this: You have an idea for an app where you take a photo of a banana and the app tells you if it’s ripe. The first technical hurdle here is accessing the device camera and getting it to take a photo that can show on screen. For you, that challenge isn’t a fun part of making the app, so you look around StackOverflow and Google and GitHub and find that someone has already written a simple app that takes pictures. And it’s open-source, so you can do whatever you want with the code! So you check out the code and start hacking away to make a pretty interface. You get to a stopping point, so you stage the files and commit them. Next day, you do some more coding, but end up breaking something. The app crashes every startup, so you just hit rewind by resetting the unstaged files. Or maybe you have many commits and can’t figure out where the crash started, so you checkout previous commits and run the app until it stops crashing. Now you can pinpoint when the breaking change occurred. If other disciplines were this fault-tolerant, I’d have taken up carpentry instead of coding.

Next time, we’ll look at starting from scratch and pushing our already backed-up code to GitHub, where it’ll be super backed-up and potentially available for collaboration.

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade