DEV Community

6 Git Aha Moments

Henrik Warne on June 25, 2018

When I switched jobs four years ago, I went from using subversion (svn) to using git as the version control system. Even though I am a pretty quick...
Collapse
 
pratikaambani profile image
Pratik Ambani

Adding one from my side,

Ability to modify previous commits.

Yeah

Collapse
 
khmarbaise profile image
Karl Heinz Marbaise

Hi Henrik,

a hint to your point #5 ... In svn you can do a merge in your working copy without committing back to the server.

If you think you done something wrong you can simply do a

svn revert -R .  

and start from beginning. Afterwards you can do the final commit

svn commit -m"Done merge."

But I would always recommend to run your build including tests before I finally commit.

Collapse
 
henrikwarne profile image
Henrik Warne

Thanks for the tip! I'm only using git these days, but you never know...

Collapse
 
jessekphillips profile image
Jesse Phillips

It is interesting that you use the phrase, "makes the Commits available." In svn the merge has you apply all the branch changes in one commit then it Commits meta data so tools can show history. Git has the meta data native to its structure.

I keep finding out how important it is to emphasize that git Commits are safe. Merge and rebase have --abort. If you don't use hard or force git won't touch your files, but then they use gui that warns in a dialog everyone ignores.

Collapse
 
cseeman profile image
christine • Edited

4 was a huge one for me too, I also came from a SVN to GIT background. Rebase still is like magic somedays :)

Collapse
 
rfbarraza profile image
RenΓ© Barraza

These were the exact same aha moments I had when learning git (in a heavily cherry-pick biased team). Nice post for folks learning the ropes. :)

Collapse
 
sujithnath profile image
Sujith

β€œgit reset –hard HEAD~” always saviour for me!!! Also instead of you could have mentioned about git rebase.

Collapse
 
moopet profile image
Ben Sinclair

Your talk of periodically merging master into b makes be think you should just rebase b onto master instead.

Collapse
 
henrikwarne profile image
Henrik Warne

For small changes, rebase is fine, but for bigger changes I prefer merging.

Collapse
 
whitetire67 profile image
Paul Dailey

I never merge ... you squash all the commits into one. I only ever rebase. Only. Ever. Rebase. Good luck! Paul

Collapse
 
henrikwarne profile image
Henrik Warne

For small changes and short-lived branches (which are most common), I prefer rebasing. For long-running branches with really big changes (changing how a major feature works, changing a framework), I prefer merging.
Regardless, understanding that you can merge in both directions, and why that works, improves your knowledge of git.

Collapse
 
kmonsoor_42 profile image
Khaled Monsoor

Now, try tj's git extra. You'll be blown away ... πŸ’―

Collapse
 
sktguha profile image
Saikat Guha

also git merge --abort is a good command to do , if you find that you are messing up the merge

Collapse
 
henrikwarne profile image
Henrik Warne

Agreed, good point!

Collapse
 
eljayadobe profile image
Eljay-Adobe

Any particular GUI front-end you use for Git, or do you prefer using Git from the command line?

(I include Xcode or Visual Studio or Eclipse or other Git-savvy IDEs as a front-end.)

Collapse
 
henrikwarne profile image
Henrik Warne

I mostly use git from the command line, but I also look at diffs and file histories from within PyCharm.