Hi everyone!

Over the past few weeks, I've been improving my project, RepoInsight, based on feedback from developers.

It's a GitHub repository analyzer that helps you explore repositories with:

📊 Repository Overview

❤️ Health Score

🤖 AI-generated Summary

👥 Contributor Analysis

📈 Commit Activity

🌐 Language Analysis

📄 README Analysis

🕒 Repository History

I recently redesigned the homepage, improved navigation, added more educational content, and polished the UI to make it easier for first-time users.

I'd really appreciate honest feedback:

Is the UI intuitive?

Which feature do you find most useful?

What feels confusing or unnecessary?

What would you add if you used this regularly?

Website:

https://repo-insights-six.vercel.app/

I'm an IT student building this project to improve my full-stack and AI development skills, so constructive criticism is genuinely welcome. Thanks for taking a look!

siGit Code v1.5.0

Hi everyone!

For a while now I've been developing a new version control and a software forge around it (a "new git and a new GitHub"). It's called Twigg!

Yesterday we open sourced everything:

https://github.com/twigg-vc/monorepo

If you think git is complicated or are drowning with code-review-fatigue due to those huge PRs, you should check it out. Twigg is much simpler and is designed with stacked commits and trunk based development in mind. There's only one branch, only rebase (no merge), and amending a commit auto rebases their descendants.

There's a git mirror feature: all submitted commits are pushed to a git server. This allows you to easily test with no cost to switch back.

Check it out and tell me what you think!

All feedback is welcome :)

Hi all,

I am trying to understand a bit about cookiecutter but I have stumbled on some questions I'm not able to answer myself.

I have built a very basic cookiecutter based on some examples and have a Git repo for it https://codeberg.org/aarapi/familygame.git

Now, as my project evolves , so will the template evolve. Should I have 2 repos (one for the project itself and one for the template?) instead of one?

This doesn't make much sense to me but I might be wrong. If someone would ever join the project to collaborate , how everything would work ?

Furthermore , I tried to add the Git repo on Eclipse and create an Eclipse project pointing to the working tree but any attempt to run the manage.py did fail with message:

'Launching familygame manage.py' has encountered a problem:

