Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

More Incomplete Thoughts on Git

DZone's Guide to

More Incomplete Thoughts on Git

· Java Zone
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

I’m working through Chapter 6 and things are starting to go off the rails for me. Here are my current thoughts…

  • The git diff --stat <branch|tag> command is nifty. Even more nifty: referring to tags and branches by name rather than full path (svn).
  • I’m gratified to see that EGit displays annotations (blame) similarly to Subclipse.
  • Countless times I’ve committed code to a Subversion repository only to find I’ve broken the build by leaving out a file or lib. The Subversion-way is to either make a follow-up commit with whatever was missing or to reverse-merge the commit and re-commit with everything. The former is undesirable because it spreads the single change across more than one commit; the latter is preferred but is more complicated. Git’s amended commit gives you the convenience of the former with the pedantic correctness of the latter.
  • Yeah… git revert != svn revert … this is going bite me constantly. It already has.
  • I’m totally confused by git reset. I have no idea what this means: “git reset updates the repository and stages the changes for you to commit.” Maybe if I knew what was being “updated” or what was being “staged,” it would make sense! Also, the book says “[git reset] is useful when you notice an error in your previous commit and want to fix it.” What…? I thought that’s what amend was for…? Apparently, if I’m going to understand reset, I’ll have to find another reference.
  • My single experiment with git rebase -i wherein I attempted to squash two commits together and then break them back out did not work as expected. The book said the second execution of rebase would show my squashed commit starting with “edit” but it still says “pick”; not sure what I did wrong.
  • Using hashes as revision numbers makes it impossible to glance at a list of commits and determine what’s newer, older, or (dis)ordered. I ran into this when playing with git rebase -i. Unquestionably, rebase has a set order but it’s not self-obvious.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

Topics:

Published at DZone with permission of Mike Christianson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}