I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
I think visualizing the tree takes time to master. Once you're able to see the commit tree in your mind, it's easier to forecast what each command does.
Something else, a little more advanced, is to realize that everything is just a reference. A commit, branch, tag, even stash all simply point to some changeset in the .git folder. This also helps visualize the tree as well as understanding the various commands that accept a reference as an argument.
In the beginning, I recommend keeping is simple. Just use add and commit. Don't worry about the other commands until you need them. And never be afraid to ask your local Git Master or me on Twitter - we all started as beginners.
On this note, how much is mastering git different from other parts of software development? Like, is learning to visualize the tree different from visualizing the structure of an application or data flow?
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
As with anything, it's all about experience. You have to push yourself to fully understand the problem and try new solutions. Many developers just do what they know, and in this case, only scratch the surface of Git.
I'm definitely guilty of continuing to grow my skills in most areas of software development, but only doing the minimum in advancing my deeper understanding of git. Something I plan to fix π
I think visualizing the tree takes time to master. Once you're able to see the commit tree in your mind, it's easier to forecast what each command does.
Something else, a little more advanced, is to realize that everything is just a reference. A
commit
,branch
,tag
, evenstash
all simply point to some changeset in the.git
folder. This also helps visualize the tree as well as understanding the various commands that accept a reference as an argument.In the beginning, I recommend keeping is simple. Just use
add
andcommit
. Don't worry about the other commands until you need them. And never be afraid to ask your local Git Master or me on Twitter - we all started as beginners.That's a great point. Once I started picturing the git tree it really made a lot more sense.
On this note, how much is mastering git different from other parts of software development? Like, is learning to visualize the tree different from visualizing the structure of an application or data flow?
True, not much is different.
As with anything, it's all about experience. You have to push yourself to fully understand the problem and try new solutions. Many developers just do what they know, and in this case, only scratch the surface of Git.
I'm definitely guilty of continuing to grow my skills in most areas of software development, but only doing the minimum in advancing my deeper understanding of git. Something I plan to fix π
This comment mad me think of your recent post Ben.
The myth of "never going back to fix it later" π€£ so did you fix it?