How to start a first JavaFX program that uses git?

[Jaakko Seppälä]

I would like to learn git and Java programming by doing a simple JavaFX program using Scenebuilder. Whe would I get some learning material for that? And I was said that one should never commit non-workable code to git. How a programmer verifies that his or her code works well before the commit?

[Campbell Ritchie]

I shall move you to our git and FX fora.

Jaakko Seppälä wrote:. . . . Whe[re] would I get some learning material for that?

There are all sorts of resources for learning git. I have a book by Rick Umali. Similarly there are all sorts of places you can learn FX. It is probably better not to use SceneBuilder or similar until you are more experienced.

And I was said that one should never commit non-workable code to git.

I can understand that committing uncompilable code will cause no end of confusion, but: if you are using the repository yourself and not sharing it, and you include warnings about errors not corrected in the comments, why not start a branch until you have got it working? Then you can close or merge the branch and get lots of useful git experience
It might be better to create a branch with errors and tell your colleagues you have problems than to let the code sit without correcting the errors. You can consider abandoning the branch if something better appears.

How a programmer verifies that his or her code works well before the commit?

Didn't you know how to test code before starting on FX/Swing/etc?

[Stephan van Hulst]

Jaakko Seppälä wrote:Whe would I get some learning material for that?

There's nothing special you need to know for the combination of JavaFX and Git. Both are completely unrelated to each other, so if you want to learn them at the same time, you should read different learning materials for Git and JavaFX at the same time.

The only learning materials I can recommend personally are:

Git User Manual

Learn Git Branching

Sadly, I don't know of any good JavaFX tutorials. Maybe somebody else can help you with more guides.
 

And I was said that one should never commit non-workable code to git. How a programmer verifies that his or her code works well before the commit?

Hogwash. Commit early, commit often. It's better to have non-working code safely backed up in a remote repository than to run the risk of losing it.

However, there is a slight hint of truth to what you've heard: you should not have non-working code on the main development branch of your repository. If you want to commit code that doesn't work (yet), just create a new side-branch and commit your code to the side-branch.

If you don't know what that means, don't worry. First do the Learn Git Branching tutorial. And as long as you're working on the project by yourself and not in a team, you can also ignore the rule that you shouldn't commit non-working code to the main branch. Don't be afraid to experiment a little bit.

[Tim Holloway]

Stephan's advice is sound. Initially, you don't need a branch, since you are starting with a blank slate and there's nothing to screw up. Once you have something working, you'll find it convenient to create branches. You may also want to use tags to mark your production releases.

Git is complex and powerful, but most of what you need to know is just a few basic commands. The more esoteric ones are what let you do things like take changes made to the main branch out and move them to a work branch (for those of us who don't have the wisdom to make the branch first!)

[Lou Hamers]

For learning Git, I always tell people to use a quality standalone GUI tool like GitKraken (free version is fine). You still want to know how to do basic stuff on a command line, but I credit the GUI tools (GK specifically) with helping me to finally break away from SVN. I think the latest version of GK even has a way to show the CLI commands it's using. But the biggest advantage IMO of a Git GUI is that you can see the start and end state of every action you take.

On learning Java via JavaFX, I'd say that's a fine idea. But I do suggest that you start out with at least some basic Java tutorials or other learning materials without the complexities of JFX initially.

JFX (really any UI) brings with it two things for someone learning:

- Additional complexity (which is a bad)
- A much more interesting and appealing end-result of your work (which is a good for motivation)

It is a little less complex than a web application with a Java backend, so in that sense I guess it's less complicated if you're the type that needs visual feedback to stay motivated.

I know this is a strange looking URL (supposed to be a free University of Helsinki course) below but it seems like it'll get you on a good path. Starts with plain Java and it hits JavaFX later on (part 13), so after you're done you should have some experience with the fundamentals and enough to keep going with JavaFX after the end.

https://java-programming.mooc.fi