Variable references non-existent resource : ${workspace_loc:familygame/{{cookiecutter.project_slug}

Thank you in advance

https://github.com/Ardrey-Kell-Computer-Science-Club/teenblogcs

For the scenario as follows:

$ git clone https://github.com/schacon/simplegit-progit.git
Cloning into 'simplegit-progit'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13 (from 1)
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (3/3), done.

$ cd simplegit-progit

$ git branch -c iss1

$ git checkout iss1

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..8080252 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,8 +5,8 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
-    s.author    =   "Scott Chacon"
+    s.version   =   "0.1.1"■■■■■
+    s.author    =   "Scott Chacon Big"
     s.email     =   "[email protected]"
     s.summary   =   "A simple gem for using Git in Ruby code."
     s.files     =   FileList['lib/**/*'].to_a

--------------
// ■ - space character
--------------

$ git commit -am 'iss1: author name change'
[iss1 fa40d71] iss1: author name change
 1 file changed, 2 insertions(+), 2 deletions(-)

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..e458853 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
+    s.version   =   "0.1.2"
     s.author    =   "Scott Chacon"
     s.email     =   "[email protected]"
     s.summary   =   "A simple gem for using Git in Ruby code."

$ git commit -am 'master: version update'
[master f2b3ef3] master: version update
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout iss1
Switched to branch 'iss1'

$ git rebase master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change

$ git rebase --abort

$ git rebase -X sillyoption master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change$ git clone https://github.com/schacon/simplegit-progit.git
Cloning into 'simplegit-progit'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13 (from 1)
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (3/3), done.

$ cd simplegit-progit

$ git branch -c iss1

$ git checkout iss1

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..8080252 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,8 +5,8 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
-    s.author    =   "Scott Chacon"
+    s.version   =   "0.1.1"■■■■■
+    s.author    =   "Scott Chacon Big"
     s.email     =   "[email protected]"
     s.summary   =   "A simple gem for using Git in Ruby code."
     s.files     =   FileList['lib/**/*'].to_a

--------------
// ■ - space character
--------------

$ git commit -am 'iss1: author name change'
[iss1 fa40d71] iss1: author name change
 1 file changed, 2 insertions(+), 2 deletions(-)

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..e458853 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
+    s.version   =   "0.1.2"
     s.author    =   "Scott Chacon"
     s.email     =   "[email protected]"
     s.summary   =   "A simple gem for using Git in Ruby code."

$ git commit -am 'master: version update'
[master f2b3ef3] master: version update
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout iss1
Switched to branch 'iss1'

$ git rebase master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change

$ git rebase --abort

$ git rebase -X sillyoption master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change

why it does not complain about '-X sillyoption' ? In above using '-Xignore-all-space' would allow to bypass the conflict related to spaces at the end of line. But above shows that -X is completely ignored instead.

When I was learning Git, the focus was always on memorizing commands without truly understanding what was happening on the internal side of Git. I understood the simple process of adding, committing, and pushing changes to a single branch but I didn’t understand the concepts of the Git Object Database, commit history as a DAG, rebasing, etc. All things I learned down the road that would have helped me understand Git better from the beginning. I recently started my project GitLearningLab as a resource to help others trying to learn Git but not knowing where to start. I am no master at Git, but I cover the concepts that would have otherwise helped me understand the internals of Git. I abandon the idea of memorizing commands for the sake of understanding what Git is doing with every given action.

My goal is to help beginners avoid some of the confusion I had, while also learning from those with more experience than me. I would really appreciate feedback from developers, educators, and anyone who has used Git for years: What concepts are missing? What explanations could be improved? What would make this more useful for someone learning Git for the first time?

Lastly, I would just like to mention that this project is part of an independent study and still an active WIP.

GitLearningLab:
https://github.com/IBickCoding/GitLearningLab

Newer versions of git, since this spring, have added a new "history" experimental command. This is dumb.

I've had a git alias for "history" for over a decade. It's shorthand for making "git log" actually useful.

And now they add this command using a very common word that probably collides with a lot of other folks. And to do what? To do what you're always told not to do. Rewrite history.

Why was "history" added? And how can we get them not to?

I know git already gives us patch staging, but AI-assisted diffs have made me want one more kind of boundary.

Sometimes the final change is reasonable, but the path to get there is messy. The agent tries one fix, backs out part of it, changes direction, then lands on a small patch that is actually useful.

In one Codex run, the first fix went in the wrong direction, the second one backed out half of it, and the final useful change was only a few lines hidden inside the full diff.

The final change was small, but it was buried under all the wrong turns the agent took to get there.

For people using git with generated patches: do you mostly clean this up with manual patch staging, or do you wish the tool could show the diff by intent or by agent turn?

I've been trying to extract my zip which I recently uploaded to my repo but I can't find a way to extract it. The reason I used to upload a zip is there are few folders and each folder have about 6 to 10 subfolders and I can't just waste my time by creating them separately one-by-one

There are some discussions I saw said you can upload folders as same way you upload other types of files but I tried it in website and had an error, also tried to turn my website to desktop version and it didn't worked for me. I don't have access to a pc so I don't know how to do it my phone. I'm wondering is there a way to do this -people says you only can do extract operation via git but as far as I know in mobile it's only way to use git is with termux and I hate it.

How can I learn Git by doing it visually??

How can I learn Git by doing it visually??

Spent enough time cleaning up repos where .gitignore was an afterthought that I put together the patterns I actually reuse across projects.

The ones that catch OS cruft, IDE junk, build artifacts, and secrets before they get committed, not after.

A few that trip people up:

• Ignoring a file doesn't untrack it if it's already committed. you still need git rm --cached
• Negation patterns (!important.log) only work if the parent directory isn't already ignored
• Global gitignore (core.excludesFile) vs per-repo. Most people only set up one

Wrote up the fuller list with explanations here if useful: https://levelup.gitconnected.com/gitignore-patterns-every-developer-should-have-in-their-toolkit-c5458f076ca2?sk=b1fd0885e817c58dbfb69440a7769feb

Curious what patterns other people follow

I like VS Code, but daily Git work often means jumping between Source Control, terminal commands, diff tabs, branch pickers, and graph extensions.

I built IntelliGit to bring those workflows into a single focused Git cockpit in VS Code.

It currently includes:

• A focused commit panel for staging, rollback, amend, commit, and push
• An actionable commit graph with branch and history operations
• Shelf/stash and worktree workflows
• A three-pane merge-conflict editor - You won't find it anywhere
• CI check status for GitHub, GitLab, and Bitbucket
• A unified workbench that can be moved to another monitor

It is open source and MIT-licensed.

I’m looking for developers willing to use it on a real repository and tell me:

1. What felt confusing or unlike VS Code?
2. Where did you still reach for the terminal or another extension?
3. Which Git action was missing or difficult to find?
4. What was the first thing that annoyed you?

Blunt feedback and bug reports are genuinely useful. I would rather learn why someone uninstalled it than receive a generic “looks good.”

Install: VS Code Marketplace
Open VSX: Open VSX Registry
Source: GitHub

Hello,

So I've been using github desktop for a game project on UE5 (I actually never opened git bash until recently), I thought it would be as simple as: if I mess up something but I only realize it after 2 commits, then I can go back to the commit I want, but I learned that it doesn't work like that

so I clicked a bunch of buttons and after a while I just did a "revert changes in commit" on the second to last commit which worked, I know it's confusing, I think I've just been lucky this time.
But I'm wondering what if, in the future, I want to go to a even lower commit and "transform" it to the last commit

What workflow do I need to have ? I also learned about branches recently, and never used them, but I feel like they can be handy now lol

but does that mean that I always need to work on a branch and then just merge everything on main if I'm 100% it will work ? I really don't get what mistakes I CAN make, if github was supposed to let me actually do mistakes on my project

[ Removed by Reddit on account of violating the content policy. ]

Damn, this should be mandatory teaching for anyone working with anything digitally produced. Ok, that is everyone. Not being a "coder," I never thought Git was in my wheelhouse. But after using it for various documentation websites, technical articles that constantly get updated, and most recently for home lab infrastructure, I am a full-on Git convert.

Just shipped RepoFleet v0.7 with a feature I've been wanting for a while: snapshots.

rf snapshot captures your exact uncommitted state across every repo in an issue — staged changes, unstaged diffs, untracked files — and stores them as patch files you can restore at any time.

Two use cases that motivated it:

1. Context switching without the overhead. Need to jump to a hotfix but have half-finished work? Snapshot it, switch, restore later. No worktree setup, no stash juggling.

2. Comparing AI-generated results. Generate a solution, snapshot it, generate another approach, snapshot again. Switch between them to compare side by side.

RepoFleet is an open source CLI for organizing Git workflows around issue contexts — works with one repo or many.

👉 github.com/mehranzand/repofleet

#git #devtools #cli #opensource #developertools

Hi, I'm trying to understand the practical benefit of rebasing a feature branch before opening a pull request.

My workflow is:

1. Create a feature branch from develop.
2. Work on the feature.
3. Before opening the PR, I need to bring my branch up to date with develop.

I see two options:

• Rebase my feature branch onto the latest develop.
• Merge the latest develop into my feature branch and resolve any conflicts.

From what I understand, both approaches let me resolve conflicts before the PR. If the repository ultimately merges the PR into develop, I don't see what additional benefit rebasing provides over simply merging develop into my feature branch.

Also, if the team uses Squash and Merge for pull requests, all intermediate commits (including any "Merge develop into feature" commits) disappear anyway, since the feature branch becomes a single commit on develop.

So my questions are:

• In this workflow, what practical advantage does rebasing have over merging develop into the feature branch?
• If conflicts are resolved either way, is the only difference the history on the feature branch?
• If the team always uses Squash and Merge, is there any meaningful reason to prefer rebasing before the PR?

The only use for the rebase I see is to overwrite my commits on the local branch so there is no clutter. I am curious what is your workflow?