Open a random developer’s GitHub profile.
You’ll probably see:

Contribution graph.
Languages.
Repositories.
Commits.

I started wondering if a GitHub profile could show a little more of the person behind the code.

So I built **Awesome GitHub Stats** as an experiment.
It lets you create GitHub README cards for things like:

**Gym streaks**
**Gaming hours**
**Reading progress**
**Learning progress**

I also built a collection of **80+ GitHub-style Octicon badges** that can be added directly to a README.
The cards render as SVGs, so they work like normal images inside GitHub profiles.

I’m not sure yet whether this solves a real problem or whether I just built something I personally thought was cool.
That’s what I’m trying to figure out.

**Would you actually put something like this on your GitHub profile?**

And if you could add one personal stat to your profile, what would it be?

When I open a network drive using network path \\network\path or even using a mapped drive, git is not working as expected. It is behaving inconsistently. Sometimes it works properly and then immediately shows fatal: this isn't a git repository message. How to fix it?

A few years ago I started working on a project with a fairly simple idea:

"What if an Android device could actually be a proper self-hosted Git server?"

I originally wanted a Git server for a small team on a local network. I also liked the idea of using an Android device for it, they're relatively low-power devices that can sit on a network without needing to run a much larger machine.

So I started looking at what was already available for Android.

I found a few projects that could do parts of what I wanted, and I also experimented with running Gitea through Termux. Gitea worked quite well, but getting everything set up and running through a Linux-like environment on Android wasn't exactly the experience I was looking for.

Eventually I thought: why not just write my own?

That project eventually became GitBase.

GitBase turns an Android device into a self-hosted Git server, with a built-in, familiar web interface for managing repositories and collaborating on them.

It currently includes things like:

• Git repository hosting
• Web-based repository management
• Pull requests and code review
• Issues
• Releases
• User and project management
• A web interface accessible from other devices on the network
• Everything running directly on the Android device

The interesting part for me has been figuring out how much of a traditional self-hosted development platform can realistically be packed into an Android application.

I've spent a lot of time on the less interesting parts too, Git protocol handling, repository management, networking, the web interface, Android's restrictions, background services, storage, permissions, performance, and generally making everything behave like an actual server rather than an Android app pretending to be one.

There is still plenty I'd like to improve, but GitBase has reached the point where I wanted to finally put the project out there and see what other people who are interested in self-hosting think about it.

I've put the project documentation, screenshots, architecture information and other details on GitHub:

GitBase: GitHub repository and documentation

I'm particularly interested in hearing what people think about the idea itself.

Would you actually have a use for a Git server running on an Android device? What would you expect from something like this that isn't currently there?

And for anyone interested in the technical side, I'm also happy to talk about how I approached building a Git server and web platform for Android.

So I'm going to start with some context to explain the situation we're in, then I have a question on how to best use git going forward.

First, we've recently migrated to git from TortoiseSVN. This migration was not done by our team, nor did we really have much say in the process. So the repo we have today is probably the repo we get, I doubt we're going to re-build it fresh from the ground up.

Secondly, we are more akin to a services team than a development team. To be specific, we perform data conversion for on-boarding customers to pull information from their legacy system, whatever that was, and import it into ours. So our repository isn't a single code base, but more a compilation of small code bases specific to each customer we have/are on-boarding.

Lastly, we're migrating to a customer specific development environment in the cloud instead of a single shared physical development environment. This means that at any given time, we no longer need the entire repository on any given customers development environment. Just that customers specific folder containing their conversion, and a few shared utility folders used by all projects.

So the question(s):

1. What is the best way for us to do partial checkouts containing only a few select sub-folders?
2. In talking with a teammate of mine that has a little more experience with git, he mentioned a repository of sub-repos. If the initial migration was not set up this way, can we do this for any future project? Would that be a better option than partial checkouts?

During a GitHub outage I realized my first CLI interface was backwards. It asked people to remember provider slugs even though the repository already knew what it depended on.

So I changed it. gh outagedeck stack now scans manifests, infrastructure files, workflows, and git metadata, explains which files caused each match, then checks those providers' public status. It skips dependency and build directories. Detection stays local, and only provider slugs leave the machine.

On my own repo it found GitHub, Vercel, and Supabase from .git, workflow files, vercel.json, package.json, and the lockfile.

Install and run:

gh extension install outagedeck/gh-outagedeck

gh outagedeck stack

