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.
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.