Suggestions for a git noob

[Phillip Brooks]

My development environment is fractured.

All my LabVIEW code is in SVN.

I need to use git to manage the Python modules that are called from LabVIEW. My group had a pretty simple process and I squeaked by.

Now the modules are in a repository where all sorts of black/flake8 and pull request activity are making me crazy.

I'm spending way too much time googling "how to" with git and end up breaking or losing my Python changes. Everyone tells me "Its easy if I use PyCharm" but now I just end up googling "how to git in PyCharm" instead (with worse results).

My git expertise is almost zero and I use git from the command line under Windows.

[LogMAN]

Considering that git has been the de-facto standard for source control for years, there is simply no way avoiding it anymore.

1 hour ago, Phillip Brooks said:

Now the modules are in a repository where all sorts of black/flake8 and pull request activity are making me crazy.

I'm spending way too much time googling "how to" with git and end up breaking or losing my Python changes. Everyone tells me "Its easy if I use PyCharm" but now I just end up googling "how to git in PyCharm" instead (with worse results).

My git expertise is almost zero and I use git from the command line under Windows.

I presume you are not the one who setup this nightmare.

As someone who has worked with repositories on both ends of the spectrum, my general advise is to avoid nested repositories, pre-commit hooks and overly complex pull-request strategies unless all members of the team are intimate familiar with the workflow and understand the implications (which is pretty much never the case).

 

If you have some control over the process, I suggest rethinking the strategy. Here are a few pointers:

• Use simple repositories (no commit hooks, no special features, no enforced rules, just a repo)
  • It all starts with "git init" -- no more, no less.
• Create a single-page document with all the necessary git commands (5-10 at most). It should include the initial setup of user name and email, cloning, committing, pushing, pulling, branching, and merging. => search "git cheat sheet" for some examples (ignore all the stuff you don't need)
  • If you are eager to keep the history clear of merge commits, then rebasing should be included. But it might require some assistance when there are merge conflicts (if it's too complex, just don't use it)
  • If you have a team member who is experienced with git, they should be available to help users with topics like rewriting history, stashing, fixing, etc. (it's not needed 99.9% of times that people think they need it) -- they should also have a positive attitude, access to the coffee machine, and preferably some sweets to keep morale up 😉
• Avoid squashing and all the shenanigans. Instead, emphasize (but do not enforce) good commit habits (write useful commit messages, etc.).
• Document your guidelines and tooling. Do not enforce them with commit hooks!
  • Keep it as short and concise as possible
  • Avoid documenting industry standards (makes the document annoying to read and unnecessarily long)
  • Tools like black and flake8 should be called manually when the developer finds it necessary and convenient.
  • More advanced git users can make their own private commit hooks to automate the process if they are eager to suffer.
• Don't be afraid to commit
• Don't be afraid to commit "ugly" code (it can always be cleaned up with another commit)
• Most importantly: think of your team as colleagues that work towards a common goal and not as inmates that must be forced to do thy bidding.

In case that you are familiar with TortoiseSVN, then TortoiseGit may be interesting to you. Though, the command line is where git shines.

Edited September 6 by LogMAN

[Phillip Brooks]

My colleagues drank the cool-aid and did most of the things you reccommend against.

There is one other person who also supports LabVIEW but mostly stand-alone 'experimental' setups with NI DAQ hardware that doesn't integrate with Python.

Their one page instruction sheet is mostly about setup, not how to use the workflow other than "rebase, sqaush and create a PR". Also an encyclopedia of screenshots for configuring PyCharm settings 🤷‍♀️

I guess I just need to learn to drink cool-aid 🤢

Edited September 6 by Phillip Brooks

[LogMAN]

33 minutes ago, Phillip Brooks said:

My colleagues drank the cool-aid and did most of the things you reccommend against.

Well, it makes one feel so professional. Though, commit signing is probably not enforced, right?

33 minutes ago, Phillip Brooks said:

There is one other person who also supports LabVIEW but mostly stand-alone 'experimental' setups with NI DAQ hardware that doesn't integrate with Python.

Perhaps you can get together with this person and discuss a setup that works for all parties?

Even if the person does not integrate with Python, it may only be a matter of time. It also gives the argument more weight, especially if it hinders your progress and reduces productivity.

One suggestion would be to enable commit hooks only for the main branch. That way the team responsible for merging PRs may take the honor of running said tools and maintain code quality throughout the repository.

39 minutes ago, Phillip Brooks said:

"rebase, sqaush and create a PR"

If you are using any of the typical systems to host and manage your repositories (e.g., GitHub, GitLab, etc.) they can squash and rebase on merge with the click of a button, which is typically less error prone than doing it locally through the command line. Of course, merge conflicts still need to be resolved locally.

43 minutes ago, Phillip Brooks said:

I guess I just need to learn to drink cool-aid 🤢

Or scare them 😇