Looking for a good Git tutorial

Johnatan56

Honorary Master
Joined
Aug 23, 2013
Messages
24,532
#21
Keeps the tree clean. Only use it when guys are working on long running branches.

Team of right guys and that line is straight most of the time :p (although squash is not the reason for this, more like the last resort).
So basically on master? Or if someone made little mistakes and says "fixed the missing semi-colon", no need to record something like that.
Wouldn't really see the use in small, private projects.
 

cguy

Expert Member
Joined
Jan 2, 2013
Messages
4,617
#22
So basically on master? Or if someone made little mistakes and says "fixed the missing semi-colon", no need to record something like that.
Wouldn't really see the use in small, private projects.
Personally, I will put in a bunch of “WIP” (work in progress) commits when I am in the middle of something, but haven’t really crossed any milestone worth documenting.

Before this gets integrated to the master brach, I will squash them.
 

Hamster

Resident Rodent
Joined
Aug 22, 2006
Messages
30,909
#24
So basically on master? Or if someone made little mistakes and says "fixed the missing semi-colon", no need to record something like that.
Wouldn't really see the use in small, private projects.
What use is a bunch of commits saying “Fixed missing semicolon”, “Added null check to cart”, “Changing cart to use DB instead of stubs” etc

vs

Code:
TICKET-456: Cart v2 implementation

The new cart <blah blah blah>

Release:
 - run these db scripts
 - activate components like so
 - exec migration script
 

zippy

Executive Member
Joined
May 31, 2005
Messages
9,739
#26
Personally, I will put in a bunch of “WIP” (work in progress) commits when I am in the middle of something, but haven’t really crossed any milestone worth documenting.

Before this gets integrated to the master brach, I will squash them.
We have a policy to commit and push progress at the end of each day which results in at least 2 or 3 of these WIP commits. And coupled with an idiot who keeps switching work priority, I can end up with with more than a few commits. So a squash before merging is needed. Since we only merge after QA sign-off, the commits don’t add value. Also yet to come across any situation where I have needed to go back to them. If you need to revert master, you will revert the whole merged branch not bits of it. Never had to go there though :)
 

Solarion

Honorary Master
Joined
Nov 14, 2012
Messages
18,280
#27
Thanks for the advice and help guys. I did a small presentation today and they are going ahead with it. This is probably going to keep me flat out busy for a while.
 

kfc4unme

Well-Known Member
Joined
Dec 27, 2016
Messages
353
#30
My experience with GIT, and correct me if I'm wrong, is be very careful to properly configure your excludes and make sure you don't have any production or test settings files lying around to commit. Once you've uploaded to GitHub for example, there's no going back short of recreating the repo from scratch... That history remains.
Handy site to generate your .gitignore

https://www.gitignore.io/
 
Top