4 ms·
I absolutely love git now. I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in i
by mathieuh 10y ago
I absolutely love git now.
I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo.
I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to a branch which other developers are working on), it is almost impossible to break irrevocably. Even if you do accidentally break master/develop/whatever, it only causes a bit of hassle and grumbling.
Highly recommend that everyone take a bit of time to learn about "undoing" git commands, whether that's through soft resets, hard resets to origin, or the reflog.
Reflog is also useful for figuring out how someone else broke something and explaining what they did wrong, since you can see what branch they were on at what commit and what commands they ran.
I think git's main problem is the somewhat arcane language it uses, and lack of understanding of what's actually happening behind those words like "rebase", "commit", "patch", "reset" etc.
- Annatar 10y agoit is almost impossible to break irrevocably. This tells me you still don't get the point about using a revision control system: the whole point is NOT that you can hack the revision control system's database every which way, but that you can never, as in ever, break something in a repository, because you can always revert the previous commit and do a new commit of that revert. Keeping it simple since January 1st, 1970. It's called the "unceremonious revert", popularized by Jeff Bonwick, the father of ZFS and former Solaris gatekeeper, in the "Quality death spiral": Bonwick was granted authority to "rip it out if itʼs broken" — an early BDFL model, and a template for later generations of engineering leadership. https://web.archive.org/web/20091028095830/http://hub.opensolaris.org/bin/view/Community+Group+on/qual_death_spiral https://web.archive.org/web/20091028095830/http://hub.openso... https://wiki.smartos.org/display/DOC/Community+History https://wiki.smartos.org/display/DOC/Community+History SEE ALSO http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-fetid-and-grimy/ http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-f... ...and do youserlf a favor, try out Bitkeeper (it's open source!) before you get completely absorbed into git. You might never be able to get out of that tar pit afterwards, or it might be decades before you realize it. Who will compensate you for all that lost time, and how would you be compensated?
- lukeholder 10y agoI think you misunderstood @mathieuh's statement, which is why you are being downvoted. @mathieuh was only referring to not being able to break the something in the repo, He didn't mention hacking the git or the git data structure. Also, @mathieuh is a uni student, so comments like > This tells me you still don't get the point about using a revision control system Can come across a little unnice.
- apk17 10y agoAnd? You will have some kind of 'blessed' repo anyway. In git you disable non-fast-forward pushes there (aka prevent commits from ever being removed) there, and implemented your 'point'. See also 'svn obliterate'.
- swehner 10y agoI would not expect a university to teach git. Maybe the theory of version control systems, their history, or a comparison of different version control systems. But not how to use the tool.
- sergiosgc 10y agoI agree. Class time is much too valuable to be lost on such minutiae. However, I'd expect a good university to: a) Explain the value of version control and actively promote its usage b) Drop some hints on which good version control systems are out there, one of which is git, then let students pick, learn and run with their own choice It'd take all of half an hour, with great benefits for students.
- ufmace 10y agoI agree because of the large variety of version control tools. Git is great IMHO, but not every company uses it or can easily switch to it. Teach some theory or the basics of a few different systems and their pros and cons, but I don't think diving too deeply into only one is a good idea in a university environment.
- mathieuh 10y agoPerhaps not specifically git, but ANY version control would have been good. We were told to version control a group project, but all we were given was an SVN repo and told "if anything goes wrong, email this address". Personally I would expect tuition through the use of a tool, that tool doesn't have to be git, it just so happens to be the tool I've had the most exposure to.
- Jarwain 10y agoI had to take a class, Principles of Software Engineering, that was a sort of hands-on class. We went over different methodoligies like waterfall vs agile, scrum, the use of kanban boards, design documents, and the use of version control. The version control lession was basically an assignment saying "do the Udacity git course". Alongside this, we had a group project where we had to, well, develop something.
- adamkochanowicz 10y agoI agree that the syntax is nonintuitive.