Thanking to Fabiola De la Cueva and Emilien Kia for reviewing this presentation
Olivier Jourdan <olivier.jourdan@wovalab.com>
Why this journey ?
My Travelog
Today
Advice
Why I started on this trip
VCS records changes to a set of files over time
VCS allows reverting any file back to a previous state
VCS can tell when and who made changes to a file
VCS gives a way to collaborate with other developers
You must use it, even if you are working alone! |
—
This is not a backup system |
*.vi
and *.ctl
are binary files
Binary files can’t be merged, if a conflict happens, you need to choose between files. |
—
*.lvproj
, *.lvlib
, *.lvclass
are XML files
Auto-merging XML files can be dangerous |
Objective motivation
features that not exist in SVN
Cloud service integration (GitLab, GitHub…)
CI/CD tools
Subjective motivation
Curiosity
Trend of adoption in LabVIEW community
spring 2020 - 83 participants |
spring 2020 - 83 participants |
Read on the internet back in 2018…
Git is more complex than SVN
Git is not handling binary files correctly
Git needs to use command lines
Git forces you to merge
My travelog
SVN | Git |
---|---|
Checkout | Clone |
Update | Pull |
Commit | Commit |
SVN and Git have a different architecture
The impacts can be substantial
SVN | Git |
---|---|
Commit | Stage → Commit (local) → Push (remote) |
Amend
Stash
Rebase / Squash / Cherry pick / Bissect
Git branching model makes it stand apart from SVN
Creating, merging, switching and deleting are simple and fast actions
That means you can:
Switch context easily
Define roles for branches
Create branches for experimentation and forget them
Git is an open system that can adapt to an infinite way to work
Define the team workflow is really important
Spring 2020 - 83 participants |
Kind of process above Git
Allow you to delegate the merging responsibility to someone else
Command line | Free | |
Tortoise Git | Free | |
SourceTree | Free | |
Tower | annual fee |
|
Fork | One-time purchase |
|
GitKraken | Free/annual fee | Not tested yet |
Today…
Moving to Git requires learning effort
Going out of your comfort zone makes you learn intersting things
Everything I was doing with SVN can be done with Git
We use Git for all project at Wovalab
Locking files is not possible with Git (at least, not easily…) |
We use Git Flow as our main branching workflow
Git is agile enought to fit the development context
Your Git workflow is going to improve/reinforce your development process
Working on open source project
As project owner (Antidoc - Asciidoc toolkit for LabVIEW)
As contributor
Successful and efficient CI/CD implementation via GitLab
My advice for this journey
Commit (local) vs. Push (synchronization with a remote repository)
Modifying commits history already pushed can lead to headaches
Make your git workflow best fit your development process and vice versa
Some ideas
Want to mimic SVN trunk → Centralized
You are building software that is explicitly versioned with Semantic Versioning → Git Flow
You are collaborating to open source project or have a strong code review process → Fork / Merge Request
Be kind to your future you.
Often
Clear message (explain "what and why" instead of "how" )
Cohesive (only one reason i.e., adding feature or refactoring not both)
Mindful (only file you voluntarily modified)
To avoid getting more file changed than you have really modified use separate compiled code from files option |
Without config files
Without build artifact
Use .gitignore file to skip folders or files in your working copy from being versionned |
—
Use a release server to keep your artifacts |
You can lose data |
Whatever Version Control System you use, a modular architecture is essential to work as a team on the same project.
No Version Control System can replace communication within a development team.
Thank you