So you can say, for example, “Markdown files, just let them go straight to main.” You can say “In this case, I want to I want to push to main, but I still want someone to review this at some point.” So it’s like still in there, it’s low-risk, so you want to progress, and later someone can check it. Well, that can be sometimes a little bit too strict, and ReviewPad lets you actually create some more nuanced rules around this. So your main is never broken, your main branch. So in a lot of my projects I like to have it such that PR goes up, and then we automatically run all the tests and everything, and only if all those tests pass… And they can be backend unit tests, they can be integration tests sometimes, they can be frontend tests, end-to-end tests… Whatever it is that gives you the confidence to release to production, you can gate the PR on that, so that it doesn’t go into main. And this is like smarter PRs and rules around PRs. This is like the best side of open source, right? People that loved it and wanted to use it picked it back up, and now it’s under like the GitX GitHub org even, it’s not some user’s account… And it’s an open source Git GUI for macOS that’s under active development once again… Mostly maintenance mode, but I’m happy in maintenance mode, because…Īnd this I think is very cool… It’s at. And so GitX was gone for a while it was just like abandoned, and I was super-sad, I started looking for a new one… And then it got revitalized in the last year or two by the community. That’s the main thing I do inside of a GUI. I like to do staging, and committing, especially like - what do you call it, chunk commits? Specific lines of a file, and like selecting all that… I like to do that in a GUI, and not from the command line, because it’s just clunky from the command line. had a fork of GitX, that they maintained for a while after the original GitX author didn’t want to do it anymore, and then that went unmaintained… And I went searching, actually, for a GUI, specifically for a few things. So there was this Rohan – I think it was Rohan J. Now, GitX has been a long, long time project that’s gone through multiple forks and abandonments and community pickups, as macOS has changed dramatically over the years. Other than that, it just looks cool, and so it’s probably fun to build… And that also helps you familiarize yourself pretty quickly.
GITX HOMEBREW CODE
I know I’ve also done like CLOC, count the lines of code… And that will spit out kind of a report on a project of how many lines of code there are in each kind of programming language, like how much HTML there is, how much CSS, how much is Python. I think I would only use it in that context, if I’m like new to a team, and I have a repo that maybe has years in history, and I want to quickly familiarize myself with it… Running the tests is a good first start, and then maybe just throwing this thing in there… Depending on how long it takes to operate, you can get a tree map real quick. And so the color, I think, is based on how hot it is, meaning how often it changes, and you can limit that to certain authors, like I said… And then the size of it in the actual tree map is how big the file is, or the folder structure is. So it basically scans through the entire Git history using git log, and then takes that history and compiles a few database tables, which tracks files, commits, the author, and then the relationships between those things.Īnd then the second step is taking that database, querying it to create the tree map, and the query is based on both the size of the file, and then the total number of changes to the file. So I did look up the way that this thing works, and so it’s a two-step process.
I can also see it when you’re coming to a new project that’s existed for a long time, and you’re just trying to familiarize yourself with the project, who’s working on what, and which files are they working on the most.
0 kommentar(er)
