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. 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. 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). This personal repo was very useful for saving my work. 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). the code in your personal Git repo that constitutes unpushed commits to the upstream branch).Īdditionally, 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. The flag "-ff-only" basically just means "refuse to start a local merge while performing this operation, and instead fail".īecause 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. 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. 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. But you resolve this locally, by updating your (unpushed, local) commit(s) to account for the new history. 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. If your change and the new commits from origin aren't touching the same lines or files, then the update is seamless. It will only ever modify your local unpublished commits to account for new commits from the origin branch. "git pulll -rebase" will not ever rewrite history from the origin repository. If "git pull -rebase" succeeds without reporting a merge conflict, then it's tantamount to having executed the command with "-ff-only". 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. 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. Has the project not changed the CLI for compatibility reasons or something? 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. You can achieve this in your global Git configuration by setting "pull.rebase" to "true". 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. There are configuration settings to make "git pull" rebase by default, and I'd recommend always turning that on that default (which may be by why the person above omitted it from his pull command). The command you want is "git pull -rebase".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |