Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 12 down vote favorite
4

I've recently started using GIT for personal projects, it's the first version control system I have used. After submitting a few commits on a project, then branching, then submitting a few commits on the 2nd branch, then pushing both branches to github, I decided to rename the folder my project was in, along with the name of my main javascript class. I've no idea what went wrong I'm not entirely sure what went wrong but I've ended up losing a README file that I committed (it was definitely on github as well as my local machine for a while) along with quite a few commits along the way. I haven't lost anything important, but my history does not reflect what actually happened, which is a bit irritating. All this seems to be because I decided to rename a couple of things and obviously didn't know how to deal with this in git.

So has anyone else had any disasters that a bit of experience could have avoided? Are there other hidden pitfalls I should beware of?

share|improve this question
6  
If you really managed to completely expunge any trace of that README file from the history of two separate repositories, I'm impressed (and a little disturbed). It's not particularly straightforward to do that, even when you want to. – David Zaslavsky Oct 13 '11 at 20:39
I've just been looking through my history and I found this This reverts commit f4bb6a9. It's probably safe to say this was what did it. I remember reverting a commit because the rename seemed to have cocked things up. I didn't realise this would remove the README I had created too. I realise this now though. – MrMisterMan Oct 13 '11 at 20:43
2  
You're lucky that you've never used source control before. Everybody else has to unlearn everything they knew, first. – kylben Oct 13 '11 at 23:47
3  
As @kylben says, not having to unlearn anything else is actually a mark in your favor. One popular "transitioning to git" tutorial on the web begins with, "Start by accepting that as a Subversion user you're already brain damaged." – Dan Ray Oct 14 '11 at 12:31

6 Answers

up vote 7 down vote accepted
  1. Take your time when you're first learning - try to read all of the output and understand what Git is telling you, not just blowing through commands without knowing what they are doing.
  2. Dry runs will save your life when you're first getting started; see this question on SO. Most commands have a --dry-run option as well.
  3. Know the difference between git rm and git rm --cached - one of these will definitely save your life!

Definitely more, but these are a good start.

share|improve this answer
up vote 3 down vote

I'll add my $0.02. First, I would have to agree that git is probably a pretty rough choice for a beginner to VCS, but it is very different from typical VCSs that most of us had to unlearn. I would agree that mercurial would be a little easier. I think the best analogy is Git vs. Mercurial: Please Relax. In the blog post Mr. Thompson describes Git as MacGuyver, and Mercurial as James Bond. At this point, Git is becoming more polished, and Mercurial is becoming more flexible, but they still have personalities. This is not to say you must change, or that one is better.. just that in using both I've found Mercurial a little cleaner in the user interface.

The next point is the big one.. and it's a little philosophical, but important: Never use reverts (unless you really, really know what you're doing). The purpose of a VCS is to store the history of changes you make, even mistakes. It is often a better philosophy to simply check-in the version you'd rather revert to, than to try and erase the last change. For one, as you've found, you may unintentionally remove valuable data permanently. If it is just another check-in then the history is still there even if something is 'removed'. Second, you may actually change your mind at some point, or figure out a way to implement a feature properly, and wish you could have the half-broken code back. Reverting is a loss of information, which is not what you want out of a VCS. Disk space is cheap, and both Git and Mercurial are very compact.. so keep mistakes. There are few reasons to revert.. one is if you accidentally check-in a large binary file you do not want/need. Other than that, trust in your VCS.

I also should point out that both Git and Mercurial have built in help. Use it, and use it often. They also both have excellent online documentation. Research any command you're not entirely comfortable. You will make mistakes, but thankfully they're pretty forgiving if you're not trying to delete check-ins. :)

share|improve this answer
The other main use of a VCS revert is when something is checked in that can't be allowed there, typically for legal or liability reasons. Possibly sample health care data that hasn't been sanitized or code with a license that precludes such inclusion. – David Thornley Oct 18 '11 at 21:50
up vote 2 down vote

NEVER force push to the depot EVER

share|improve this answer
This is not something you need to know of if you have a git server with properly configured permissions, e.g. a Gerrit server. – oberlies Jun 12 at 8:17
I would qualify that. Never force push to a shared branch. If you are working on a feature branch and have lots of small fixes that don't add to readability rebasing to combine (squish) commits can be very useful. Once squished you may need to force a push. – Loki Astari Jun 12 at 13:52
up vote 1 down vote

You should consider having some kind of backup regimen in addition to whatever version control system you use. I generally kick off a Time Machine backup in between major commits - that way even if I manage to screw up my version control or some other major catastrophe happens I can still retrieve any missing stuff from my incremental backups.

share|improve this answer
Personally, when I have a belt and braces, I eschew the piece of string. *8') – Mark Booth Oct 18 '11 at 10:23
@Mark: assuming I understand what you're saying, a version control system is no substitute for a backup system (and vice versa) - disks can still crash, version control metadata can get corrupted, cats can walk on keyboards, etc... – Paul R Oct 18 '11 at 10:27
The belt is your repository (local, remote and any clones), the braces are your normal backups, but to kick off a Time Machine backup in between major commits is the ugly piece of string which shouldn't be necessary. If you don't trust your VCS to take care of letting you revert to any point in the history (rather than trawling through incremental backups) then you really should be using a VCS that you do trust. *8') – Mark Booth Oct 18 '11 at 11:14
@Mark: OK - understood - just to clarify: the incremental Time Machine backups happen automatically (every hour), but because I commit often I tend to kick off an additional backup after a commit - it's not necessary but it makes me feel more secure. ;-) – Paul R Oct 18 '11 at 11:21
That would be nice, but losing no more than an hour's work in the event of a minor disaster is probably good enough for me... – Paul R Oct 18 '11 at 11:56
show 1 more comment
up vote 0 down vote

For my own learning, I couldn't really think practically about git until I understood what my personal work flow needed to be...

  1. checkout local shared branch
  2. fetch changes from remote shared branch
  3. commit changes to local shared branch
  4. rebase local shared branch to local work branch
  5. checkout local work branch
  6. make changes
  7. commit changes to local work branch
  8. check out local shared branch
  9. merge/cherry-pick local work commits
  10. push changes to remote shared branch
share|improve this answer
up vote -5 down vote

Preface

It's worst choice to have git as first VCS in common and as DVCS namely. Be ready to go long and hard (and only partially usable for future experience) way of walking through a minefield and getting your personal rake cones

Face

  • Git is not easy to learn
  • Git is not transparent and obvious
  • Manual is a must, not a option. You must RTFM, guess&try doesn't work (you'll get troubles rather fast)
  • Git ignores KISS principle (Git terminology: remote, add, track, stage, etc.)
  • Git is overflooded by git-specific low-level jargon, which is git-specific and never used in other VCS and DVCS (URL above again and partially from git-svn, and thoughts on Subversion, search term "jargon", some quotes

I stayed away from git for a long time because of its refusal to use conventional revision control terminology... Sorry, you use checkout to revert a commit? And checkout also switches between branches? revert is like a merge? WTF? )

  • "80/20 percents" rule work in it in inverted form (not 20% do 80%, but, long time, 80% of tools do only 20% of tasks)
  • You must forget about adequate GUI for Git
  • You'll lose your data, because it's easy to achieve. Quote from James McKay entry about Git

More traditional version control systems don’t give you as much power as Git by any stretch of the mind.

They are like taking a walk in the woods with your parents, at age 14.

You’re probably gonna see and do neat stuff, but you sure ain’t gonna get lost or anything.

Using Git on the other hand is more akin to being handed a cool motocross to go play alone in the woods… Also at age 14.

We all know what’s bound to happen, right? You’ll smash into a tree.

The source control equivalent to slamming into a tree is losing commits…

share|improve this answer
2  
You make valid points, the packaging is rather "ranty", so no upvote. – sebastiangeiger Oct 14 '11 at 7:06
3  
-1 this answer is completely off topic – barjak Oct 14 '11 at 8:26
4  
@LazyBadger I fail to see how you draw the conclusion that @barjak is a 'git-fanatic' from the comment this answer is completely off topic. – MrMisterMan Oct 14 '11 at 8:59
2  
@LazyBadger This is funny. Actually, I am a mercurial user, and I've never used git in my life. – barjak Oct 14 '11 at 9:37
2  
@LazyBadger To be clear, I do not contest the content of your answer (I am not familiar enough with git to evaluate your opinion), but it really feels inappropriate for this particular question. – barjak Oct 14 '11 at 9:41
show 13 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.