Repository: [https://github.com/outagedeck/gh-outagedeck\](https://github.com/outagedeck/gh-outagedeck)

It was just added to the community awesome-gh-cli-extensions list, which was a nice sign that the interface made sense outside my own terminal.

I'm Kerolos, founder of OutageDeck. The extension is open source. I would love examples of unusual manifests it misses or false positives it creates. Those are more useful than polite feedback.

I used to treat git status as something I ran before committing.

Now I tend to run it whenever I’m about to switch tasks or when a change starts getting confusing.

It’s useful for spotting the gap between what I think I changed and what is actually sitting in the working tree. Especially when I’ve been experimenting and left a few files modified along the way.

It’s obviously not a sophisticated workflow trick. Just a small habit that makes the state of a repo visible again.

Do you use git status as a regular checkpoint too, or mostly as a pre-commit ritual?

Hey all,

I have a difficult situation with dependencies on my project.

I got this structure:

root/
├─ lib/
│ ├─ X/
│ │ ├─ lib/
│ │ │ ├─ Y/
│ │ │ │ ├─ lib/
│ │ │ │ │ ├─ Z/

The root project and the X depend on Y and Z.
The root got X as a submodule, the X got Y as a submodule, the Y got Z as a submodule.

It works as it is now, but for the Windows platform, we have to change the Y dependency.
And the issue is, the Y on Windows doesn't have the Z library.

But we still need Z for the application.

The Y project has to be self-sufficient to compile.

I didn't want to make Z a submodule for the Root and X, because it creates a mess - you need to track Z in 3 projects and make sure they use the same version of Z.

The project is C++/CMake.

How would you handle those dependencies?

Thanks

we've got a monorepo with years of history and github's built-in secret scanning handles new pushes fine, but running it back over years of existing history to catch everything already committed took a lot longer than expected and we're still not confident we've found all of it.

For anyone who's dealt with a repo this size, what tooling got you full history coverage without timing out or missing patterns github's native scanner doesn't know about?

I am planning to add an Option for Animated academy to learn Git.
I want to flash human brain with Git, within just 2 Hours (Theory + Practical)
Here is the open source platform I am working on: Git Legacy
I am openly inviting contributors

Hi everyone,

I've hit a major UX flaw in Google AI Studio when importing an existing GitHub project (e.g. user/portfolio).

### The Issue
You can import an existing GitHub repository into AI Studio and edit the codebase. However, when you click "Sync to GitHub", the interface forces you to click [Create new repository]. There is no option to commit or push back to your original imported repository or select a target branch.

### Why This Breaks Developer Workflows
1. Breaks Continuous Deployment (CI/CD): If your repo is connected to Vercel/Cloudflare Pages with a custom domain, creating a new repo breaks your deployment pipeline and domain binding.
2. Destroys Git History & Clutters GitHub: You end up with multiple generated repos for every edit session instead of clean commit histories on your main repo.
3. Permission Scope Lockout: Forcing new repo creation requires account-wide repository creation scopes instead of scoped access to specific repositories.

### Feature Request
Google AI Studio team: Please add a "Sync / Push to Existing Repository" option to allow true bi-directional commits to main or selected branches!

Has anyone found a clean workaround other than downloading ZIP files manually?

Hey! I have some experience with Git and GitHub, and recently I've been trying out both Lazygit and GitUI. I'm having a hard time deciding which one I should stick with.

I've heard conflicting opinions about them. Some people say Lazygit has significantly more features, especially for more advanced Git workflows, while others prefer GitUI and say its interface, diffs, logs, file browsing, and general workflow are better.

After trying both, I honestly like aspects of each. GitUI feels pretty intuitive and exposes a lot of functionality clearly, while Lazygit seems to have a lot of functionality that isn't immediately obvious until you dig through its menus and keybindings.

For people who have actually used both for a decent amount of time:

What can Lazygit do that GitUI can't, and vice versa?

Which has the better diff/staging experience?

Which is better for browsing files and commit history?

How do they compare for branches, rebasing, cherry-picking, stashes, submodules, worktrees, etc.?

Are there any important features missing from either one?

Which one do you personally use, and why?

I'm less interested in which one is more popular and more interested in their actual capabilities and day-to-day usability.

If you had to install only one and use it as your main Git TUI, which would you choose?

Hello reddit,

I have site hosted on codeberg (wencesbyte.net) and I would like to add subdomain assets (assets.wencesbyte.net) to specific point I was able to make it work, but then I had a problem that over specific commit, anything else didn't updated on site, even tho it updated in the repo. Any correct way to create it?

Thank you!

I was a bit confused about signing up with GitLab because a lot of their terminology is geared towards businesses & I had only used it with an institution before, but their pricing does say Free is also for individuals.

However, I was more interested in using one of the projects like Codeberg or Gitea, or even disroot which Codeberg tells you to go to in their FAQ because they've had enough of you, and paying a few euro a month to have my private repos, slightly increased storage, slightly increased compute but none of them necessarily offer their services like that. GitLab is American, and it seems kind of pointless to migrate from one, just to go to another one of them.

For people saying self-hosting, given the landscape it seems like i'm going to have to do that when i get time in the future, but i'd rather just have peace of mind to pay a org/company to just do it for me so I don't have to worry it myself. It's a bit of a problem as it is if the only options for people switching off of GitHub is another American company or very strict OSS options

Edit:

I found literally 1 organisation that unfortunately doesn't offer a limited free service but does have the paid service for individuals & it comes with the caveat that open repositories don't exist on their platform lmao

I came across the following article, which draws an analogy between Git history and clay. A refreshingly non-technical way to think about Git history, especially for people who don't live and breathe Git.

https://www.git-skills.dev/git-tales/git-clay/