The worst part is the "easier" solutions are actually just footguns in disguise, as soon as they accidentally click the wrong thing and end up with a detached HEAD, a few commits ahead and behind the REMOTE, and halfway through a botched merge, you have to figure out how to bail them out of that using a GUI you've never actually used. Knowing all this, you either teach them git (high short term pain, high chance of them just giving up immediately) or you tell them to download the first result for "windows foss git gui" and pray that history won't repeat itself.
It has a few helpful hints.
> If that doesn't fix it, git.txt contains the phone number of a friend of mine who understands git. Just wait through a few minutes of 'It's really pretty simple, just think of branches as...' and eventually you'll learn the commands that will fix everything.
Using GitExtensions means I can use Git as easily as any other tool, I never give it a second thought. I see the command line commands being executed, but never think about them. The flipside is I'd be knackered if I had to use the command line only.
This is once of those scenarios where subscription for an enterprise might be a thing, but makes no sense for me. The JetBrains model would make sense and I could justify that.
You just don't get new features.
My issue is that I do not get £5 worth of value each month from GitKraken. I get value every couple of months, and it is to explain to other people what they are doing wrong rather than direct value for me.
The risk is that they have to keep "doing stuff" to justify a subscription and we will end up with a new email client.
git stash
git reset --hard master
git pull
git stash popMy git config has fast-forward only for pulls and I habitually use --ff-only for any pull :)
I actually thought "git pull" did "git pull --rebase" by default (this may be what you get from running `git --configure` without modifications?), but maybe I've just been configuring it that way. You can achieve this in your global Git configuration by setting "pull.rebase" to "true".
I don't think it's sane behavior for "git pull" to do anything else besides rebase the local change onto the upstream branch, so I'm surprised it's not the command's default behavior. Has the project not changed the CLI for compatibility reasons or something?
When do you ever want a "git pull" that's not a rebase? That generates a merge commit saying "Merge master into origin/master" (or something similar) which is stupid. If you really want to use actual branches for some reason, that's fine, but "merge master into master" commits are an anti-pattern that if I ever see in a Git repository I'm working on or responsible for, results in me having a conversation with the author about how to use Git correctly.
I believe you are incorrect however. "git pulll --rebase" will not ever rewrite history from the origin repository. It will only ever modify your local unpublished commits to account for new commits from the origin branch. If your change and the new commits from origin aren't touching the same lines or files, then the update is seamless [1].
If there is a conflict because your change and a new commit from origin both changed the same line in the same file, this can result in a merge commit that you need to resolve. But you resolve this locally, by updating your (unpushed, local) commit(s) to account for the new history. When you complete the merge, it will not show up as a merge commit in the repository -- you will simply have simply amended your local unpublished commit(s) only to account for the changes in upstream, and you will have seen every conflict and resolved each one yourself. When the process is complete, and you've resolved the merge, you'll have a nice linear branch where your commit(s) are on the tip of the origin branch.
The flag "--ff-only" basically just means "refuse to start a local merge while performing this operation, and instead fail".
Because of the potential for these merge conflicts, it's a best practice to "git pull" frequently, so that if there are conflicts you can deal with them incrementally (and possibly discuss the software design with coworkers/project partners if the design is beginning to diverge -- and so people can coordinate what they're working on and try to stay out of each other's way), instead of working through a massive pile of conflicts at the end of your "local 'branch'" (i.e. the code in your personal Git repo that constitutes unpushed commits to the upstream branch).
Additionally, all of the central Git repositories I've worked in in a professional context were also configured to disallow "git push --force" (a command that can rewrite history), for all "real" branches. These systems gave users their own private Git repo sandbox (just like you can fork a repo on GitHub) where they can force push if they want to (but is backed up centrally like GitHub to avoid the loss of work). This personal repo was very useful for saving my work. I was in the habit of committing and pushing to the private repo about once every 30m-1h (to eliminate the chance of major work loss due to hardware failure). Almost always I'd squash all of these commits into one before rebasing onto master, so that the change comes in as a single commit, unless it would be too large to review.
In the occasional circumstances where I've legitimately needed to rewrite history for some reason -- say credentials got into the repository, or someone generated one of these "merge master into master" commits -- then I would change HEAD from master to another branch, delete master, and then recreate it with the desired state. (And even that operation would show up in the system's logs, so in the case of something like credentials you'd additionally contact the security or source control team to make sure the commit objects containing the credentials were actually deleted out of the repo history completely, including stuff you can find only via the reflog.) Then contact the team working on the repo to let them know that you had to rewrite history to correct a problem.
I would recommend disabling "git push --force" for all collaborative projects. If you're operating the repository, you can do this by invoking "git config --system receive" and setting "denyNonFastForwards true". In GitHub there's probably a repository setting switch somewhere.
Once professional software engineers start working with Git all day long, they quickly get past the beginner stage and the need to do this kind of stuff is very rare.
[1] It doesn't mean the software will work though, even if both changes would have worked in isolation. You still need to inspect and test the results of "git pull (--ff-only)", since even if there are no conflicts like commits that modify the same lines as yours, or there are conflicts that Git can resolve automatically, it's possible for the resultant software logic to be defective, since Git has no semantic understanding of the code.
this is not correct. git rebase, as with git merge, will automatically resolve conflicts using a 3-way merge algorithm.
> It will only ever modify your local
this is correct.
> unpublished commits
this is not correct. git rebase (in its default mode) rebases all commits that are not upstream onto the upstream. it has nothing to do with whether they are published or not. if you have a published feature branch, and git pull --rebase into it, git rebase will dutifully rebase all your commits.
I get pushing every day, but how unreliable does your PC have to be if you feel you need to push every hour???
> (And even that operation would show up in the system's logs, so in the case of something like credentials you'd additionally contact the security or source control team to make sure the commit objects containing the credentials were actually deleted out of the repo history completely, including stuff you can find only via the reflog.)
You can't un-leak credentials. The only valid action for leaked credentials is to invalidate them, not to pretend that they were never leaked.
Hey, I commit and push on a branch on my fork of the repo every time my unit tests work and sometimes if they don't.
It's a single command, `gi`. My joke is "commit/push is the new save" though I'm not that bad...
No one but me has to see that branch. I rely on my rebasing skills and a library of git tools to produce a small number manicured commits out of it with no work.
It works so well. For one, if I am going from one machine to another, I can literally work and then step off my machine and continue on the other with a pull but no interruption.
At any time, I can just send someone a question with a permalink to the code as it was at that moment, and keep working while waiting for the answer.
I never have much uncommitted work in the current branch, so I can almost immediately start a new bugfix in an emergency.
> The only valid action for leaked credentials is to invalidate them,
Quoted for truth.
# git branch -av;
# git remote -v;
# git reflog; git help reflog; man git-reflog
# git show HEAD@{0}
# git log -n5 --graph;
git add -A; git status;
git stash; git stash list;
git pull --rebase;
#git pull --rebase origin develop
# git fetch origin develop
# git rebase origin/develop
git stash pop;
git stash list;
git status;
# git commit
# git rebase -i HEAD~5 # squash
# git push
There's a way to default to --rebase for pulls: is there a reason not to set that in a global gitconfig? Edit: From https://stackoverflow.com/questions/13846300/how-to-make-git... :
> There are now 3 different levels of configuration for default pull behaviour. From most general to most fine grained they are: […]
git config --global pull.rebase trueAfter reading more about it, you are right about that. It will only apply your commits to the tip of remote.
If you can make one that thinks in terms of git on the backend, great.
If you want to go a bit further, you could expose the underlying operations to the user. You will need to get them to reason around and interact with the minimal requirements inherent to a versioning system, namely explicit versioning and an explicit commit process, along with explicit merging and conflict resolution.
There are GUI clients that help with some of this, but you're not going to get away from some concept of dealing with branches and merges in any SCM. You hear about it less often, but you'd have the same troubles dealing with a chewed up repository in Perforce, ClearCase, or the like.
(edit: even Subversion!)
And some statisticians and stuff only know how to use the GitHub desktop client and that works ok for 99% of them. Drives me crazy because I only use cli and struggle to help when they get blocked with the client.
The question really should be why do we want to use git for version control when people really want an backup system where they can essentially update files by uploading a new version of the file.
Designer: Hey, I filed a bug for this, it doesn't look like the design. <screenshot of design they changed yesterday>
Developer: Um, we released that like two weeks ago; it's correct according to the design I had at the time.
Designer: Yeah, but this is the design <link to continuously updated document in web editor with no history> Maybe you can just fix it really quick today?
Doesn't have to be git, but some way to match up releases to the design document that was current at that time is quite useful.
So you could tell the designer that you have the version they sent you on Friday August 13, 2021 at 3:12 PM EDT. Did they make any changes after that, or did they mean to send you a version they made prior to that?
But I think the reason is because the mess of folders they then create in DropBox and they can never find their files.
What would be great is if someone could make a TimeMachine for non-developers that uses git, because that is what they are doing in their heads anywy.
Integrating those file(s) as a submodule or subtree in a git repository would work on the development side, but people who generate those files would have no need to interface with git, and people who use git would not need to use the editor for those files to get the history they need.
But yeah, I pay for it now because it's such a significant time saver for my day-to-day. I'm always aware of what my coworkers are doing because it auto-fetches every minute. I use it for code review as well, because I find it really easy and snappy to navigate file changes in a commit (I always use split view, and I almost always have "hide whitespaces changes" on). I has a great interface for interactive rebases as well, allowing to drag to reorder commits, etc. Good built-in merge conflict resolution tool.
GitHub's web interface is pretty good for this.
What GitHub has going for it is that it is familiar to ("a majority of"?) working developers, and that it's better than both the competition and the Git CLI itself, but from a reality-adjusted perspective, GitHub is pretty bad, too. (Then when people like me make comments like this, others wrongly infer that it comes from a history of false starts and firsthand frustration, unable to conceive that anyone would speak up on this sort of thing if there weren't something personal at stake; no way that it could just be the result of empathy for the uninitiated.)
It's pretty tragic that we've basically killed wikis —like, actual wikis—and regressed back to directories of text files managed by version control systems originally meant for handling program source code. That people then go on to call these wikis is basically an insult to history.
52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f
1. Go to dev branch
2. Find file and edit it
3. Commit change
What are the steps to edit a wiki? Click edit page, make changes, add comment and submit. That sounds like almost the exact same steps to me.
https://github.com/solid/solid-rest
(It's the only link in the file.)
Make sure you don't have your thumb on the scale.
$ sha256sum "./PR?-ORLY.txt"
52028d35999a481e7cb19b14eae3bf66cb7c9c4fe2e15b56b55f3ccadffeee1f ./PR?-ORLY.txt
$ cat "./PR?-ORLY.txt"
Did you commit to source control and submit a pull request to post this comment?GitHub Learning Lab: https://lab.github.com/
https://learnxinyminutes.com/docs/git/ #Further_resources
The problem is, as soon as someone needs any of the non-basic operations, they're completely stuck, and have to start out by learning the basics (which they've managed manged to avoid so far).
Plus, each implementation makes up its new terms and abstractions.
I'm not experienced here, but is using the GitHub website perhaps the easiest way to submit a PR, that's how I first did it and I think it worked ... I've only really used git privately and for pulling code from public projects.
Is graphic designer even going to be able to merge things in their files?
It seems that "overwrite my files by data in repository" "apply my changes with message" are all what is necessary? Or is it case of multiple nontechnical people editing files together and expecting to merge changes?
Another extremely common pain is trying to "delete" a local commit.
The only thing lacking is public code spaces. I can’t even try them out without paying for GitHub Teams or GitHub Enterprise.
Wow, never heard about this (ok I don't follow all possible tech news), but why is this not clearly advertised on github itself? Looks pretty neat and seems to work fine (for what it offers) as well.
I can't find `.` on this page: https://docs.github.com/en/get-started/using-github/keyboard...
It used to explain itself through building your own version of git. You have a file named hash that tracks changes on each file named foo... now all the changes are in a directory named hash...now your changes have to be merged with others...
It's kind of up there with next steps after if then else fi. Some things will always be difficult, but diffs and commit and picking one of two possible diffs from two windows should not be one of them.
Just think of the "places" a change can be in (technically most of these are just labels on the tree, but they have separate commands to deal with them).
Remote, Index, working copy, staging area, stash, branches.
Those are the ones involved in the simples way I know how to make the smallest change. When you get up to stuff like submodules, LFS, subtrees then I very much understand when people get frustrated. All most of them wanted is a slight improvement over copying a folder they named myproject_v23 to a network drive.
https://code.visualstudio.com/blogs/2021/06/10/remote-reposi...
Combined with things like Codespaces, I can see a lot of intro classes glossing over some of what's happening under the hood.
That said, I really do think that skills like learning how to use a terminal and work through the CLI are necessary for developers to grow. It's not so different from how woodworkers don't just learn how to use a chisel, but also how to sharpen and bevel the tool as well.
I don't get this.
"Can you imagine? Learning to program a computer took us some hours!"
What do you expect? That people without prior knowledge or experience just pick up source control in seconds? I'm honestly wondering - what makes you think source control systems are so trivial? Is it really too much to ask a newcomer to invest some hours into learning something these days?
I mean, ideally, that'd be great. I don't think there's any fundamental reason things can't be this way, many of these complexities are completely incidental, rather than inherent.
> Is it really too much to ask a newcomer to invest some hours into learning something these days?
No, but when I'm learning something, I prefer for my time to be spent on important stuff, not wasted unnecessarily.
Using SCM for teaching development to newbies is already adding unnecessary complexity (even in a collaborative setting, flows are complex enough to distract from more fundamental topics).
If you're a software developer getting to the point where using git is needed you should absolutely know the core concepts behind public key cryptography, it's going to come up everywhere and you can fuck up big time by publishing the wrong part.
https://github.com/digitalocean/tos
There are plenty of text file versioning use cases I think, from configuration files for system administrators to LaTeX papers for science students who could benefit and should have an easy path to using it.
Heck even if you want to host a static site you probably want to just be on github these days.
Yet to me there is no reason for version control to be this complex. The current github + git universe is locked in, but I don't see why it should be optimal.
There is no such thing as a project not complex enough to warrant a SCM/VCS. There's probably an argument that there is a case where a DVCS is unnecessary, but if you aren't actually doing distributed work there's no reason you need to be aware of more complexity in a DVCS than a non-D VCS.
I have a program I wrote that helps me straighten scanned images in bulk. It took maybe an hour to write because I did it in D and was not familiar with the language. Though I have used it for years now and made a few tweaks I have never felt the need to have it in any kind of source control.
I and most developers I know use git or similar for projects of any size, often even if it's "just" a single file or a "one-off" change (because it rarely stays that way).
I would have agreed in the days when Subversion was the closest you could get to "easy version control" but these days in my eyes "the point where using git is needed" is not far from the point where you start making changes to an existing file.
The alternative is just doing what you always do on every project: run "git init" and occasionally do a "git add -i && git commit". Even if you end up with a lot of non-descriptive snapshots name "WIP" at least you have something resembling a chronology and you can track changes across multiple files at the same time.
If your hobby projects mostly consist of single files with thousands of lines that are easy to unambiguously make copies of for backups, I won't judge you, but your experience is definitely not universal.
Or I just let my backup software handle it. Automated daily backup supplemented with manually initiated backup if I need a specific point-in-time snapshot.
This isn't rocket science.
I remember the first time I tried to use SCM. It was a collaborative project in college, and our professor recommended we set up a CVS repo (at that point in time, he probably should have recommended SVN, but we didn't know that). We spent about an hour trying to set one up, and eventually concluded it was a waste of time and that we'd just e-mail each other .tar.gz files of the repo and manually sync them. Eventually we did break something and have to go back to the last .tar.gz to un-break it, which wasted another hour or so, but with the friction we'd seen trying to set up CVS, that still seemed preferable to trying SCM again (although it also showed that SCM would have been helpful had we been able to set it up).
GitHub with a password is much easier than setting up a CVS repo as a newbie, and had that been an option then we likely would have succeeded. But I'm much more doubtful that we would have tried and succeeded at token authentication; I also remember how mystifying I found it the first few times I worked somewhere that required it, even understanding the underlying concepts of public key cryptography. The problem is understanding the tools well enough to get it working, and working across operating systems (Linux doesn't have PuTTY; Windows doesn't have the Linux command-line tools; etc.).
When I eventually started using SCM reliably, it was with Mercurial + BitBucket + a password. I recall that I kind of knew I should set up a token, but my first few attempts were unsuccessful (largely due to most instructions being Linux-focused, and being on Windows), and thus I kept using a password for years because making progress on development seemed more useful than figuring out a token. I did use randomly-generated, lengthy, unique passwords, so the risk of using a password seemed pretty low.
So I think this is a bad thing for newcomer-friendliness. Perhaps it is an opportunity for GitLab and whatever other competitors still exist. But I would have rather seen it remain an option, perhaps based on new users choosing whether they're new to Git (allow passwords) or experienced (require tokens, but be able to change it in case they're only experienced with Git, and not with tokens).
I wouldn't call installing a vcs "learning to program".
A better analogy might be: "Can you imagine, opening an A4 notepad to take lecture notes took us some hours"
Not a perfect analogy I know but "setting up tools to start learning" != "learning completely"
Either way, I don't really get this kind of aggressive resistance to making things more accessible...
And using a notepad to take notes relies on your having learnt how to read and write in general, which took a significant amount of time.
That being said, I agree with it being good to try make things as accessible as possible, so long as it doesn't impact overall utility.
The commenter is referring to the tooling around git, wasting valuable teaching time.
For example, most people will only ever have one ssh key on their device. Having to setup the keyring, and keeping aware of its nuances, is a waste of time.
Git is a wonderfull tool for exploring a development process unlike anything that’s existed in other domains, but in my experience it is mostly used as a write only tool to deploy code.
It's really important to me that whoever I'm teaching is able to really understand each piece and build their intuition as we build things up.
FTP is a bit orthogonal to the use case here. That being to have her code pushed up to a central repository, able to clone it on her other computer (laptop), and enable me to review it or tweak things.
Never before have humans experienced such an overabundance of learning materials (YouTube, blog posts, StackOverflow, books, courses, etc). So much of it easily accessible and available for free. The tooling continually improves.
What most people are missing these days is a goddamned attention span and a dash of humility.
This isn't about mastering source control systems (that can take years). This is about taking a complete newcomer with absolutely no background whatsoever from nothing to something in three hours, which is an absolute miracle in and of itself. Will you also complain about how hard it is to learn how to swim, paint, use chopsticks, change a tire or play chess?
Quantity unfortunately doesn't mean quality.
Without experience it is hard to separate low quality from high quality content. And then there's are.many things which are outdated ...
Start QBASIC
Enter:
PRINT "Hello World!"
Run the program.
Congratulations, you wrote your first program and have become a software developer
python3
> print(“Hello world”) >>> print(“Hello world”)
File "<stdin>", line 1
print(“Hello world”)
^
SyntaxError: invalid character '“' (U+201C)Oh and probably you should be using a package manager to do it so figure out which one’s on your system first and learn its interface.
Oh and it’s best practice to create projects in a virtualenv so install that too, and learn how to use it.
Start ipython (or the interactive interpreter for your language)
Enter:
print("Hello World!") See the result!
When you use git directly, you at least get all the tools to solve your problems. When you use (most) frontends, you don't. And you learn: If there are errors, just start over - much easier!
This is not the fault of developers, it's shitty tooling + bad tutorials + bad defaults in tooling + unsuitable defaults in git (git's defaults are for the workflow used in the kernel, NOT the workflow most git users use, which is completely different; it's actually amazing that the same tool can support both workflows pretty well, with the right config settings).
On Windows I use TortoiseGit and although I find certain things to require a few more clicks than I would like, it has been able to handle very nearly everything I have ever needed to do with Git. Management of worktrees seems to be the only thing I wish it would add, but once you add a worktree folder using the command line, it is then able to work with it perfectly fine.
It even recently added dark mode!
Every other Git GUI I've tried only seems to cover "pull", "merge" and "push" workflows competently, at best. If you want to do anything more complex like even a slightly interesting rebase, then they seem to be a nightmare. So I completely agree with your assessment there.
I don't really know Git CLI very well and the thought of using it exclusively seems very inefficient and painful. As with any decent GUI program, TortoiseGit exposes available functionality reasonably well and you don't have to resort to reading a large manual to become proficient.
For both Linux and Mac (which I use rarely to work on issues with a cross-platform Electron app), I have yet to find a Git GUI app that I am satisfied with.
When I looked, Fork appears to be pretty good, I should probably at least try the evaluation and if it's okay just pay the seemingly reasonable $50 fee, but it's a pity it doesn't also support Linux.
I know GitKraken works on Linux, but it's one of those clients which is not nearly powerful enough for my needs and it costs $60 a year, I think GitKraken's popularity is largely driven by their eye-candy and that many Git users don't really understand Git beyond the simple workflows.
As a novice, you don't understand the benefit provided by the tools, so you don't bother learning them. As an expert, you've forgotten the shape and impact of the massive learning curve faced by the novice so you don't understand why they don't bother overcoming it.
I suspect the 80/20 rule applies here - a GUI provides 80% of the value of a source control system, 80% of the time. If occasionally you do have to delete everything and start again, that may actually be a more effective technique than spending a lot of time learning Git beforehand, despite how crazy it looks from the perspective of an expert.
Either way, GitHub's authentication change doesn't seem to be the problem people are making it out to be.
This will certainly be a little more difficult for newcomers, and not very discoverable, but it is there.
Okay, no big deal, I just have to spend an extra second searching for the copy password icon, since it’s not in the same place as every other account password—but did this really improve my security at all? It’s just a different password.
> Tokens offer a number of security benefits over password-based authentication:
> - Unique – tokens are specific to GitHub and can be generated per use or per device
> - Revocable – tokens can can be individually revoked at any time without needing to update unaffected credentials
> - Limited – tokens can be narrowly scoped to allow only the access necessary for the use case
> - Random – tokens are not subject to the types of dictionary or brute force attempts that simpler passwords that you need to remember or enter regularly might be
I pretty much do the same thing, I just copy-and-paste a PAT from my password manager when I need it on VMs. The big benefit to us is that PATs are "limited", and mine only has Git repo access, so unlike my password, it can't:
- Delete repos
- Edit my GitHub organization
- Share my private repos with other users
- Add/remove SSH keys from my account
There's always the chance that a software you install on your VM would contain a keylogger (e.g. NPM/PyPI malicious libraries), so limiting the damage that your credentials can do is always a good thing.
Still, it's good to be in the habit of doing this, because sometimes you do need it.
So maybe it didn't improve your security, if you were already letting your password manager generate distinct passwords, but it almost certainly improves the median user's security, who has come up with a weak password they think is strong, and may well use that password on multiple websites.
Generating the accout password instead of allowing a user-supplied password would also work here (and incentivize the use of password managers, if enough websites did it), but I would guess getting people onto SSH keys is useful for them in general - e.g., it allows them to make 2FA or CAPTCHAs mandatory for use of high-abuse-potential features like CI or Codespaces.
Then they want you to generate a new token, in the "new format". Then they refuse to generate a token valid for more than a year. With a dark pattern where you push the "generate" button, but nothing happens.
Then comes dealing with Git itself. If you have a credential store file, there's no obvious way to log out of Git so that you get prompted for the new "authentication token". So I had to find out where it stores that data and delete the file. Then I could log back in with the new "authentication token". The documentation is written assuming you are using Git for the first time, not, as is more likely, updating an existing set of repositories.
(Why do I suspect that, at some point in the future, we will see "Log in with your Microsoft account?")
Of course you won't be able to do it in a couple of hours. Most people spend years learning the things that are required to understand how git works, or at least many months if you want to learn in a fast, intensive manner.
They don't need to know how git works, they need to know how to use it.
Just like I don't need to know the details of an internal combustion engine to drive a car, someone who only does CSS work doesn't need to know how git works to push commits. A simple GUI interface suffices there.
The problem is that the official Git GUI interface is unbelievably bad and happily lets you put yourself into situations that the GUI is completely incapable of getting out of. A default GUI that can't essentially softlock itself would be fine for most casual users.
There absolutely does. It's called Git GUI. It's right here: https://github.com/git/git/tree/master/git-gui
But, hey, git is sooooo superior. </s>
GitHub has done almost as much damage to version control as PowerPoint has done damage to presentations.
Git for Windows and most Linux distributions of git today include such a credential manager out of the box. Generally the only thing that needs to change to move to that workflow is adjust the muscle memory to grab HTTPS addresses, not git: addresses. (Which shouldn't be an issue for new people learning it for the first time, and GitHub's own UI has worked to get better at pushing the HTTPS links first.)
ETA: A link for the main tool that provides this user flow: https://github.com/microsoft/Git-Credential-Manager-Core
It also has an undo button to undo the last commit which has saved my ass a couple of times.
Anything but git. Git was definitely not designed for ease-of-use.
Only Linus and friends need or use 90% of git's features.
$ git add-ssh-key github.com
Checking for ssh key ... not found
Generating ssh key for you (ssh-keygen -t rsa)... done
Enter username for github.com: alberteinstein
Enter account password for [email protected]: **********
Touch your Yubikey now: <beep>
Uploading public key ... done
Welcome to Github!
$ git clone [email protected]:username/someprivaterepoDifficult question. In the past, the solution was just not to use any of that. A bunch of files inside a random folder in your computer that were not version controlled in any way. That worked, but that's also the reason I lost most of the source code that I've written before/during university.
Version control is not a simple problem. A distributed version control system, even less simple. Git has some ergonomics issues that may possibly get improved, but the fundamental problem is not trivial.
We already have to learn so much to do the simplest of tasks, that removing password auth seems to not move the little much, if at all.
You can certainly 'postpone' some of this learning, maybe that's one route. Back when there were "IDE wars", that would be one of the arguments ("we don't have to learn no stinkin' CLI"). Some IDEs even had their own, local, "version control". At some point you'll have to "pop open the hood" though.
This is what my company does. Except we use git. Everyone just keeps their repo on their drive and there's no central "canonical" repository. Everyone has a personal folder in the main fileserver and they push frequently to their personal remote repo.
Any time they send emails saying they've made a notable milestone, anyone curious just merges against their remote.
The codebases somehow rarely (never) diverge catastrophically. Maybe because we're doing embedded work.
Yep - when we need to release we just kind of merge everything into a release, compile the firmware, validate it in house and then send it to our contract manufacturer in China. "Who" does that depends on whoever is free or most closely tied to that update.
It probably feels really unnecessary to newcomers though. I haven’t used Github Desktop in a long time but I feel like this would be perfect for a Git client to handle. It’ll fill in the “it’s just like Dropbox but for code” mental space.
Passwords were useful until better alternatives were available, and are around now to satisfy authentication based on 'something you know'. As long as the necessity is to verify something you know or something you have, a private key can be more convenient.
People who prefer to enter through doors by entering a PIN instead of using a metal key will disagree.
The thing left to do is make maintaining this private key as frictionless as adding a metal key to my IRL keychain. The kids may have some good ideas :)
Those aren't goals that are in tension, but rather have pretty similar solutions..
The way for real projects to consistently follow the appropriate set of best practices applicable to their specific use case is for the project team to (1) identify what the appropriate practices are, (2) define workflows around them, and (3) build (or adopt existing, if available) tooling that wraps low level plumbing to implement the project workflows.
The way to offer a more gentle learning curve for budding developers is to...leave learning the details of low-level infrastructure tools for later, and to use workflow tools adapted for the project they are working on (whether its a real project or something one that is strictly pedagogical.)
"Pick a huge random number, this is a private key, you must never tell anybody else this key" is a fundamental operation. If they've never done this operation, that's more telling us how bad a job we did securing everything else than a problem with software development.
If the argument was, "But my users all have perfectly nice long term private keys for some other system" then we could leverage that to get keys to make GitHub work, but in reality that's not the case. SSH keys are likely the most common private key† full stop even though they're only needed to do the 21st century equivalent of telnet
† For people anyway, for machines Let's Encrypt means there are an eye-watering number of new private keys minted each day by Certbot and similar tools.
BUT, at the same time, I agree with you that the process of getting set up with GitHub is suboptimal. Have you used Heroku with git before? You run "heroku login" in the console, which then opens your browser. You sign in on the browser like normal and then the CLI magically knows who you are. You can then push and pull from heroku remotes with 0 friction. Maybe the GitHub CLI could/does have a feature like that.
While it is fine to require better auth, it should be in the hands of users. Otherwise adoption is severely endangered.
That said, Github is an extremely juicy target for someone trying to inject code in a lot of codebases without anyone noticing. So popular repos should certainly make use of it.
Use literally any GUI. Alternatively, press '.'
We start in the browser using the built-in editing functionality and build a PR, then when they're familiar with that we progress to GitHub Desktop and VS Code.
Worked really well so far, planning on trying both Codespaces and the `.` editor next.
https://docs.github.com/en/get-started/quickstart/set-up-git https://www.atlassian.com/git/tutorials
This one's always fun: https://learngitbranching.js.org/ https://www.tutorialspoint.com/git/index.htm
It walks you through installing a "cask" using "brew". It doesn't mention how to install homebrew but instead directs you to the homebrew homepage which shows the output of a curl command being fed to `bash -c`. Something that's both bad practice and unintelligible unless you're quite familiar with Unix shells. If everything works as intended, you're good to go! But if anything goes wrong, or you have to update the "cask" in the future you're left with little to no context about what you just did.
For someone unfamiliar with Unix shell commands, homebrew, curl, etc. this is a quagmire that can take days to unravel without someone there to help them.
You have to trust the place where you're downloading it from, of course. But there's nothing inherently worse about /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/inst...)" than burning https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/de... and booting it up.
Or are you saying that you audit the bits of the ISO yourself before burning it?
That's exactly why git is a bit of a pain to initially set up.
Github looks and behaves like a filesystem with a timeline, which is not accurate to how git works functionally, but that's what makes sense to most people out of the box
When I teach git, I make it very clear that GitHub is one of many services you could use. For our purposes, we're using it because GitHub is quite popular and is a familiar place to look when interviewing with a potential employer. But I stress that there are other options (eg. I host my own instance of Gitea).
To explain: She wants to eventually work as a developer and has a project in mind guiding her. I started her with the simplest possible steps and she's been learning html & css for a few weeks now with some great progress. She got the the point where she was starting to have multiple projects she was building for learning. In addition, she was starting to feel the pain of "this project is on my desktop, but I am going to be away from home for a week and will only have my laptop." For those reasons (as well as the benefit of introducing GitHub as a place of collaboration), we took some a few hours to cover git and the terminal.
It didn't seem like we jumped to it too early and after those three hours she had the basics which is good enough to ensure her projects are safely replicated to GitHub and available for her no matter which machine she is on.
But, if this person's goal is about creating a web application then version control is a good skill to have. I remember the days when source code for a web application was something we could zip up and hand to a client. But, these days, more than likely you have a remote server somewhere and you need to SSH into it and from there you could SFTP the files but at that point why not just use git and it's branch management. Obviously, there are more arguments that can be made for learning git.
With git you can install and git init anywhere and go you have source control. Moving commits to another machine gets us into the complications way above of learning GitHub and tools for GitHub, but in terms of 0-60 on "start a repository so you can commit changes" it's really hard to beat.
It's certainly a difficult problem. How can we offer a more gentle learning curve for budding developers while still requiring "real" projects to use best practices for security and development?