ran script/content-migrations/remove-map-topics.js && script/content-migrations/update-tocs.js
This commit is contained in:
Sarah Schneider
@@ -0,0 +1,109 @@
|
||||
---
|
||||
title: About Git rebase
|
||||
redirect_from:
|
||||
- /rebase/
|
||||
- articles/interactive-rebase/
|
||||
- /articles/about-git-rebase
|
||||
- /github/using-git/about-git-rebase
|
||||
- /github/getting-started-with-github/about-git-rebase
|
||||
intro: 'The `git rebase` command allows you to easily change a series of commits, modifying the history of your repository. You can reorder, edit, or squash commits together.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
Typically, you would use `git rebase` to:
|
||||
|
||||
* Edit previous commit messages
|
||||
* Combine multiple commits into one
|
||||
* Delete or revert commits that are no longer necessary
|
||||
|
||||
{% warning %}
|
||||
|
||||
**Warning**: Because changing your commit history can make things difficult for everyone else using the repository, it's considered bad practice to rebase commits when you've already pushed to a repository. To learn how to safely rebase on {% data variables.product.product_location %}, see "[About pull request merges](/articles/about-pull-request-merges)."
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Rebasing commits against a branch
|
||||
|
||||
To rebase all the commits between another branch and the current branch state, you can enter the following command in your shell (either the command prompt for Windows, or the terminal for Mac and Linux):
|
||||
|
||||
```shell
|
||||
$ git rebase --interactive <em>other_branch_name</em>
|
||||
```
|
||||
|
||||
### Rebasing commits against a point in time
|
||||
|
||||
To rebase the last few commits in your current branch, you can enter the following command in your shell:
|
||||
|
||||
```shell
|
||||
$ git rebase --interactive HEAD~7
|
||||
```
|
||||
|
||||
### Commands available while rebasing
|
||||
|
||||
There are six commands available while rebasing:
|
||||
|
||||
<dl>
|
||||
<dt><code>pick</code></dt>
|
||||
<dd><code>pick</code> simply means that the commit is included. Rearranging the order of the <code>pick</code> commands changes the order of the commits when the rebase is underway. If you choose not to include a commit, you should delete the entire line. </dd>
|
||||
|
||||
<dt><code>reword</code></dt>
|
||||
<dd>The <code>reword</code> command is similar to <code>pick</code>, but after you use it, the rebase process will pause and give you a chance to alter the commit message. Any changes made by the commit are not affected. </dd>
|
||||
|
||||
<dt><code>edit</code></dt>
|
||||
<dd>If you choose to <code>edit</code> a commit, you'll be given the chance to amend the commit, meaning that you can add or change the commit entirely. You can also make more commits before you continue the rebase. This allows you to split a large commit into smaller ones, or, remove erroneous changes made in a commit. </dd>
|
||||
|
||||
<dt><code>squash</code></dt>
|
||||
<dd>This command lets you combine two or more commits into a single commit. A commit is squashed into the commit above it. Git gives you the chance to write a new commit message describing both changes.</dd>
|
||||
|
||||
<dt><code>fixup</code></dt>
|
||||
<dd>This is similar to <code>squash</code>, but the commit to be merged has its message discarded. The commit is simply merged into the commit above it, and the earlier commit's message is used to describe both changes.</dd>
|
||||
|
||||
<dt><code>exec</code></dt>
|
||||
<dd>This lets you run arbitrary shell commands against a commit.</dd>
|
||||
</dl>
|
||||
|
||||
### An example of using `git rebase`
|
||||
|
||||
No matter which command you use, Git will launch [your default text editor](/github/getting-started-with-github/associating-text-editors-with-git) and open a file that details the commits in the range you've chosen. That file looks something like this:
|
||||
|
||||
```
|
||||
pick 1fc6c95 Patch A
|
||||
pick 6b2481b Patch B
|
||||
pick dd1475d something I want to split
|
||||
pick c619268 A fix for Patch B
|
||||
pick fa39187 something to add to patch A
|
||||
pick 4ca2acc i cant' typ goods
|
||||
pick 7b36971 something to move before patch B
|
||||
|
||||
# Rebase 41a72e6..7b36971 onto 41a72e6
|
||||
#
|
||||
# Commands:
|
||||
# p, pick = use commit
|
||||
# r, reword = use commit, but edit the commit message
|
||||
# e, edit = use commit, but stop for amending
|
||||
# s, squash = use commit, but meld into previous commit
|
||||
# f, fixup = like "squash", but discard this commit's log message
|
||||
# x, exec = run command (the rest of the line) using shell
|
||||
#
|
||||
# If you remove a line here THAT COMMIT WILL BE LOST.
|
||||
# However, if you remove everything, the rebase will be aborted.
|
||||
#
|
||||
```
|
||||
|
||||
Breaking this information, from top to bottom, we see that:
|
||||
|
||||
- Seven commits are listed, which indicates that there were seven changes between our starting point and our current branch state.
|
||||
- The commits you chose to rebase are sorted in the order of the oldest changes (at the top) to the newest changes (at the bottom).
|
||||
- Each line lists a command (by default, `pick`), the commit SHA, and the commit message. The entire `git rebase` procedure centers around your manipulation of these three columns. The changes you make are *rebased* onto your repository.
|
||||
- After the commits, Git tells you the range of commits we're working with (`41a72e6..7b36971`).
|
||||
- Finally, Git gives some help by telling you the commands that are available to you when rebasing commits.
|
||||
|
||||
### Further reading
|
||||
|
||||
- "[Using Git rebase](/articles/using-git-rebase)"
|
||||
- [The "Git Branching" chapter from the _Pro Git_ book](https://git-scm.com/book/en/Git-Branching-Rebasing)
|
||||
- [The "Interactive Rebasing" chapter from the _Pro Git_ book](https://git-scm.com/book/en/Git-Tools-Rewriting-History#_changing_multiple)
|
||||
- "[Squashing commits with rebase](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html)"
|
||||
- "[Syncing your branch](/desktop/contributing-to-projects/syncing-your-branch)" in the {% data variables.product.prodname_desktop %} documentation
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
title: About Git subtree merges
|
||||
redirect_from:
|
||||
- /articles/working-with-subtree-merge/
|
||||
- /subtree-merge/
|
||||
- /articles/about-git-subtree-merges
|
||||
- /github/using-git/about-git-subtree-merges
|
||||
- /github/getting-started-with-github/about-git-subtree-merges
|
||||
intro: 'If you need to manage multiple projects within a single repository, you can use a *subtree merge* to handle all the references.'
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
### About subtree merges
|
||||
|
||||
Typically, a subtree merge is used to contain a repository within a repository. The "subrepository" is stored in a folder of the main repository.
|
||||
|
||||
The best way to explain subtree merges is to show by example. We will:
|
||||
|
||||
- Make an empty repository called `test` that represents our project
|
||||
- Merge another repository into it as a subtree called `Spoon-Knife`.
|
||||
- The `test` project will use that subproject as if it were part of the same repository.
|
||||
- Fetch updates from `Spoon-Knife` into our `test` project.
|
||||
|
||||
### Setting up the empty repository for a subtree merge
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Create a new directory and navigate to it.
|
||||
```shell
|
||||
$ mkdir test
|
||||
$ cd test
|
||||
```
|
||||
3. Initialize a new Git repository.
|
||||
```shell
|
||||
$ git init
|
||||
> Initialized empty Git repository in /Users/octocat/tmp/test/.git/
|
||||
```
|
||||
4. Create and commit a new file.
|
||||
```shell
|
||||
$ touch .gitignore
|
||||
$ git add .gitignore
|
||||
$ git commit -m "initial commit"
|
||||
> [main (root-commit) 3146c2a] initial commit
|
||||
> 0 files changed, 0 insertions(+), 0 deletions(-)
|
||||
> create mode 100644 .gitignore
|
||||
```
|
||||
|
||||
### Adding a new repository as a subtree
|
||||
|
||||
1. Add a new remote URL pointing to the separate project that we're interested in.
|
||||
```shell
|
||||
$ git remote add -f spoon-knife git@github.com:octocat/Spoon-Knife.git
|
||||
> Updating spoon-knife
|
||||
> warning: no common commits
|
||||
> remote: Counting objects: 1732, done.
|
||||
> remote: Compressing objects: 100% (750/750), done.
|
||||
> remote: Total 1732 (delta 1086), reused 1558 (delta 967)
|
||||
> Receiving objects: 100% (1732/1732), 528.19 KiB | 621 KiB/s, done.
|
||||
> Resolving deltas: 100% (1086/1086), done.
|
||||
> From git://github.com/octocat/Spoon-Knife
|
||||
> * [new branch] main -> Spoon-Knife/main
|
||||
```
|
||||
2. Merge the `Spoon-Knife` project into the local Git project. This doesn't change any of your files locally, but it does prepare Git for the next step.
|
||||
|
||||
If you're using Git 2.9 or above:
|
||||
```shell
|
||||
$ git merge -s ours --no-commit --allow-unrelated-histories spoon-knife/main
|
||||
> Automatic merge went well; stopped before committing as requested
|
||||
```
|
||||
|
||||
If you're using Git 2.8 or below:
|
||||
```shell
|
||||
$ git merge -s ours --no-commit spoon-knife/main
|
||||
> Automatic merge went well; stopped before committing as requested
|
||||
```
|
||||
3. Create a new directory called **spoon-knife**, and copy the Git history of the `Spoon-Knife` project into it.
|
||||
```shell
|
||||
$ git read-tree --prefix=spoon-knife/ -u spoon-knife/main
|
||||
```
|
||||
4. Commit the changes to keep them safe.
|
||||
```shell
|
||||
$ git commit -m "Subtree merged in spoon-knife"
|
||||
> [main fe0ca25] Subtree merged in spoon-knife
|
||||
```
|
||||
|
||||
Although we've only added one subproject, any number of subprojects can be incorporated into a Git repository.
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip**: If you create a fresh clone of the repository in the future, the remotes you've added will not be created for you. You will have to add them again using [the `git remote add` command](/github/getting-started-with-github/managing-remote-repositories).
|
||||
|
||||
{% endtip %}
|
||||
|
||||
### Synchronizing with updates and changes
|
||||
|
||||
When a subproject is added, it is not automatically kept in sync with the upstream changes. You will need to update the subproject with the following command:
|
||||
|
||||
```shell
|
||||
$ git pull -s subtree <em>remotename</em> <em>branchname</em>
|
||||
```
|
||||
|
||||
For the example above, this would be:
|
||||
|
||||
```shell
|
||||
$ git pull -s subtree spoon-knife main
|
||||
```
|
||||
|
||||
### Further reading
|
||||
|
||||
- [The "Advanced Merging" chapter from the _Pro Git_ book](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging)
|
||||
- "[How to use the subtree merge strategy](https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html)"
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: Dealing with non-fast-forward errors
|
||||
intro: 'Sometimes, Git can''t make your change to a remote repository without losing commits. When this happens, your push is refused.'
|
||||
redirect_from:
|
||||
- /articles/dealing-with-non-fast-forward-errors
|
||||
- /github/using-git/dealing-with-non-fast-forward-errors
|
||||
- /github/getting-started-with-github/dealing-with-non-fast-forward-errors
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
If another person has pushed to the same branch as you, Git won't be able to push your changes:
|
||||
|
||||
```shell
|
||||
$ git push origin main
|
||||
> To https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>REPOSITORY</em>.git
|
||||
> ! [rejected] main -> main (non-fast-forward)
|
||||
> error: failed to push some refs to 'https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>REPOSITORY</em>.git'
|
||||
> To prevent you from losing history, non-fast-forward updates were rejected
|
||||
> Merge the remote changes (e.g. 'git pull') before pushing again. See the
|
||||
> 'Note about fast-forwards' section of 'git push --help' for details.
|
||||
```
|
||||
|
||||
You can fix this by [fetching and merging](/github/getting-started-with-github/getting-changes-from-a-remote-repository) the changes made on the remote branch with the changes that you have made locally:
|
||||
|
||||
```shell
|
||||
$ git fetch origin
|
||||
# Fetches updates made to an online repository
|
||||
$ git merge origin <em>YOUR_BRANCH_NAME</em>
|
||||
# Merges updates made online with your local work
|
||||
```
|
||||
|
||||
Or, you can simply use `git pull` to perform both commands at once:
|
||||
|
||||
```shell
|
||||
$ git pull origin <em>YOUR_BRANCH_NAME</em>
|
||||
# Grabs online updates and merges them with your local work
|
||||
```
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Getting changes from a remote repository
|
||||
intro: You can use common Git commands to access remote repositories.
|
||||
redirect_from:
|
||||
- /articles/fetching-a-remote/
|
||||
- /articles/getting-changes-from-a-remote-repository
|
||||
- /github/using-git/getting-changes-from-a-remote-repository
|
||||
- /github/getting-started-with-github/getting-changes-from-a-remote-repository
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
### Options for getting changes
|
||||
|
||||
These commands are very useful when interacting with [a remote repository](/github/getting-started-with-github/about-remote-repositories). `clone` and `fetch` download remote code from a repository's remote URL to your local computer, `merge` is used to merge different people's work together with yours, and `pull` is a combination of `fetch` and `merge`.
|
||||
|
||||
### Cloning a repository
|
||||
|
||||
To grab a complete copy of another user's repository, use `git clone` like this:
|
||||
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>REPOSITORY</em>.git
|
||||
# Clones a repository to your computer
|
||||
```
|
||||
|
||||
You can choose from [several different URLs](/github/getting-started-with-github/about-remote-repositories) when cloning a repository. While logged in to {% data variables.product.prodname_dotcom %}, these URLs are available below the repository details:
|
||||
|
||||
|
||||
|
||||
When you run `git clone`, the following actions occur:
|
||||
- A new folder called `repo` is made
|
||||
- It is initialized as a Git repository
|
||||
- A remote named `origin` is created, pointing to the URL you cloned from
|
||||
- All of the repository's files and commits are downloaded there
|
||||
- The default branch is checked out
|
||||
|
||||
For every branch `foo` in the remote repository, a corresponding remote-tracking branch
|
||||
`refs/remotes/origin/foo` is created in your local repository. You can usually abbreviate
|
||||
such remote-tracking branch names to `origin/foo`.
|
||||
|
||||
### Fetching changes from a remote repository
|
||||
|
||||
Use `git fetch` to retrieve new work done by other people. Fetching from a repository grabs all the new remote-tracking branches and tags *without* merging those changes into your own branches.
|
||||
|
||||
If you already have a local repository with a remote URL set up for the desired project, you can grab all the new information by using `git fetch *remotename*` in the terminal:
|
||||
|
||||
```shell
|
||||
$ git fetch <em>remotename</em>
|
||||
# Fetches updates made to a remote repository
|
||||
```
|
||||
|
||||
Otherwise, you can always add a new remote and then fetch. For more information, see "[Managing remote repositories](/github/getting-started-with-github/managing-remote-repositories)."
|
||||
|
||||
### Merging changes into your local branch
|
||||
|
||||
Merging combines your local changes with changes made by others.
|
||||
|
||||
Typically, you'd merge a remote-tracking branch (i.e., a branch fetched from a remote repository) with your local branch:
|
||||
|
||||
```shell
|
||||
$ git merge <em>remotename</em>/<em>branchname</em>
|
||||
# Merges updates made online with your local work
|
||||
```
|
||||
|
||||
### Pulling changes from a remote repository
|
||||
|
||||
`git pull` is a convenient shortcut for completing both `git fetch` and `git merge `in the same command:
|
||||
|
||||
```shell
|
||||
$ git pull <em>remotename</em> <em>branchname</em>
|
||||
# Grabs online updates and merges them with your local work
|
||||
```
|
||||
|
||||
Because `pull` performs a merge on the retrieved changes, you should ensure that
|
||||
your local work is committed before running the `pull` command. If you run into
|
||||
[a merge conflict](/articles/resolving-a-merge-conflict-using-the-command-line)
|
||||
you cannot resolve, or if you decide to quit the merge, you can use `git merge --abort`
|
||||
to take the branch back to where it was in before you pulled.
|
||||
|
||||
### Further reading
|
||||
|
||||
- ["Working with Remotes" from the _Pro Git_ book](https://git-scm.com/book/en/Git-Basics-Working-with-Remotes)"{% if currentVersion == "free-pro-team@latest" %}
|
||||
- "[Troubleshooting connectivity problems](/articles/troubleshooting-connectivity-problems)"{% endif %}
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Using Git
|
||||
intro: ''
|
||||
redirect_from:
|
||||
- /articles/using-common-git-commands
|
||||
- /github/using-git/using-common-git-commands
|
||||
- /github/using-git/using-advanced-git-commands
|
||||
- /categories/52/articles/
|
||||
- /categories/advanced-git/
|
||||
- /articles/using-advanced-git-commands
|
||||
- /github/using-git/changing-author-info
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
children:
|
||||
- /pushing-commits-to-a-remote-repository
|
||||
- /getting-changes-from-a-remote-repository
|
||||
- /dealing-with-non-fast-forward-errors
|
||||
- /splitting-a-subfolder-out-into-a-new-repository
|
||||
- /about-git-subtree-merges
|
||||
- /about-git-rebase
|
||||
- /using-git-rebase-on-the-command-line
|
||||
- /resolving-merge-conflicts-after-a-git-rebase
|
||||
---
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: Pushing commits to a remote repository
|
||||
intro: Use `git push` to push commits made on your local branch to a remote repository.
|
||||
redirect_from:
|
||||
- /articles/pushing-to-a-remote/
|
||||
- /articles/pushing-commits-to-a-remote-repository
|
||||
- /github/using-git/pushing-commits-to-a-remote-repository
|
||||
- /github/getting-started-with-github/pushing-commits-to-a-remote-repository
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
The `git push` command takes two arguments:
|
||||
|
||||
* A remote name, for example, `origin`
|
||||
* A branch name, for example, `main`
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
git push <em> <REMOTENAME> <BRANCHNAME> </em>
|
||||
```
|
||||
|
||||
As an example, you usually run `git push origin main` to push your local changes
|
||||
to your online repository.
|
||||
|
||||
### Renaming branches
|
||||
|
||||
To rename a branch, you'd use the same `git push` command, but you would add
|
||||
one more argument: the name of the new branch. For example:
|
||||
|
||||
```shell
|
||||
git push <em> <REMOTENAME> <LOCALBRANCHNAME></em>:<em><REMOTEBRANCHNAME> </em>
|
||||
```
|
||||
|
||||
This pushes the `LOCALBRANCHNAME` to your `REMOTENAME`, but it is renamed to `REMOTEBRANCHNAME`.
|
||||
|
||||
### Dealing with "non-fast-forward" errors
|
||||
|
||||
If your local copy of a repository is out of sync with, or "behind," the upstream
|
||||
repository you're pushing to, you'll get a message saying `non-fast-forward updates were rejected`.
|
||||
This means that you must retrieve, or "fetch," the upstream changes, before
|
||||
you are able to push your local changes.
|
||||
|
||||
For more information on this error, see "[Dealing with non-fast-forward errors](/github/getting-started-with-github/dealing-with-non-fast-forward-errors)."
|
||||
|
||||
### Pushing tags
|
||||
|
||||
By default, and without additional parameters, `git push` sends all matching branches
|
||||
that have the same names as remote branches.
|
||||
|
||||
To push a single tag, you can issue the same command as pushing a branch:
|
||||
|
||||
```shell
|
||||
git push <em> <REMOTENAME> <TAGNAME> </em>
|
||||
```
|
||||
|
||||
To push all your tags, you can type the command:
|
||||
|
||||
```shell
|
||||
git push <em> <REMOTENAME></em> --tags
|
||||
```
|
||||
|
||||
### Deleting a remote branch or tag
|
||||
|
||||
The syntax to delete a branch is a bit arcane at first glance:
|
||||
|
||||
```shell
|
||||
git push <em> <REMOTENAME></em> :<em><BRANCHNAME> </em>
|
||||
```
|
||||
|
||||
Note that there is a space before the colon. The command resembles the same steps
|
||||
you'd take to rename a branch. However, here, you're telling Git to push _nothing_
|
||||
into `BRANCHNAME` on `REMOTENAME`. Because of this, `git push` deletes the branch
|
||||
on the remote repository.
|
||||
|
||||
### Remotes and forks
|
||||
|
||||
You might already know that [you can "fork" repositories](https://guides.github.com/overviews/forking/) on GitHub.
|
||||
|
||||
When you clone a repository you own, you provide it with a remote URL that tells
|
||||
Git where to fetch and push updates. If you want to collaborate with the original
|
||||
repository, you'd add a new remote URL, typically called `upstream`, to
|
||||
your local Git clone:
|
||||
|
||||
```shell
|
||||
git remote add upstream <em> <THEIR_REMOTE_URL> </em>
|
||||
```
|
||||
|
||||
Now, you can fetch updates and branches from *their* fork:
|
||||
|
||||
```shell
|
||||
git fetch upstream
|
||||
# Grab the upstream remote's branches
|
||||
> remote: Counting objects: 75, done.
|
||||
> remote: Compressing objects: 100% (53/53), done.
|
||||
> remote: Total 62 (delta 27), reused 44 (delta 9)
|
||||
> Unpacking objects: 100% (62/62), done.
|
||||
> From https://{% data variables.command_line.codeblock %}/<em>octocat</em>/<em>repo</em>
|
||||
> * [new branch] main -> upstream/main
|
||||
```
|
||||
|
||||
When you're done making local changes, you can push your local branch to GitHub
|
||||
and [initiate a pull request](/articles/about-pull-requests).
|
||||
|
||||
For more information on working with forks, see "[Syncing a fork](/articles/syncing-a-fork)".
|
||||
|
||||
### Further reading
|
||||
|
||||
- [The "Remotes" chapter from the "Pro Git" book](https://git-scm.com/book/ch5-2.html)
|
||||
- [`git remote` man page](https://git-scm.com/docs/git-remote.html)
|
||||
- "[Git cheatsheet](/articles/git-cheatsheet)"
|
||||
- "[Git workflows](/github/getting-started-with-github/git-workflows)"
|
||||
- "[Git Handbook](https://guides.github.com/introduction/git-handbook/)"
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Resolving merge conflicts after a Git rebase
|
||||
intro: 'When you perform a `git rebase` operation, you''re typically moving commits around. Because of this, you might get into a situation where a merge conflict is introduced. That means that two of your commits modified the same line in the same file, and Git doesn''t know which change to apply.'
|
||||
redirect_from:
|
||||
- /articles/resolving-merge-conflicts-after-a-git-rebase
|
||||
- /github/using-git/resolving-merge-conflicts-after-a-git-rebase
|
||||
- /github/getting-started-with-github/resolving-merge-conflicts-after-a-git-rebase
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
After you reorder and manipulate commits using `git rebase`, should a merge conflict occur, Git will tell you so with the following message printed to the terminal:
|
||||
|
||||
```shell
|
||||
error: could not apply fa39187... something to add to patch A
|
||||
|
||||
When you have resolved this problem, run "git rebase --continue".
|
||||
If you prefer to skip this patch, run "git rebase --skip" instead.
|
||||
To check out the original branch and stop rebasing, run "git rebase --abort".
|
||||
Could not apply fa39187f3c3dfd2ab5faa38ac01cf3de7ce2e841... Change fake file
|
||||
```
|
||||
|
||||
Here, Git is telling you which commit is causing the conflict (`fa39187`). You're given three choices:
|
||||
|
||||
* You can run `git rebase --abort` to completely undo the rebase. Git will return you to your branch's state as it was before `git rebase` was called.
|
||||
* You can run `git rebase --skip` to completely skip the commit. That means that none of the changes introduced by the problematic commit will be included. It is very rare that you would choose this option.
|
||||
* You can fix the conflict.
|
||||
|
||||
To fix the conflict, you can follow [the standard procedures for resolving merge conflicts from the command line](/articles/resolving-a-merge-conflict-using-the-command-line). When you're finished, you'll need to call `git rebase --continue` in order for Git to continue processing the rest of the rebase.
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: Splitting a subfolder out into a new repository
|
||||
redirect_from:
|
||||
- /articles/splitting-a-subpath-out-into-a-new-repository/
|
||||
- /articles/splitting-a-subfolder-out-into-a-new-repository
|
||||
- /github/using-git/splitting-a-subfolder-out-into-a-new-repository
|
||||
- /github/getting-started-with-github/splitting-a-subfolder-out-into-a-new-repository
|
||||
intro: You can turn a folder within a Git repository into a brand new repository.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
If you create a new clone of the repository, you won't lose any of your Git history or changes when you split a folder into a separate repository.
|
||||
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Change the current working directory to the location where you want to create your new repository.
|
||||
3. Clone the repository that contains the subfolder.
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/<em>USERNAME</em>/<em>REPOSITORY-NAME</em>
|
||||
```
|
||||
4. Change the current working directory to your cloned repository.
|
||||
```shell
|
||||
$ cd <em>REPOSITORY-NAME</em>
|
||||
```
|
||||
5. To filter out the subfolder from the rest of the files in the repository, run [`git filter-branch`](https://git-scm.com/docs/git-filter-branch), supplying this information:
|
||||
- `FOLDER-NAME`: The folder within your project that you'd like to create a separate repository from.
|
||||
|
||||
{% windows %}
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** Windows users should use `/` to delimit folders.
|
||||
|
||||
{% endtip %}
|
||||
|
||||
{% endwindows %}
|
||||
- `BRANCH-NAME`: The default branch for your current project, for example, `main` or `gh-pages`.
|
||||
```shell
|
||||
$ git filter-branch --prune-empty --subdirectory-filter <em>FOLDER-NAME BRANCH-NAME</em>
|
||||
# Filter the specified branch in your directory and remove empty commits
|
||||
> Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)
|
||||
> Ref 'refs/heads/<em>BRANCH-NAME</em>' was rewritten
|
||||
```
|
||||
The repository should now only contain the files that were in your subfolder.
|
||||
|
||||
6. [Create a new repository](/articles/creating-a-new-repository/) on {% data variables.product.product_name %}.
|
||||
7. At the top of your new {% data variables.product.product_name %} repository's Quick Setup page, click {% octicon "clippy" aria-label="The copy to clipboard icon" %} to copy the remote repository URL.
|
||||
|
||||
|
||||
{% tip %}
|
||||
|
||||
**Tip:** For information on the difference between HTTPS and SSH URLs, see "[About remote repositories](/github/getting-started-with-github/about-remote-repositories)."
|
||||
|
||||
{% endtip %}
|
||||
|
||||
8. Check the existing remote name for your repository. For example, `origin` or `upstream` are two common choices.
|
||||
```shell
|
||||
$ git remote -v
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>USERNAME/REPOSITORY-NAME</em>.git (fetch)
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>USERNAME/REPOSITORY-NAME</em>.git (push)
|
||||
```
|
||||
|
||||
9. Set up a new remote URL for your new repository using the existing remote name and the remote repository URL you copied in step 7.
|
||||
```shell
|
||||
git remote set-url origin https://{% data variables.command_line.codeblock %}/<em>USERNAME/NEW-REPOSITORY-NAME</em>.git
|
||||
```
|
||||
10. Verify that the remote URL has changed with your new repository name.
|
||||
```shell
|
||||
$ git remote -v
|
||||
# Verify new remote URL
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>USERNAME/NEW-REPOSITORY-NAME</em>.git (fetch)
|
||||
> origin https://{% data variables.command_line.codeblock %}/<em>USERNAME/NEW-REPOSITORY-NAME</em>.git (push)
|
||||
```
|
||||
11. Push your changes to the new repository on {% data variables.product.product_name %}.
|
||||
```shell
|
||||
git push -u origin <em>BRANCH-NAME</em>
|
||||
```
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: Using Git rebase on the command line
|
||||
redirect_from:
|
||||
- /articles/using-git-rebase/
|
||||
- /articles/using-git-rebase-on-the-command-line
|
||||
- /github/using-git/using-git-rebase-on-the-command-line
|
||||
- /github/getting-started-with-github/using-git-rebase-on-the-command-line
|
||||
intro: Here's a short tutorial on using `git rebase` on the command line.
|
||||
versions:
|
||||
free-pro-team: '*'
|
||||
enterprise-server: '*'
|
||||
github-ae: '*'
|
||||
---
|
||||
### Using Git rebase
|
||||
|
||||
In this example, we will cover all of the `git rebase` commands available, except for `exec`.
|
||||
|
||||
We'll start our rebase by entering `git rebase --interactive HEAD~7` on the terminal. Our favorite text editor will display the following lines:
|
||||
|
||||
```
|
||||
pick 1fc6c95 Patch A
|
||||
pick 6b2481b Patch B
|
||||
pick dd1475d something I want to split
|
||||
pick c619268 A fix for Patch B
|
||||
pick fa39187 something to add to patch A
|
||||
pick 4ca2acc i cant' typ goods
|
||||
pick 7b36971 something to move before patch B
|
||||
```
|
||||
|
||||
In this example, we're going to:
|
||||
|
||||
* Squash the fifth commit (`fa39187`) into the `"Patch A"` commit (`1fc6c95`), using `squash`.
|
||||
* Move the last commit (`7b36971`) up before the `"Patch B"` commit (`6b2481b`), and keep it as `pick`.
|
||||
* Merge the `"A fix for Patch B"` commit (`c619268`) into the `"Patch B"` commit (`6b2481b`), and disregard the commit message using `fixup`.
|
||||
* Split the third commit (`dd1475d`) into two smaller commits, using `edit`.
|
||||
* Fix the commit message of the misspelled commit (`4ca2acc`), using `reword`.
|
||||
|
||||
Phew! This sounds like a lot of work, but by taking it one step at a time, we can easily make those changes.
|
||||
|
||||
To start, we'll need to modify the commands in the file to look like this:
|
||||
|
||||
```
|
||||
pick 1fc6c95 Patch A
|
||||
squash fa39187 something to add to patch A
|
||||
pick 7b36971 something to move before patch B
|
||||
pick 6b2481b Patch B
|
||||
fixup c619268 A fix for Patch B
|
||||
edit dd1475d something I want to split
|
||||
reword 4ca2acc i cant' typ goods
|
||||
```
|
||||
|
||||
We've changed each line's command from `pick` to the command we're interested in.
|
||||
|
||||
Now, save and close the editor; this will start the interactive rebase.
|
||||
|
||||
Git skips the first rebase command, `pick 1fc6c95`, since it doesn't need to do anything. It goes to the next command, `squash fa39187`. Since this operation requires your input, Git opens your text editor once again. The file it opens up looks something like this:
|
||||
|
||||
```
|
||||
# This is a combination of two commits.
|
||||
# The first commit's message is:
|
||||
|
||||
Patch A
|
||||
|
||||
# This is the 2nd commit message:
|
||||
|
||||
something to add to patch A
|
||||
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# Not currently on any branch.
|
||||
# Changes to be committed:
|
||||
# (use "git reset HEAD <file>..." to unstage)
|
||||
#
|
||||
# modified: a
|
||||
#
|
||||
```
|
||||
|
||||
This file is Git's way of saying, "Hey, here's what I'm about to do with this `squash`." It lists the first commit's message (`"Patch A"`), and the second commit's message (`"something to add to patch A"`). If you're happy with these commit messages, you can save the file, and close the editor. Otherwise, you have the option of changing the commit message by simply changing the text.
|
||||
|
||||
When the editor is closed, the rebase continues:
|
||||
|
||||
```
|
||||
pick 1fc6c95 Patch A
|
||||
squash fa39187 something to add to patch A
|
||||
pick 7b36971 something to move before patch B
|
||||
pick 6b2481b Patch B
|
||||
fixup c619268 A fix for Patch B
|
||||
edit dd1475d something I want to split
|
||||
reword 4ca2acc i cant' typ goods
|
||||
```
|
||||
|
||||
Git processes the two `pick` commands (for `pick 7b36971` and `pick 6b2481b`). It *also* processes the `fixup` command (`fixup c619268`), since it doesn't require any interaction. `fixup` merges the changes from `c619268` into the commit before it, `6b2481b`. Both changes will have the same commit message: `"Patch B"`.
|
||||
|
||||
Git gets to the `edit dd1475d` operation, stops, and prints the following message to the terminal:
|
||||
|
||||
```shell
|
||||
You can amend the commit now, with
|
||||
|
||||
git commit --amend
|
||||
|
||||
Once you are satisfied with your changes, run
|
||||
|
||||
git rebase --continue
|
||||
```
|
||||
|
||||
At this point, you can edit any of the files in your project to make any additional changes. For each change you make, you'll need to perform a new commit, and you can do that by entering the `git commit --amend` command. When you're finished making all your changes, you can run `git rebase --continue`.
|
||||
|
||||
Git then gets to the `reword 4ca2acc` command. It opens up your text editor one more time, and presents the following information:
|
||||
|
||||
```
|
||||
i cant' typ goods
|
||||
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# Not currently on any branch.
|
||||
# Changes to be committed:
|
||||
# (use "git reset HEAD^1 <file>..." to unstage)
|
||||
#
|
||||
# modified: a
|
||||
#
|
||||
```
|
||||
|
||||
As before, Git is showing the commit message for you to edit. You can change the text (`"i cant' typ goods"`), save the file, and close the editor. Git will finish the rebase and return you to the terminal.
|
||||
|
||||
### Pushing rebased code to GitHub
|
||||
|
||||
Since you've altered Git history, the usual `git push origin` **will not** work. You'll need to modify the command by "force-pushing" your latest changes:
|
||||
|
||||
```shell
|
||||
# Don't override changes
|
||||
$ git push origin main --force-with-lease
|
||||
|
||||
# Override changes
|
||||
$ git push origin main --force
|
||||
```
|
||||
|
||||
{% warning %}
|
||||
|
||||
Force pushing has serious implications because it changes the historical sequence of commits for the branch. Use it with caution, especially if your repository is being accessed by multiple people.
|
||||
|
||||
{% endwarning %}
|
||||
|
||||
### Further reading
|
||||
|
||||
* "[Resolving merge conflicts after a Git rebase](/github/getting-started-with-github/resolving-merge-conflicts-after-a-git-rebase)"
|
||||
Reference in New Issue
Block a user