Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

Development Tools

Jonathan Grieve
MOD
Jonathan Grieve
Treehouse Moderator 91,252 Points

Git: Working with Commits

Quick question on using Git commits.

One of my favourite things about Git in my limited experience with it, is that I can go to various versions of a file, so long as I have a commit for it.

I had this idea that I could save different code snippets in different versions of a file so long as I have a commit for it, or use commits to go to a completely different CSS colour scheme if I wanted. I can see how powerful Git is.

But when I go to a commit, my main question is what do I do next? Do I simply move the commit and it's previous commits to a new branch and work with some files there? How do I get back to the latest version of the files and if I have a merge problem or anything breaks can it be fixed by simply deleting branches and going back to the master branch?

Jennifer Nordell
seal-mask
.a{fill-rule:evenodd;}techdegree
Jennifer Nordell
Treehouse Teacher

I'm not an expert and I still haven't gotten my hands in it yet LOL. I'm such a chicken. But I'm given to understand there's a git revert command. Maybe something to look in to?

Note: I was on my way to say "checkout" before I stopped myself and saved you from the bad pun :smile:

2 Answers

Sue Dough
Sue Dough
35,800 Points

"How do I get back to the latest version of the files?"

This will do a hard reset to the latest commit. It will throw away any uncommitted changes. Run git status to confirm after.

git reset --hard HEAD

You can create and delete branches any time. You can even delete branches permanently and still go back in time once its merged.

to create a new branch and check it out

git checkout -b myNewBranch

to view your branches

git branch

to delete a branch

git branch -d myNewBranch

If you have a merge conflict and your using for example GitHub to merge in the gui they will tell you how to fix it. The first ones the hardest but you will be alright.

And to go back to master

git checkout master
Jonathan Grieve
Jonathan Grieve
Treehouse Moderator 91,252 Points

So this is interesting. It looks like when I run

git reset --hard HEAD

It creates a new kind of temporary branch with a copy of the log up to the commit i was last on. It didn't occur to me at first that

PC2@PC2-PC  ~/Documents/GitHub/jgdm ((4e38aaa...))

4e38aaa was actually a branch name so all I needed to do, to get back to the last version of my work was back go back to the master branch.

git checkout master

So as long as I use reset command i won't do any damange to my current work. Have I got that right?

Karolin Rafalski
Karolin Rafalski
11,368 Points

Git commits are like 'snapshots' of your project. Branches are where you create different versions of your project.

Have you ever written a term paper and made files like termpaper1, termpaper2,termpaperfinalversion, termpaperfinalfinalversion. termpaperrealfinalfinalversion? These are more similar to branches in git. And then every time you had hit 'save' would be more like 'commit'.

The reason you made all the saves was that you made some progress that you didn't want to lose due to a power failure, your laptop being stolen, etc.- these are the times you want to use commit in git.

The reason you would have made those file versions of the your term paper was probably because there were some changes that you were making that you were nervous would mess something up, or you'd want to easily go back to a previous version.

Let's say you were working on some CSS, and you were torn between a light color palette and a dark color palette, you would start with some basic css that would go in both, so you would probably create a branch called main -for the main css and html. Then from there, you could create two other branches: light and dark. You could switch between these branches as much as you like and change all the associated files, without affecting the main branch.

At some point though, you would make a choice between the css and then you would merge your branch of choice into your main branch which would be your 'final' version.

Let's say you chose the light version. You merge that. But you don't have to do anything with the dark branch. You could delete it ,if you decide you'd never use it, or you could just leave it alone. All you have to do is git add and git commit your changes and then you can switch branches.

If you get a merge conflict, you just work out the conflict: it's not so scary. Take a deep breath first, and then it'll be fine.

Sometimes you do want to go back to an old commit, and then it would be wise to create a new branch if you want to work on stuff. You typically don't want to go and change commits, since that can be like rewriting history and that can lead to many problems.

I know this sounds like a lot, but it really just is a matter of when you do it, it will make sense. At this point it is rather abstract. But it gets better. I hope this info helps.

@Jennifer - I am excited to see your work! I hope to see you at Ugliest CSS soon!

I have put Ugliest CSS live on the web: http://krafalski.github.io/ugliestcss/