• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Git Gotchas

 
Ranch Hand
Posts: 343
Mac OS X Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What are some of the Git gotchas that you will like to share?

For me understanding the full power of git log has been one of the moments of enlightenment.
 
Author
Posts: 36
7
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh dear! Where do I start?

There is a lot of beauty in the design of Git, and you gain more and more enlightenment the more you peel away the layers. Starting from the inside out:

- Git does not store files—it stores contents in blobs.
- Git records the entire tree in every commit. In other words, Git commits are snapshots, not diff (See https://github.blog/2020-12-17-commits-are-snapshots-not-diffs/)
- How Git grows the core datastructure—Git's directed acyclic graph (DAG) of commits
- And finally, how everything you do in Git is simply working with this datastructure (This, to your point Palak, is the basis of the Git log, and so much more)

Once you understand the DAG, you understand that branches are simply named references to commit that move, while tags are named references to commits that don't move. You understand what happens when you merge, and what is the difference between a merge commit and a fast-forward merge. You know exactly what happens when you rebase, and how to create a workflow that works for you and your team.

I realize that I got a little carried away, but I will say this—understanding how Git was designed will make you a better software developer. You will see how a well designed datastructure means you can build all kinds of interesting new functionality afterwards, that you never foresaw when you initially designed the system. You can start to reckon with the power that comes from an immutable datastructure, which in turn, can show you the power of programming languages like Clojure, Elixir (or Erlang) and Haskell.

(OK, I might have a problem )

Regards,
 
Saloon Keeper
Posts: 25653
183
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd say that the #1 virtue of git is that if you start meddling with a project and suddenly realize you need a branch, git makes it relatively easy to scoop up the changes that you've already made as part of the new branch. Related is the "git stash" feature. Coming in close behind is the fact that you can do local work and not pollute the master repository.

The downside of git is that it is immensely sophisticated to the point where I still don't know what some of the features do and may never need to. But the upside to that is I don't have to.
 
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic