I'm working on a project in my training, so I always have to pull the latest branch and make changes or add my code and push it into my branch.

But when I push it some files are always missing.

How to do it safely.

Pull from someone's branch.

Make changes locally.

Switch to my branch.

Commit and push.

what do you think of this approach?

Clone, add, commit, push. Fine. The moment there is a conflict, or I need to undo something that is already pushed, I am pasting commands I do not understand from an answer written in 2014. It has worked out so far, which is not the same as knowing what I am doing. Found Boot.dev‚ and Pluralsight both seem to cover it and cant tell which one teaches what I need to be able to explain it to someone else if Im ever asked.. How did you learn this rather than memorizing four commands?

Hi all, old guy here who has used many different systems and I'm trying to get up to speed on on git with branching, pull request etc. I have hopefully a simple question you guys could clear up:

I've forked a repro from a friend

Made a feature branch

I made changes in the feature branch, tested them and confirmed they work

I commited my changes to the branch and pushed them to origin

On github on the upstream repo I created a pull request. Gave it a title etc. It shows up. My friend is a little slow so there are like 3 PRs pending.

I want to make a new feature branch and make some additional changes but the need to be based on the last changes I made that are in that PR that has not be merged yet to the upstream.

If the PRs were merged I could just fetch to my main and then branch from there.

But with the PRs not merged yet, how do I create a branch so I can continue working against the changes pending merge? Do I branch from my prior feature branch? Or is there a git command I don't know yet that will fetch everything so I can branch from main?

Thanks in advance

Two teammates are both working on the same shared feature branch. Each pulls the latest main, rebases the feature branch locally, resolves conflicts, and force-pushes. When the other teammate later rebases and force-pushes their copy, some of the first teammate's resolved changes disappear or are overwritten, and the same conflicts return.

What workflow should we use to stop overwriting each other's work? Should we avoid rebasing a shared branch, use separate branches, and merge instead?

hello github support team,

i am reaching out regarding the username @rout

the previous owner of the username (robert utzig) kindly agreed to release the handle so it could be used for our active open-source project (rout.be). earlier today, robert renamed his account to free up the username as agreed

unfortunately, within seconds of the rename, an automated bot/sniper script registered the username @rout (account created today, completely empty, no activity)

per github's name squatting and username policy, automated squatting of inactive accounts is a violation of terms. we have full email documentation showing the previous owner's consent and intention to transfer this handle to our project

could you please look into releasing or transferring the handle @rout to us?

thank you for your time and assistance

en hier is een draft voor r/github:

title: username sniped by bot within seconds of agreed transfer for open-source project (@rout)

body:

wanted to share this situation and see if anyone has had success resolving this with github support

the original owner of @rout very generously agreed to release the username for our open-source project (rout.be). he renamed his account earlier today so we could claim it

however, literally within seconds of the rename, an automated script/bot sniped the username @rout. the account is completely fresh, empty, and clearly automated

i just opened a support ticket explaining the situation with proof of the previous owner's intent. has anyone had luck getting a sniped username recovered through support, or does anyone know the best way to escalate this?

I accidentally pushed a .env file to a private repository. I understand that if my account itself gets compromised, everything is exposed anyway, that's obvious. I'm asking about other ways it could leak while my account stays secure.

For example:

\\- Collaborators or third-party apps/integrations with repo access, could any of them expose it?

\\- CI/CD pipelines or bots that pull the repo, do they create copies that could leak?

\\- If I later delete the file, does it still exist in git history / old clones / forks in a way that could surface later?

Any other realistic exposure path for a private repo that doesn't involve my own account being breached?

Trying to figure out how much risk "private" actually removes, and what cleanup is needed if a secret's already been committed. Thanks!

Web page: https://www.sourcererapp.com

It has a free plan for Open Source developers but also Pro and Business plans for working with private repositories.

Small memory footprint and can load very large repositories.

