The point of this post is not to get everyone rebasing their branches for the sake of feeling cool, but instead I hope that more people learn just enough Git skills to achieve one simple goal: make your pull requests more focused and understandable to improve their chance of getting merged quickly (or even getting merged at all). So what is the point of mastering Git and becoming a rebasing wizard with the ability to rewrite history like you are Hermione Granger wielding a time turner‽ # anchorIt's all in the eye of the reviewer Even if you don't know exactly what you're looking at when you see the Fork interface, you will pick up the concepts of branching in Git much faster when you see a command's effect on the tree visualisation rather than an abstract set of characters in the command line. I have always been a visual learner so when I think about Git I very much see the branching model in my head.
Git clean repository download#
This is why, whenever I get the chance, I always recommend people to just download Fork. The fact that we funnel so many junior and intermediate developers into using git on the command line, I believe, has significantly hampered their ability to truly master Git. Sure there are plenty of places in the tech community where we have a gatekeeper problem, but this particular idea of "you're not a real developer if you don't do X" is the most pervasive and destructive. The most egregious thing that holds back people's understanding of Git is the concept that "if you don't use git on the command line then you're not a real developer" and this idea it needs to die. This potential I am talking about is not anything so complex as dealing with the reflog, or knowing anything about blobs or the internals of Git, I am just talking about people feeling comfortable understanding branches, rebasing, cherrypicking, and have the ability to clean up a branch before submitting it to a Pull Request (PR).
Git clean repository full#
It's my belief that a number of factors have held developers back from becoming super productive with Git, and with a bit of guidance in pairing sessions I can usually help people to unlock their full potential while using Git. Most of the time this works out, but then every so often we do something wrong or someone asks us to rebase or "squash" something and we either panic and/or mess up our git repo 😫 This is such a common feeling that sites like Oh shit, git! have cropped up to help us get out of our messes. Most of us learn Git up to a point where we're happy to use it day-to-day and then stick to the few commands that we are comfortable with without trying anything too fancy.
Git can sometimes be complex to get your head around. If you haven't already checked out Tobias' blog on Open Source maintenance I would highly recommend checking it out after reading this post 🎉 # anchorGit complexities It's not ideal I know, but in my case it was the issue history I wanted to keep, and a pruned version of the repo.This topic was inspired by some of my pairing sessions with my colleague Tobias Bieniek and the concepts laid out in this post have become invaluable to me while working with open source development. Now you can rename your old and new repos and hopefully you should be good to go. Now you can create a new project on gitlab by importing that tar.gz, and you should hopefully have all your issues, tags, etc from the original, but with the new repository.
Then replace the project.bundle in the downloaded tar.gz with the new project.bundle. Git bundle create /tmp/project.bundle -all Once ready, create a bundle of that new repo, ie: the one you want (from within that repo): Then create / modify / whatever the new repo you wish to replace the existing one with. First export your current repo and download the tar.gz file from gitlab (this contains the repo, issues etc). Moving all issues across to a new repo isn't an option either as the dates all get "today's" date and is cumbersome. I can easily reduce my local repo to < 1MB and force push that to gitlab, however the hosted repo simply doesn't reduce in size (I presume artefacts remain in the repo). I have repositories with a lot of crud in them that shouldn't have been there before which is why I wanted to do this. I've been asking myself this same question, and running through the same issues you mentioned.
0 kommentar(er)
