I used to hate git. It was something that “got in my way” programming. Of late I’ve been using it on a medium sized project that I’m working on as lone wolf. I’m thinking twice about git now. I have been diligently doing a daily or hourly check in, with progress notes for both working code, and code that is not working and I’m using git as a disk backup kind of thing.
I’m starting to really like this, even enjoy it, dare I say relying on it?
I’m sure that I’ve only scratched the surface of what this remarkable tool can do.
Any tips / tricks from folks that have much more experience with this tool than I?
I am using it as a single contributor to my current project much like you do. It plays it’s full strength in managing code for a dev team. Other folks here may know more about this.
Huge projects like the Linux kernel use Git.
I like source control in general for the backup and history aspects, even on projects where there’s no real need for branching and/or where I’m working on it alone. I just prefer TFS to Git, at least in the Visual Studio environment. I had to use Git on my side gig a couple of years ago and it was not Git that got (ha) in the way, it was the so-called agile process, mostly the fixation on pull requests – a mechanism that was designed for untrusted contributors on open source projects, not for a tightly gelled small team in a private company. It was just a delay mechanism in our case.
Now on the new gig they use Git and I am doing commits to a local repository. I asked them if they wanted me to push to a remote repository where they could see my code and they responded by creating a repo in Azure. But now it wants credentials and no one can tell me what they are, I just get pointed to articles that say, well try this and if that doesn’t work, try this other thing, and if that doesn’t work here’s a third thing. And I just said, feh, I’m too busy working for this. When they really need or care to see my code they’ll ask about it and I’ll set aside a couple of joyless hours figuring the damned thing out.
Or, when I need to fork something maybe. At this point it’s just another layer of cruft.
I zip up all the solutions every day or two and copy them via the RDP client to my laptop, just so there’s something off-premise / on a different machine. I imagine I could also push stuff to one of the NAS devices attached to my virtual PC, as those should fail independently of the PC itself.
I use Git for all of my work projects, even though it’s normally just me working on them. It’s handy to be able to look back and see when and why something was added.
Not a tip as such, but thought I’d mention that I use Nova as my code editor on Mac. It has a feature where when you position the cursor on a line of code, it shows the date and commit note inline for when that line was added. Can be really useful when trying to work out what a particular line does or what it relates to (providing you’ve made regular commits and used sensible notes!).
Now that I think of it, my source code and therefore my local repository already are on a NAS drive. It is just mapped as drive F: in windows and I don’t think of what’s behind the letter. So I could backup to the VPC itself, too.
branch
branch lots
it does a really great job of making it easy to have a perpetually working MAIN branch and then merging in features / new code as it reaches an acceptable level of completeness & quality
Assuming you have a coherent branching strategy, yes this can be a Good Thing.
Right now though everything for me is under early development, and once it’s in production, it will be releasing fixes … branching would for me be overkill unless I were working on substantial new functionality that was intertwined in ways that adding it could break existing functionality.
Then there is also the problem that when you have a DB-driven product, changes or additions tend to mean altering the DB schema so the new code won’t work on the old schema and vice versa, so … all I can say is we had no significant mishaps operating on a live patient in realtime, so I’m thinking confusion around branching may have just been a wash. Other’s mileage may vary.
I think on this system I will have a dev / test DB at least, so that I can branch new features against that, then merge after testing. One reason being, at the old place we had 2 devs working on features and one client (us) whereas now there will very likely be 3 devs and before long, several clients (via the API) so now a more cumbersome workflow starts to make sense, as there’s more moving parts.
I used to use Coda and Coda 2 for years, then they discontinued that and moved to Nova.
For me one of the most useful features is its inbuilt publishing. So when I’m working on web projects, it will track changes and allow me to push only what’s changed out to various servers (be that staging or production servers etc.).
The Git integration is nice, with side-by-side comparisons to the latest or a specific commit. And as I say, the in-editor commit messages are handy too.
Also it allows extensions, so you can extend the functionality with code validators etc.
It’s not free, but considering I live in it for hours everyday, I think it’s worth the yearly upgrade fee.
I often use GitFlow (Gitflow Workflow | Atlassian Git Tutorial), mainly because it is integrated with SourceTree, which I used to use a lot. You can add a nice toolbar button to SourceTree that made starting or finishing a feature, release or hotfix branch really quick and easy. It’s not for everyone and trying to explain to an offshore contractor that was taking over one of my clients how to correctly use it proved impossible!
Yes we used that at the side gig, or something slightly adapted from it anyway. I think it would have been okay if we didn’t have to stop the world for pull requests going from dev to test and then from test to production especially, as that required a senior dev sign off and they were always way behind. I had features miss production that people were screaming for because my pull request sat unanswered for 2 or 3 days and I just had to shrug and say, well, too bad so sad!
That’s always an issue, you can only deliver as fast as the senior dev can sign off on stuff. I’ve mainly only used it for myself, so haven’t run into that problem.
For me it’s handy for the web apps that I support as clients will always want a few big features added that will take weeks or months to complete, but in the mean time will be expecting small tweaks to be sorted quicker. So I can have the big feature branch sit off develop, but still have little hotfix branches from main for their tweaks. Then when the bigger features have been tested and accepted I can create a release branch to bring everything together and then merge that back to main as my current version.
Sounds complicated, but can be a real life saver if a new feature causes big structural changes to a project, but you’re still expected to publish smaller changes during that development time.
I recommend that you don’t make my mistake: I started with a GIT tool (still use it by the way (https://git-fork.com/). Costs a few pennies, but for me it’s one of the best clients.
BUT(!) I only got really fit when I watched a few youtube tutorials, some that explain git on the console. Only then did I understand many connections and also the more complex topics such as “merge / rebase” etc. Topics such as tags and how you can use them to trigger “actions” on Github, for example, etc. are also exciting.
The annoying but systematic approach is worth it here too learn. Looking back, I just used git completely wrong in the beginning.
I didn’t notice that and nothing bad happened either, but a lot of things were just fundamentally wrong.