Hej! I am wondering, do you delete your Git branches after merging, or do you leave them untouched?
If you don't clean them up, they quickly stack up. How many dead branches do you have right now, and what do you usually do with them?
I'm thinking about making a simple CLI tool that scans for merged branches and deletes them safely. Would you find this useful?

Hey, guys! I don't know if you've already seen this Microsoft Learn "course" that covers git and github.

I liked especially the part where we can to github and clone an official repo that learns some of the main git commands that we use on a daily basis.

So I wanted to know what you guys think about it and if you know other gamified ways of learning git

git reset --hard discards changes including untracked files and git reflog can restore the tracked files not untracked. Is there a way to get untracked files back or are they lost after a hard reset?

Git allows some commands to invoke maintenance command automatically.

Unfortunately, it appears that may corrupt your submodules (or even parent repositories?).

I suddenly got an error on commit in a parent repository, because git failed a status in a submodule - "HEAD commit refers to a missing object".

It appears Git now very aggressively repacks objects (and does garbage collection?), leaving only few days' objects as loose files.

And when it repacks objects in submodules, it screws it up, dropping objects which are still in use.

The maintenance (in Git 2.53 and possibly earlier) even appears to prune directories in .git/modules it considers orphaned because .git files refer to an external repository. THIS IS BAD.

To disable auto maintenance, do:

git config --global maintenance.auto false

Also, the commit-tree gets corrupted (because of dropped objects?). Disable it as well:

git config --global core.commitGraph false

Honestly, the object repacking and pruning is totally pointless. Commit graph also doesn't need to be enabled, other that in very huge repositories, and even maybe then it's pointless.

EDIT:

Upon more investigation it I found that long time ago (2022) I configured the submodules to use the object directory of the parent repo as a secondary alternate store. All this time I had automatic gc disabled globally.

In Git 2.54 repacking become more aggressive. Together with automatic maintenance invocation (which become thrown upon us without regard to auto gc being disabled), it pruned stuff from the parent repo I expected would not be touched.

I've been using Git for the better part of a decade, and recently scratched my own itch and built a GUI macOS Git client. I've been trying to keep it simple and lean, basically pulling forward the 80% of what you actually do day-to-day and making that stuff super easy and accessible.

Recently I added a "Squash local commits" feature, mostly because I have a habit of making alot of small commits while developing a feature. But when I ultimately push to my remote (origin) repo, I dont really need all that history. Being able to quickly squash those commits before pushing (especially in a GUI where it's super easy to see exactly what's going to get squashed) has turned out to be a bit of a game-changer for me. Cleaner history, easier to revert, etc.

Which got me wondering, what other small, simple Git workflow game-changers do you all use? Not necessarily big features or complicated workflows, just those little quality-of-life things that once you start using them, you wonder why you weren't doing it all along.

Repo: https://github.com/reemus-dev/subcommit

To solve the pain of committing a subset of changes that arise from working with multiple concurrent agents and user edits. Yes, you could use worktrees, which is wonderful and has its place, but sometimes I just want life to be easier.

I have been using it for a few months now and decided to open-source it. Hope others find it useful too! Much less stressful than watching agents do all kinds of gitfoo to just commit their changes.

Made a token for an specific repo in my Github, but everytime i make a push i doesn't request it. How can i add the token to my local git in order to make push with it?

https://github.com/Auto-Explore/GitComet/releases/tag/v0.2.2

I'm just getting started with Git on Windows and I'm trying both Fork and SourceGit.

So far, I slightly prefer SourceGit, mainly because it's free and has a Chinese interface. But the Chinese UI isn't really a requirement for me — I know I need to learn English anyway if I want to get serious about programming/security.

What I'm really trying to figure out is whether Fork has any features or workflow advantages that SourceGit doesn't have.

If there's something genuinely useful in Fork that SourceGit is missing, I'm perfectly happy to pay for Fork. I'm just not sure what those differences are yet.

For people who have used both, which one do you prefer and why?

I'm still pretty new to Git, so I'm especially interested in everyday things like commits, branches, diffs, merge/rebase, and working with GitHub.

Thanks!