Git Branches | just the twig * – clickety-clack.click

RESOURCES

Clone Specific Branch -2- Specific Folder



git fetch origin && git reset --hard origin/master && git clean -f -d



branch for yourself - you can see the branch names at: https://repositoryaddress.com/etc/-/branches

git clone -b   

git clone -b trenton-ducatti https://git.reoop.com/infostuff/site-site.git foldersmp

cd into new folder

then create a new branch

git checkout -b 

git checkout -b smpnewbranch


++++++

git remote show origin
shows remote and local branches with tracking info.

++++++++

git branch --set-upstream-to=origin/trenton-ducatti smptrentonsmlpush


git push --set-upstream origin smptrentonsmlpush

The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:trenton-ducatti

Create New Local Branch
// Example for creating a new branch named myNewBranch
```
git checkout -b myNewBranch
    
```
lock local branch to origin
git branch –set-upstream-to=origin/ORIGINbranch LOCALbranch
No CLI / COMMAND LINE TOOLS: Medium Article | sudo xcode-select --reset
- list all branches in repos
- ```
git branch -a
    
```

git add and commit

git add commit shortcut

To add all the changes you've made:

git add .

To commit them:

git commit -m "MY MESSAGE HERE" #-m is the message flag

You can put those steps together like this:

git commit -a -m "MY MESSAGE HERE"

To push your committed changes from your local repository to your remote repository:

git push origin master

You might have to type in your username/password for github after this. Here's a good primer on using git. A bit old, but it covers what's going on really well.

Show less

git reset without the –hard option resets the commit history, but not the files. With the –hard option the files in working tree are also reset. (credited user)

If you wish to commit that state so that the remote repository also points to the rolled back commit do: git push -f

The second option for me did not run: I had to do git push -f master to restore the remote repository too. However, be aware that with the -f switch the commits after the restored commit are also LOST on the remote repo! (this is what I wanted but someone else may wish to preserve history).

If you haven’t made any other changes after that, you can follow this steps:

Run git reflog. This will give you a log of the actions done by you on the repo
Pick the log just before the pull. If it is the second last commit you can run

git reset –hard HEAD@{2}

to restore your repo to a state just before you pulled your repo

If you're brand new to Git, you can learn how to start using Git on the command line. Now, without any further ado, here's how we can fix six of the most common Git mistakes.

1. Oops… I spelled that last commit message wrong

After a good few hours of coding, it's easy for a spelling error to sneak into your commit messages. Luckily, there's a simple fix.

git commit --amend

This will open up your editor and allow you to make a change to that last commit message. No one needs to know you spelled, "addded" with three "d"s.

2. Oops… I forgot to add a file to that last commit

Another common Git pitfall is committing too early. You missed a file, forgot to save it, or need to make a minor change for the last commit to make sense. --amend is your friend once again.

Add that missed file then run that trusty command.

git add missed-file.txt
git commit --amend

At this point, you can either amend the commit message or just save it to keep it the same.

3. Oops… I added a file I didn't want in the repo

But what if you do the exact opposite? What if you added a file that you didn't want to commit? A rogue ENV file, a build directory, a picture of your cat that you accidentally saved to the wrong folder? It's all fixable.

If all you did was stage the file and you haven't committed it yet, it's as simple as resetting that staged file:

git reset /assets/img/misty-and-pepper.jpg

If you've gone as far as committing that change, you need to run an extra step before:

git reset --soft HEAD~1
git reset /assets/img/misty-and-pepper.jpg
rm /assets/img/misty-and-pepper.jpg
git commit

This will undo the commit, remove the image, then add a new commit in its place.

4. Oops… I committed all those changes to the master branch

So you're working on a new feature and in your haste, you forgot to open a new branch for it. You've already committed a load of files and now them commits are all sitting on the master branch. Luckily, GitLab can prevent you from pushing directly to master. So we can roll back all these changes to a new branch with the following three commands:

Note: Make sure you commit or stash your changes first, or all will be lost!

git branch future-brunch
git reset HEAD~ --hard
git checkout future-brunch

This creates a new branch, then rolls back the master branch to where it was before you made changes, before finally checking out your new branch with all your previous changes intact.

5. Oops… I made a spelling mistake in my branch name

The keen-eyed among you will notice a slight spelling error in my last example. It's almost 3:00 PM and I haven't had lunch yet, so in my hunger, I've named our new branch future-brunch. Delicious.

We rename this branch in a similar way to how we rename a file with the mv command: by moving it to a new location with the correct name.

git branch -m future-brunch feature-branch

If you've already pushed this branch, there are a couple of extra steps required. We need to delete the old branch from the remote and push up the new one:

git push origin --delete future-brunch
git push origin feature-branch

6. Oops… I did it again

This command is for when everything has gone wrong. When you've copy-pasted one too many solutions from Stack Overflow and your repo is in a worse state than it was when you started. We've all been there.

git reflog shows you a list of all the things you've done. It then allows you to use Git's magical time-traveling skills to go back to any point in the past. I should note, this is a last resort thing and should not be used lightly. To get this list, type:

git reflog

Every step we took, every move we made, Git was watching us. Running that on our project gives us this:

3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch
3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch
2b7e508 (master) HEAD@{3}: reset: moving to HEAD~
3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo
2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1
37a632d HEAD@{6}: commit: Adds the client logo to the project
2b7e508 (master) HEAD@{7}: reset: moving to HEAD
2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site
dfa27a2 HEAD@{9}: reset: moving to HEAD
dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site
700d0b5 HEAD@{11}: commit: Addded contributing info to the site
efba795 HEAD@{12}: commit (initial): Initial commit

Take note of the left-most column, as this is the index. If you want to go back to any point in the history, run the below command, replacing {index} with that reference, e.g. dfa27a2.

git reset HEAD@{index}

So there you have six ways to get out of the most common Gitfalls.

fix mistakes

Show less

https://docs.gitlab.com/13.12/ee/topics/git/numerous_undo_possibilities_in_git/

Undo possibilities in Git ALL TIERS

Nothing in Git is deleted, so when you work in Git, you can undo your work.

All version control systems have options for undoing work. However, because of the de-centralized nature of Git, these options are multiplied. The actions you take are based on the stage of development you are in.

For more information about working with Git and GitLab:

Learn why North Western Mutual chose GitLab for their enterprise source code management.
Learn how to get started with Git.
For more advanced examples, refer to the Git book.

When you can undo changes

In the standard Git workflow:

You create or edit a file. It starts in the unstaged state. If it’s new, it is not yet tracked by Git.
You add the file to your local repository (git add), which puts the file into the staged state.
You commit the file to your local repository (git commit).
You can then share the file with other developers, by committing to a remote repository (git push).

You can undo changes at any point in this workflow:

When you’re working locally and haven’t yet pushed to a remote repository.
When you have already pushed to a remote repository and you want to:
- Keep the history intact (preferred).
- Change the history (requires coordination with team and force pushes).

Undo local changes

Until you push your changes to a remote repository, changes you make in Git are only in your local development environment.

Undo unstaged local changes

When you make a change, but have not yet staged it, you can undo your work.

Confirm that the file is unstaged (that you did not use git add <file>) by running git status:

$ git status
On branch main
Your branch is up-to-date with 'origin/main'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   <file>
no changes added to commit (use "git add" and/or "git commit -a")

Choose an option and undo your changes:
- To overwrite local changes:
```
git checkout -- <file>
```
- To save local changes so you can re-use them later:
```
git stash
```
- To discard local changes to all files, permanently:
```
git reset --hard
```

Undo staged local changes

If you added a file to staging, you can undo it.

Confirm that the file is staged (that you used git add <file>) by running git status:

$ git status
On branch main
Your branch is up-to-date with 'origin/main'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

  new file:   <file>

Choose an option and undo your changes:
- To unstage the file but keep your changes:
```
git restore --staged <file>
```
- To unstage everything but keep your changes:
```
git reset
```
- To unstage the file to current commit (HEAD):
```
git reset HEAD <file>
```
- To discard all local changes, but save them for later:
```
git stash
```
- To discard everything permanently:
```
git reset --hard
```

Quickly save local changes

If you want to change to another branch, you can use git stash.

From the branch where you want to save your work, type git stash.
Swap to another branch (git checkout <branchname>).
Commit, push, and test.
Return to the branch where you want to resume your changes.
Use git stash list to list all previously stashed commits.
Run a version of git stash:
- Use git stash pop to redo previously stashed changes and remove them from stashed list.
- Use git stash apply to redo previously stashed changes, but keep them on stashed list.

Undo committed local changes

When you commit to your local repository (git commit), the version control system records your changes. Because you did not push to a remote repository yet, your changes are not public (or shared with other developers). At this point, you can undo your changes.

Undo staged local changes without modifying history

You can revert a commit while retaining the commit history.

This example uses five commits A,B,C,D,E, which were committed in order: A-B-C-D-E. The commit you want to undo is B.

Find the commit SHA of the commit you want to revert to. To look through a log of commits, type git log.
Choose an option and undo your changes:
- To swap additions and deletions changes introduced by commit B:
```
git revert <commit-B-SHA>
```
- To undo changes on a single file or directory from commit B, but retain them in the staged state:
```
git checkout <commit-B-SHA> <file>
```
- To undo changes on a single file or directory from commit B, but retain them in the unstaged state:
```
git reset <commit-B-SHA> <file>
```

Undo multiple committed changes

You can recover from multiple commits. For example, if you have done commits A-B-C-D on your feature branch and then realize that C and D are wrong.

To recover from multiple incorrect commits:

Check out the last correct commit. In this example, B.
```
git checkout <commit-B-SHA>
```
Create a new branch.
```
git checkout -b new-path-of-feature
```
Add, push, and commit your changes.

The commits are now A-B-C-D-E.

Alternatively, with GitLab, you can cherry-pick that commit into a new merge request.

Another solution is to reset to B and commit E. However, this solution results in A-B-E, which clashes with what other developers have locally.

Undo staged local changes with history modification

You can rewrite history in Git, but you should avoid it, because it can cause problems when multiple developers are contributing to the same codebase.

There is one command for history modification and that is git rebase. Command provides interactive mode (-i flag) which enables you to:

reword commit messages (there is also git commit --amend for editing last commit message).
edit the commit content (changes introduced by commit) and message.
squash multiple commits into a single one, and have a custom or aggregated commit message.
drop commits – delete them.
and few more options.

Let us check few examples. Again there are commits A-B-C-D where you want to delete commit B.

Rebase the range from current commit D to A:
```
git rebase -i A
```
Command opens your favorite editor where you write drop in front of commit B, but you leave default pick with all other commits. Save and exit the editor to perform a rebase. Remember: if you want to cancel delete whole file content before saving and exiting the editor

In case you want to modify something introduced in commit B.

Rebase the range from current commit D to A:
```
git rebase -i A
```
Command opens your favorite text editor where you write edit in front of commit B, but leave default pick with all other commits. Save and exit the editor to perform a rebase.
Now do your edits and commit changes:
```
git commit -a
```

You can find some more examples in the section explaining how to modify history.

Redoing the undo

Sometimes you realize that the changes you undid were useful and you want them back. Well because of first paragraph you are in luck. Command git reflog enables you to recall detached local commits by referencing or applying them via commit ID. Although, do not expect to see really old commits in reflog, because Git regularly cleans the commits which are unreachable by branches or tags.

To view repository history and to track older commits you can use below command:

$ git reflog show

# Example output:
b673187 HEAD@{4}: merge 6e43d5987921bde189640cc1e37661f7f75c9c0b: Merge made by the 'recursive' strategy.
eb37e74 HEAD@{5}: rebase -i (finish): returning to refs/heads/master
eb37e74 HEAD@{6}: rebase -i (pick): Commit C
97436c6 HEAD@{7}: rebase -i (start): checkout 97436c6eec6396c63856c19b6a96372705b08b1b
...
88f1867 HEAD@{12}: commit: Commit D
97436c6 HEAD@{13}: checkout: moving from 97436c6eec6396c63856c19b6a96372705b08b1b to test
97436c6 HEAD@{14}: checkout: moving from master to 97436c6
05cc326 HEAD@{15}: commit: Commit C
6e43d59 HEAD@{16}: commit: Commit B

Output of command shows repository history. In first column there is commit ID, in following column, number next to HEAD indicates how many commits ago something was made, after that indicator of action that was made (commit, rebase, merge, …) and then on end description of that action.

Undo remote changes without changing history

This topic is roughly same as modifying committed local changes without modifying history. It should be the preferred way of undoing changes on any remote repository or public branch. Keep in mind that branching is the best solution when you want to retain the history of faulty development, yet start anew from certain point.

Branching enables you to include the existing changes in new development (by merging) and it also provides a clear timeline and development structure.

[Gbuy id=’147669′]

If you want to revert changes introduced in certain commit-id, you can revert that commit-id (swap additions and deletions) in newly created commit: You can do this with

git revert commit-id

or creating a new branch:

git checkout commit-id
git checkout -b new-path-of-feature

Undo remote changes with modifying history

This is useful when you want to hide certain things – like secret keys, passwords, and SSH keys. It is and should not be used to hide mistakes, as it makes it harder to debug in case there are some other bugs. The main reason for this is that you loose the real development progress. Keep in mind that, even with modified history, commits are just detached and can still be accessed through commit ID – at least until all repositories perform the automated cleanup of detached commits.

Modifying history causes problems on remote branch

[Gbuy id=’147670′]

Where modifying history is generally acceptable

Modified history breaks the development chain of other developers, as changed history does not have matching commit IDs. For that reason it should not be used on any public branch or on branch that might be used by other developers. When contributing to big open source repositories (for example, GitLab itself), it is acceptable to squash commits into a single one, to present a nicer history of your contribution.

Keep in mind that this also removes the comments attached to certain commits in merge requests, so if you need to retain traceability in GitLab, then modifying history is not acceptable.

A feature branch of a merge request is a public branch and might be used by other developers, but project process and rules might allow or require you to use git rebase (command that changes history) to reduce number of displayed commits on target branch after reviews are done (for example GitLab). There is a git merge --squash command which does exactly that (squashes commits on feature-branch to a single commit on target branch at merge).

Never modify the commit history of master or shared branch.

How modifying history is done

After you know what you want to modify (how far in history or how which range of old commits), use git rebase -i commit-id. This command displays all the commits from current version to chosen commit ID and allow modification, squashing, deletion of that commits.

$ git rebase -i commit1-id..commit3-id
pick <commit1-id> <commit1-commit-message>
pick <commit2-id> <commit2-commit-message>
pick <commit3-id> <commit3-commit-message>

# Rebase commit1-id..commit3-id onto <commit4-id> (3 command(s))
#
# 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
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

The comment from the output clearly states that, if you decide to abort, don’t just close your editor (as that modifies history), but remove all uncommented lines and save.

Use git rebase carefully on shared and remote branches, but rest assured: nothing is broken until you push back to the remote repository (so you can freely explore the different outcomes locally).

# Modify history from commit-id to HEAD (current commit)
git rebase -i commit-id

Deleting sensitive information from commits

Git also enables you to delete sensitive information from your past commits and it does modify history in the progress. That is why we have included it in this section and not as a standalone topic. To do so, you should run the git filter-branch, which enables you to rewrite history with certain filters. This command uses rebase to modify history and if you want to remove certain file from history altogether use:

git filter-branch --tree-filter 'rm filename' HEAD

Because git filter-branch command might be slow on big repositories, there are tools that can use some of Git specifics to enable faster execution of common tasks (which is exactly what removing sensitive information file is about). An alternative is the open source community-maintained tool BFG. Keep in mind that these tools are faster because they do not provide the same feature set as git filter-branch does, but focus on specific use cases.

Refer Reduce repository size page to know more about purging files from repository history & GitLab storage.

Set upstream branch for an existing remote branch

In some cases, you may choose to link your local branches to existing remote branches that you just pulled or cloned from the main repository.

Let’s say for example that you pulled the “dev” branch located on the “origin” remote.

As a consequence, the tracking branch is named “origin/dev”.

Set tracking branches for new local branches

In order to switch to the local “dev” branch, and to set the “origin/dev” as the tracking branch (or upstream branch), use the “–track” option.

$ git checkout --track origin/dev

Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'dev'

To verify that you linked dev to the tracking branch “origin/dev” (which upstream branch is the remote dev), use the “git branch” command.

$ git branch -vv
* dev 808b598 [origin/dev] Initial commit

Set tracking branches for existing local branches

On the other hand, you may have chosen to work on a local branch and to set the upstream branch (or the remote tracking branch later on).

It is perfectly fine, but you will have to use the “git branch” in order to set the existing branch upstream branch.

$ git branch -u <remote>/<branch>

Let’s take the example of the “feature” branch that you just created to start working.

$ git checkout -b feature
Switched to a new branch 'feature'

You created some commits in your branch, you want to set the tracking branch to be master.

$ git branch -u origin/master
Branch 'feature' set up to track remote branch 'master' from 'origin'.

Great! You successfully set the upstream branch for your existing local branch.

Why are upstream branches so useful in Git?

Upstream branches are useful because :

You get references to your remote repositories and you essentially know if you are ahead of them or not.

When performing a “git fetch” command, you can bring the new commits from your remote repository and you can choose to merge them at will.

You can perform pull and push easily

When you set your upstream (or tracking) branches, you can simply execute pulls and pushes without having to specify the target branch.

Git automatically knows that it has to fetch the new commits to the remote tracking branch. Similarly, Git already knows that it has to push new commits to the upstream branch.

But where does Git keep a reference of the upstream branches associated with local branches?

Git keeps references to upstream branches via its config file in the “.git” directory.

Inspecting tracking branches configuration

In order to inspect your current Git configuration, list the hidden files and directories in your current working Git directory.

$ ls -al

total 16
drwxrwxr-x 3 schkn schkn 4096 Nov  5 16:10 .
drwxrwxr-x 7 schkn schkn 4096 Nov  5 16:10 ..
drwxrwxr-x 8 schkn schkn 4096 Nov  6 10:27 .git

Now, inspect the content of the “config” file located in the .git directory.

$ cat .git/config

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = <repo_url>
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

As you can see, Git keeps a reference between your local branch, the name of the remote and the branch it has to merge with.

Setting your branch to exactly match the remote branch can be done in two steps:

git fetch origin
git reset --hard origin/master

Update @2020 (if you have main branch instead of master in remote repo)

git fetch origin
git reset --hard origin/main

If you want to save your current branch's state before doing this (just in case), you can do:

git commit -a -m "Saving my work, just in case"
git branch my-saved-work

Now your work is saved on the branch "my-saved-work" in case you decide you want it back (or want to look at it later or diff it against your updated branch).

Note that the first example assumes that the remote repo's name is "origin" and that the branch named "master" in the remote repo matches the currently checked-out branch in your local repo.

BTW, this situation that you're in looks an awful lot like a common case where a push has been done into the currently checked out branch of a non-bare repository. Did you recently push into your local repo? If not, then no worries — something else must have caused these files to unexpectedly end up modified. Otherwise, you should be aware that it's not recommended to push into a non-bare repository (and not into the currently checked-out branch, in particular).

How to Clone a Single Branch in Git

https://www.w3docs.com/snippets/git/how-to-clone-a-single-branch-in-git.html

Cloning a Single Branch Using git remote add
Cloning a Single Branch Using git clone
The git branch Command
The git init Command
The git remote Command
The git checkout Command

Sometimes it is necessary to clone a single and specific branch. Let’s take a look at different approaches and take the steps to get the job done!

Watch a video course Git & GitHub – The Practical Guide

Cloning a Single Branch Using git remote add¶

Creating a new repository¶

The first step should be creating a new repository with git init:

git init

Adding the remote and fetching the branch¶

The second step is to add a remote named origin for the given repository, which will fetch the given branch from origin:

git remote add -t <branch-name> -f origin <remote-repo-url>

Checkout to the given branch¶

The third step is to checkout to that branch with the git checkout command for creating a corresponding local branch:

git checkout <branch-name>

Cloning a Single Branch Using git clone¶

The classic git clone command with the –single-branch option will clone only the master branch by default. If you want to clone another branch, you should add the –branch flag with the name of the desired branch.

git clone --single-branch --branch <branch-name> <remote-repo-url>

The git branch Command¶

Git branches should be an important part of your daily working process.

The branching feature is available in most of the version control systems. It is used to create, delete or list branches. Branches act as an isolated development line. They represent a way of requesting a new working directory, project history, and staging area. When you develop isolated development lines for 2 features, it will allow working on them on parallel making the master branch free of uncertain codes.

The git init Command¶

This command is aimed at creating a new, not filled repository or reinitializing an existing git repository. Using this command you create a .git subdirectory. The subdirectory includes metadata.

Git init is a super-easy way of creating version-controlled projects. You just need to cd into the subdirectory of your project, then run the git init command. In this way, you’ll have a fully functional git repository.

The git remote Command¶

This command is used to create, view and remove connections to other git repositories. The connections of git remote are bookmarks in other repositories. They represent convenient naming used for referencing a not-so-convenient URL.

The git checkout Command¶

You can use this command for switching branches or restoring working tree files. It can be run on branches, commits, and files. It works along with the git branch command. Git checkout is aimed at updating files in the working directory to match the version which is stored in the branch. It tells Git to record all the new commits.

more branch clone

Show less

Force – Remote / Local Matching

Setting your branch to exactly match the remote branch can be done in two steps:

git fetch origin
git reset --hard origin/master

Update @2020 (if you have main branch instead of master in remote repo)

git fetch origin
git reset --hard origin/main

If you want to save your current branch's state before doing this (just in case), you can do:

git commit -a -m "Saving my work, just in case"
git branch my-saved-work

Now your work is saved on the branch "my-saved-work" in case you decide you want it back (or want to look at it later or diff it against your updated branch).

Note that the first example assumes that the remote repo's name is "origin" and that the branch named "master" in the remote repo matches the currently checked-out branch in your local repo.

git push


# If its your first push
git push -u origin BRANCH

# Otherwise
git push origin BRANCH

git new branch push to remoteShell/Bash


git push -u origin 
Source:stackoverflow.com

Image result for git push repo

In order to push a Git branch to remote, you need to execute the “git push” command and specify the remote as well as the branch name to be pushed. If you are not already on the branch that you want to push, you can execute the “git checkout” command to switch to your branch.

git pull

Trenton branch

git pull origin trenton-ducatti

To set it up so that it does this by default while you’re on the dev branch:
git branch –set-upstream-to trenton-ducatti origin/trenton-ducatti

See the git-pull man page: https://clickety-clack.click/img/git-pull.html

EXAMPLES

Update the remote-tracking branches for the repository you cloned from, then merge one of them into your current branch:
```
$ git pull
$ git pull origin
```
Normally the branch merged in is the HEAD of the remote repository, but the choice is determined by the branch..remote and branch..merge options; see git-config(1) for details.
Merge into the current branch the remote branch next:
```
$ git pull origin next
```
This leaves a copy of next temporarily in FETCH_HEAD, and updates the remote-tracking branch origin/next. The same can be done by invoking fetch and merge:
```
$ git fetch origin
$ git merge origin/next
```

Hard Reset – allow origin to overwrite local

Important: If you have any local changes, they will be lost. With or without `--hard` option, any local commits that haven't been pushed will be lost.[*]

If you have any files that are not tracked by Git (e.g. uploaded user content), these files will not be affected.

First, run a fetch to update all origin/<branch> refs to latest:

git fetch --all

Backup your current branch:

git branch backup-master

Then, you have two options:

git reset --hard origin/master

OR If you are on some other branch:

git reset --hard origin/<branch_name>

Explanation:

git fetch downloads the latest from remote without trying to merge or rebase anything.

Then the git reset resets the master branch to what you just fetched. The --hard option changes all the files in your working tree to match the files in origin/master

Maintain current local commits

[*]: It's worth noting that it is possible to maintain current local commits by creating a branch from master before resetting:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

After this, all of the old commits will be kept in new-branch-to-save-current-commits.

Uncommitted changes

Uncommitted changes, however (even staged), will be lost. Make sure to stash and commit anything you need. For that you can run the following:

git stash

And then to reapply these uncommitted changes:

git stash pop

If you tried a pull which resulted in complex conflicts and would want to start over, you can recover with git reset.

git pull [options] [<repository> [<refspec>...]]

and in the examples section:

Merge into the current branch the remote branch next:
$ git pull origin next

So I imagine you want to do something like:

git pull origin dev

To set it up so that it does this by default while you're on the dev branch:

git branch --set-upstream-to dev origin/dev

Update: Using Git Switch

All of the information written below was accurate, but a new command, has been added that simplifies the effort.

If daves_branch exists on the remote repository, but not on your local branch, you can simply type:

git switch daves_branch

Since you do not have the branch locally, this will automatically make switch look on the remote repo. It will then also automatically set up remote branch tracking.

Note that if daves_branch doesn't exist locally you'll need to git fetch first before using switch.

Original Post

You need to create a local branch that tracks a remote branch. The following command will create a local branch named daves_branch, tracking the remote branch origin/daves_branch. When you push your changes the remote branch will be updated.

For most recent versions of Git:

git checkout --track origin/daves_branch

--track is shorthand for git checkout -b [branch] [remotename]/[branch] where [remotename] is origin in this case and [branch] is twice the same, daves_branch in this case.

For Git 1.5.6.5 you needed this:

git checkout --track -b daves_branch origin/daves_branch

For Git 1.7.2.3 and higher, this is enough (it might have started earlier, but this is the earliest confirmation I could find quickly):

git checkout daves_branch

Note that with recent Git versions, this command will not create a local branch and will put you in a 'detached HEAD' state. If you want a local branch, use the --track option.

Full details are here: 3.5 Git Branching – Remote Branches, Tracking Branches

more git pull

Show less

How to Clone a Single Branch in Git

https://www.w3docs.com/snippets/git/how-to-clone-a-single-branch-in-git.html

Cloning a Single Branch Using git remote add
Cloning a Single Branch Using git clone
The git branch Command
The git init Command
The git remote Command
The git checkout Command

Sometimes it is necessary to clone a single and specific branch. Let’s take a look at different approaches and take the steps to get the job done!

Watch a video course Git & GitHub – The Practical Guide

Cloning a Single Branch Using git remote add¶

Creating a new repository¶

The first step should be creating a new repository with git init:

git init

Adding the remote and fetching the branch¶

The second step is to add a remote named origin for the given repository, which will fetch the given branch from origin:

git remote add -t <branch-name> -f origin <remote-repo-url>

Checkout to the given branch¶

The third step is to checkout to that branch with the git checkout command for creating a corresponding local branch:

git checkout <branch-name>

Cloning a Single Branch Using git clone¶

git clone --single-branch --branch <branch-name> <remote-repo-url>

The git branch Command¶

Git branches should be an important part of your daily working process.

The git init Command¶

This command is aimed at creating a new, not filled repository or reinitializing an existing git repository. Using this command you create a .git subdirectory. The subdirectory includes metadata.

The git remote Command¶

The git checkout Command¶

more branch clone

Show less

Cloning / BranchesBranches - OverviewHARD^ Soft Revert

Introduction to Git Clone

Git allows you to manage and version your project(s) in a "repository". This repository is stored on a web-based hosting service for version control, like GitHub.

You can then clone this repository to your local machine and have all the files and branches locally (I'll explain more about branches soon).

For example, you can clone freeCodeCamp's repository with SSH like so:

git clone git@github.com:freeCodeCamp/freeCodeCamp.git

Introduction to Git Branches

When working on a project, you will likely have different features. And multiple contributors will be working on this project and its features.

Branches allow you to create a "playground" with the same files in the master branch. You can use this branch to build independent features, test new features, make breaking changes, create fixes, write docs or try out ideas without breaking or affecting the production code. When you're done, you merge the branch into the production master branch.

Branching is a core concept in Git which is also used in GitHub to manage workflows of different versions of one project. The master branch is always the default branch in a repository that is most often considered "production and deployable code". New branches like passwordless-auth or refactor-signup-ux can be created from the master branch.

All branches in freeCodeCamp's repository

How to Clone Git Branches

While you can clone repositories with the git clone command, keep in mind that this clones the branch and the remote HEAD. This is usually master by default and includes all other branches in the repository.

So when you clone a repository, you clone the master and all other branches. This means you will have to checkout another branch yourself.

Let's say your task on a project is to work on a feature to add passwordless authentication to a user dashboard. And this feature is in the passwordless-auth branch.

You really don't need the master branch since your "feature branch" will be merged into master afterward. How then do you clone this passwordless-auth branch without fetching all other branches with "a bunch of files you don't need"?

I created this sample repository to explain this. This repository holds a simple blog built with Nextjs and has four dummy branches:

master
dev
staging
passwordless-auth

In Nextjs, any file inside the folder pages/api is mapped to the /api/* path and will be treated as an API endpoint instead of a page. In our repository, I have created different dummy APIs in this directory to make each branch different.

The master branch holds the file pages/api/hello.js while passwordless-auth holds the file pages/api/auth.js. Each file just returns a dummy text response. See master's hello API response here (with a special message for you ?).

Let's clone the repository:

git clone git@github.com:BolajiAyodeji/nextjs-blog.git

This gives us access to all branches in this repository and you can easily toggle between each to see each version and its files.

List all Branches in Repo

git branch -a

Wondering where the remotes/origin/.. branches came from?

When you clone a repository, you pull data from a repository on the internet or an internal server known as the remote. The word origin is an alias created by your Git to replace the remote URL (you can change or specify another alias if you want).

These remotes/origin/.. branches point you back to the origin repository you cloned from the internet so you can still perform pull/push from the origin.

So when you clone master onto your machine, remotes/origin/master is the original master branch on the internet, and master is on your local machine. So you will pull/push from and to the remotes/origin/master.

In summary Remote is the URL that points you to the repository on the internet while Origin is an alias for this remote URL.

How to Clone a Specific Branch

Now let's clone a specific branch from our demo repository. There are two ways to clone a specific branch. You can either:

Clone the repository, fetch all branches, and checkout to a specific branch immediately.
Clone the repository and fetch only a single branch.

Option One

git clone --branch <branchname> <remote-repo-url>

git clone -b <branchname> <remote-repo-url>

Here -b is just an alias for –branch

With this, you fetch all the branches in the repository, checkout to the one you specified, and the specific branch becomes the configured local branch for git push and git pull . But you still fetched all files from each branch. This might not be what you want right? ?

Let's test it:

 git clone -b passwordless-auth git@github.com:BolajiAyodeji/nextjs-blog.git

This automatically configures passwordless-auth as the local branch but still tracks other branches.

Option Two

git clone --branch <branchname> --single-branch <remote-repo-url>

git clone -b <branchname> --single-branch <remote-repo-url>

Here -b is just an alias for –branch

This performs the same action as option one, except that the --single-branch option was introduced in Git version 1.7.10 and later. It allows you to only fetch files from the specified branch without fetching other branches.

Let's test it:

git clone -b passwordless-auth --single-branch git@github.com:BolajiAyodeji/nextjs-blog.git

This automatically configures passwordless-auth as the local branch and only tracks this branch.

If you run cd pages/api you'll find the auth.js file in the passwordless-auth branch as expected from the previous setup.

Conclusion

You might be running out of internet or storage space but you need to work on a task in a specific branch. Or you might want to clone a specific branch with limited files for various reasons. Fortunately, Git provides you the flexibility to do this. Flex your muscles and try it out, there's much more "Git" to learn.

Clone branch into specific folder

https://stackoverflow.com/questions/651038/how-do-you-clone-a-git-repository-into-a-specific-folder

Option A:

git clone git@github.com:whatever folder-name

Ergo, for right here use:

git clone git@github.com:whatever .

Option B:

Move the .git folder, too. Note that the .git folder is hidden in most graphical file explorers, so be sure to show hidden files.

mv /where/it/is/right/now/* /where/I/want/it/
mv /where/it/is/right/now/.* /where/I/want/it/

The first line grabs all normal files, the second line grabs dot-files. It is also possibe to do it in one line by enabling dotglob (i.e. shopt -s dotglob) but that is probably a bad solution if you are asking the question this answer answers.

Better yet:

Keep your working copy somewhere else, and create a symbolic link. Like this:

ln -s /where/it/is/right/now /the/path/I/want/to/use

For your case this would be something like:

ln -sfn /opt/projectA/prod/public /httpdocs/public

Which easily could be changed to test if you wanted it, i.e.:

ln -sfn /opt/projectA/test/public /httpdocs/public

without moving files around. Added -fn in case someone is copying these lines (-f is force, -n avoid some often unwanted interactions with already and non-existing links).

If you just want it to work, use Option A, if someone else is going to look at what you have done, use Option C.

Create new branch locally

// Example for creating a new branch named myNewBranch

git checkout -b myNewBranch

https://www.atlassian.com/git/tutorials/using-branches

https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud

Git Branch

This document is an in-depth review of the git branch command and a discussion of the overall Git branching model. Branching is a feature available in most modern version control systems. Branching in other VCS's can be an expensive operation in both time and disk space. In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes. This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future's history before merging it into the main branch.

The diagram above visualizes a repository with two isolated lines of development, one for a little feature, and one for a longer-running feature. By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main master branch free from questionable code.

The implementation behind Git branches is much more lightweight than other version control system models. Instead of copying files from directory to directory, Git stores a branch as a reference to a commit. In this sense, a branch represents the tip of a series of commits—it's not a container for commits. The history for a branch is extrapolated through the commit relationships.

As you read, remember that Git branches aren't like SVN branches. Whereas SVN branches are only used to capture the occasional large-scale development effort, Git branches are an integral part of your everyday workflow. The following content will expand on the internal Git branching architecture.

How it works

A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.

The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.

Common Options

git branch

List all of the branches in your repository. This is synonymous with git branch --list.

git branch <branch>

Create a new branch called ＜branch＞. This does not check out the new branch.

git branch -d <branch>

Delete the specified branch. This is a “safe” operation in that Git prevents you from deleting the branch if it has unmerged changes.

git branch -D <branch>

Force delete the specified branch, even if it has unmerged changes. This is the command to use if you want to permanently throw away all of the commits associated with a particular line of development.

git branch -m <branch>

Rename the current branch to ＜branch＞.

git branch -a

List all remote branches.

Creating Branches

It's important to understand that branches are just pointers to commits. When you create a branch, all Git needs to do is create a new pointer, it doesn’t change the repository in any other way. If you start with a repository that looks like this:

Then, you create a branch using the following command:

git branch crazy-experiment

The repository history remains unchanged. All you get is a new pointer to the current commit:

Note that this only creates the new branch. To start adding commits to it, you need to select it with git checkout, and then use the standard git add and git commit commands.

Creating remote branches

So far these examples have all demonstrated local branch operations. The git branch command also works on remote branches. In order to operate on remote branches, a remote repo must first be configured and added to the local repo config.

$ git remote add new-remote-repo https://bitbucket.com/user/repo.git
# Add remote repo to local repo config
$ git push <new-remote-repo> crazy-experiment~
# pushes the crazy-experiment branch to new-remote-repo

This command will push a copy of the local branch crazy-experiment to the remote repo ＜remote＞.

Deleting Branches

Once you’ve finished working on a branch and have merged it into the main code base, you’re free to delete the branch without losing any history:

git branch -d crazy-experiment

However, if the branch hasn’t been merged, the above command will output an error message:

error: The branch 'crazy-experiment' is not fully merged. If you are sure you want to delete it, run 'git branch -D crazy-experiment'.

This protects you from losing access to that entire line of development. If you really want to delete the branch (e.g., it’s a failed experiment), you can use the capital -D flag:

git branch -D crazy-experiment

This deletes the branch regardless of its status and without warnings, so use it judiciously.

The previous commands will delete a local copy of a branch. The branch may still exist in remote repos. To delete a remote branch execute the following.

git push origin --delete crazy-experiment

git push origin :crazy-experiment

This will push a delete signal to the remote origin repository that triggers a delete of the remote crazy-experiment branch.

Summary

In this document we discussed Git's branching behavior and the git branch command. The git branch commands primary functions are to create, list, rename and delete branches. To operate further on the resulting branches the command is commonly used with other commands like git checkout. Learn more about git checkout branch operations; such as switching branches and merging branches, on the git checkout page.

Compared to other VCSs, Git's branch operations are inexpensive and frequently used. This flexibility enables powerful Git workflow customization. For more info on Git workflows visit our extended workflow discussion pages: The
Feature Branch Workflow, GitFlow Workflow, and Forking Workflow.

Ready to try branching?

Try this interactive tutorial.

Get started now

How to git reset hard and push

When working locally, it’s not exactly clear what happens when you git reset to a previous commit and push those commits to a remote repository. So to demonstrate exactly what happens when you git reset and push, I’m first going to create an empty, remote GitHub repository named git-reset-explained. It will contain nothing but a readme.md file, an MIT licence, a .gitignore file and a single commit.

Remote repository for git reset and push.

Cloning the git-reset-explained repo

With the remote GitHub repository created, I will locally clone the repo and begin working inside of it.

/c/ git reset hard and push /
$ git clone https://github.com/cameronmcnz/git-reset-explained.git
Cloning into 'git-reset-explained'...
$ cd git*
/c/ git reset hard and push / git reset explained

Creating a local commit history

From within the cloned repo, I will create five new files, adding a new commit each time.

/c/ git reset hard and push / git reset explained
$ touch alpha.html
$ git add . & git commit -m "Local commit #1"
$ touch beta.html
$ git add . & git commit -m "Local commit #2"
$ touch charlie.html
$ git add . & git commit -m "Local commit #3"
$ touch depeche.html
$ git add . & git commit -m "Local commit #4"
$ touch enid.html
$ git add . & git commit -m "Local commit #5"

A call to the reflog shows the history of HEAD as the git commit commands were issued:

/c/ git reset hard and push / git reset explained
$ git reflog
014df6a (HEAD -> master) HEAD@{0}: commit: Local commit #5
6237772 HEAD@{1}: commit: Local commit #4
593794d HEAD@{2}: commit: Local commit #3
b1a6865 HEAD@{3}: commit: Local commit #2
8a3358e HEAD@{4}: commit: Local commit #1
d072c0a (origin/master, origin/HEAD) HEAD@{5}: clone

git reset to a previous commit

Now if I was to perform a hard git reset and shift HEAD to the third local commit, commits 4 and 5 should disappear, right? The git reset should remove those commits from my commit history and take me right back to the reset point, right? Let’s see what actually happens when we issue the command to git reset local commits.

/c/ git reset hard and push / git reset explained
$  git reset --hard 593794d
HEAD is now at 593794d Local commit #3

Now let’s see what the reflog looks like:

/c/ git reset hard and push / git reset explained
$ git reflog
593794d (HEAD -> master) HEAD@{0} reset to 593794d
014df6a HEAD@{1}: commit: Local commit #5
6237772 HEAD@{2}: commit: Local commit #4
593794d (HEAD -> master) HEAD@{3}: commit: Local commit #3
b1a6865 HEAD@{4}: commit: Local commit #2
8a3358e HEAD@{5}: commit: Local commit #1
d072c0a (origin/master, origin/HEAD) HEAD@{6} clone

git reset hard and push

As you can see from the git reflog command, commits 014df6a and 6237772 are still hanging around. When you git reset local commits, those commits don’t disappear.

Knowing Git’s propensity to store everything, this isn’t a particularly unexpected result. The real question is, what would happen if you were to git reset to a previous commit and push to a remote repository? Would the two local commits git leapfrogged over get pushed as well, or would they remain isolated locally? To find out, we simply push to the remote origin:

/c/ git reset hard and push / git reset explained
$ git push origin
Counting objects: 7, done.
To github.com/cameronmcnz/git-reset-explained.git
d072c0a..593794d master -> master

After the push, when we look at the commit history on GitHub, we notice there are only four commits, the server-side commit that created the GitHub repository, and the three local commits that we published. When the git reset and push happened, the fourth and fifth local commits were not pushed to the server, essentially deleting any history of them ever existing.

Result of a git reset hard and remote push.

git reset vs revert

So what did we learn? Well, that when we git reset to a previous commit and push to a remote repository, no trace of the undone commits are published. That’s in stark contrast to a git revert in which the revert command itself creates a new commit, and none of the past commit history is lost. So if you ever want to undo a previous commit with Git, reset is the right Git command to use, not revert.

Become a Git power user

Want to become a Git power user? Take a look at the following Git articles and tutorials
- How to do a Git clean up of branches and commits
- Learn to rebase onto master and rebase from the master branch
- Squash all Git commits on a branch down to one
- Shelve your changes with Git stash pop and apply
- Easily explain the Git vs GitHub difference
- Add a shallow git clone of depth 1 do your Jenkins jobs
- Set up a local Git server with a bare Git repo
- The Git fork command explained

GitLab merge master to branch options

There are two acceptable ways with GitLab to merge the master branch into another. Which approach a developer chooses will depend whether the branch they want master to merge into is protected or not.

If the developer wants to merge master into a branch that’s protected, they must perform a GitLab merge request.
If the developer wants to merge master into a branch that’s unprotected, the easiest approach is to do a merge and push combination on the client machine.

The remote GitLab branch to delete is name feature_fun.

Merge master into unprotected GitLab branch

In the current state of my GitLab repository, I haven’t observed many GitFlow best practices and as a result, it has left the unprotected fun_feature branch several commits behind the master. The first GitLab merge master into a branch will be into the fun_feature branch. We will perform this merge master entirely on the client side and won’t involve the GitLab GUI in the process.

The steps to merge master into any branch are:

Open a Terminal window on the client machine
Switch to the feature branch
Use git to merge master into the branch
View a directory listing to validate files from master have been moved to the feature branch
View the Git reflog to validate that a master merge commit is registered
Push the merged feature branch back to the GitLab server
View the feature branch in the GitLab web app to validate the merge from master to branch is reflected on the server

GitLab merge master commands

A developer can use the following commands to merge master into any branch in GitLab:

git checkout fun_feature
git merge master
ls
git reflog
git push origin fun_feature

GitLab master to branch merge request

In a previous GitLab tutorial, both the develop branch and the hotfix branch was merged into master. That sequence of events somewhat violates proper GitFlow rules, because those branches should’ve been merged into the release branch first. As a result, the release branch is out of sync with master. I can rectify this problem with a GitLab merge master into this branch. When the merge is complete, the release and master branch will be in sync.

Since the release branch is protected, the process is a little different. If a developer wants to merge the GitLab master into a protected branch, the proper approach is to perform a merge request. Simply log into the GitLab web app, choose the option to create a GitLab merge request, specify the master branch as the source and the protected branch as the target of the merge.

The merge request can be used to have GitLab merge master in a branch that is protected.

After the merge request is submitted, the assignee will be notified of the request the next time they log in. If the merge request is approved without conflict, the GitLab master will merge into the branch, and both the master and release branches will be in sync.

The source code and sample project used for these examples can be found on the gitlab-made-easy project page on GitLab.

How to git reset hard and push

Remote repository for git reset and push.

Cloning the git-reset-explained repo

With the remote GitHub repository created, I will locally clone the repo and begin working inside of it.

/c/ git reset hard and push /
$ git clone https://github.com/cameronmcnz/git-reset-explained.git
Cloning into 'git-reset-explained'...
$ cd git*
/c/ git reset hard and push / git reset explained

Creating a local commit history

From within the cloned repo, I will create five new files, adding a new commit each time.

/c/ git reset hard and push / git reset explained
$ touch alpha.html
$ git add . & git commit -m "Local commit #1"
$ touch beta.html
$ git add . & git commit -m "Local commit #2"
$ touch charlie.html
$ git add . & git commit -m "Local commit #3"
$ touch depeche.html
$ git add . & git commit -m "Local commit #4"
$ touch enid.html
$ git add . & git commit -m "Local commit #5"

A call to the reflog shows the history of HEAD as the git commit commands were issued:

/c/ git reset hard and push / git reset explained
$ git reflog
014df6a (HEAD -> master) HEAD@{0}: commit: Local commit #5
6237772 HEAD@{1}: commit: Local commit #4
593794d HEAD@{2}: commit: Local commit #3
b1a6865 HEAD@{3}: commit: Local commit #2
8a3358e HEAD@{4}: commit: Local commit #1
d072c0a (origin/master, origin/HEAD) HEAD@{5}: clone

git reset to a previous commit

/c/ git reset hard and push / git reset explained
$  git reset --hard 593794d
HEAD is now at 593794d Local commit #3

Now let’s see what the reflog looks like:

/c/ git reset hard and push / git reset explained
$ git reflog
593794d (HEAD -> master) HEAD@{0} reset to 593794d
014df6a HEAD@{1}: commit: Local commit #5
6237772 HEAD@{2}: commit: Local commit #4
593794d (HEAD -> master) HEAD@{3}: commit: Local commit #3
b1a6865 HEAD@{4}: commit: Local commit #2
8a3358e HEAD@{5}: commit: Local commit #1
d072c0a (origin/master, origin/HEAD) HEAD@{6} clone

git reset hard and push

As you can see from the git reflog command, commits 014df6a and 6237772 are still hanging around. When you git reset local commits, those commits don’t disappear.

/c/ git reset hard and push / git reset explained
$ git push origin
Counting objects: 7, done.
To github.com/cameronmcnz/git-reset-explained.git
d072c0a..593794d master -> master

Result of a git reset hard and remote push.

git reset vs revert

Become a Git power user

Want to become a Git power user? Take a look at the following Git articles and tutorials
- How to do a Git clean up of branches and commits
- Learn to rebase onto master and rebase from the master branch
- Squash all Git commits on a branch down to one
- Shelve your changes with Git stash pop and apply
- Easily explain the Git vs GitHub difference
- Add a shallow git clone of depth 1 do your Jenkins jobs
- Set up a local Git server with a bare Git repo
- The Git fork command explained

Rollback commits ALL TIERS

Undo Commits

Undo last commit putting everything back into the staging area:
```
git reset --soft HEAD^
```
Add files and change message with:
```
git commit --amend -m "New Message"
```
Undo last and remove changes:
```
git reset --hard HEAD^
```
Same as last one but for two commits back:
```
git reset --hard HEAD^^
```

Don’t reset after pushing

Reset Workflow

Edit file again ‘edit_this_file.rb’
Check status
Add and commit with wrong message
Check log
Amend commit
Check log
Soft reset
Check log
Pull for updates
Push changes

Commands

# Change file edit_this_file.rb
git status
git commit -am "kjkfjkg"
git log
git commit --amend -m "New comment added"
git log
git reset --soft HEAD^
git log
git pull origin master
git push origin master

Note

git revert vs git reset
Reset removes the commit while revert removes the changes but leaves the commit
Revert is safer considering we can revert a revert

# Changed file
git commit -am "bug introduced"
git revert HEAD
# New commit created reverting changes
# Now we want to re apply the reverted commit
git log # take hash from the revert commit
git revert <rev commit hash>
# reverted commit is back (new commit created again)

Undo a commit & redo

$ git commit -m "Something terribly misguided" # (0: Your Accident)
$ git reset HEAD~                              # (1)
[ edit files as necessary ]                    # (2)
$ git add .                                    # (3)
$ git commit -c ORIG_HEAD                      # (4)

This command is responsible for the undo. It will undo your last commit while leaving your working tree (the state of your files on disk) untouched. You'll need to add them again before you can commit them again).
Make corrections to working tree files.
git add anything that you want to include in your new commit.
Commit the changes, reusing the old commit message. reset copied the old head to .git/ORIG_HEAD; commit with -c ORIG_HEAD will open an editor, which initially contains the log message from the old commit and allows you to edit it. If you do not need to edit the message, you could use the -C option.

Alternatively, to edit the previous commit (or just its commit message), commit --amend will add changes within the current index to the previous commit.

To remove (not revert) a commit that has been pushed to the server, rewriting history with git push origin master --force is necessary.

RESOURCES

lock local branch to origin

git add and commit

git add commit shortcut

1. Oops… I spelled that last commit message wrong

2. Oops… I forgot to add a file to that last commit

3. Oops… I added a file I didn't want in the repo

4. Oops… I committed all those changes to the master branch

5. Oops… I made a spelling mistake in my branch name

6. Oops… I did it again

Undo possibilities in Git ALL TIERS

When you can undo changes

Undo local changes

Undo unstaged local changes

Undo staged local changes

Quickly save local changes

Undo committed local changes

Undo staged local changes without modifying history

Undo multiple committed changes

Undo staged local changes with history modification

Redoing the undo

Undo remote changes without changing history

Undo remote changes with modifying history

Where modifying history is generally acceptable

How modifying history is done

Deleting sensitive information from commits

Set upstream branch for an existing remote branch

Set tracking branches for new local branches

Set tracking branches for existing local branches

Why are upstream branches so useful in Git?

Inspecting tracking branches configuration

Setting your branch to exactly match the remote branch can be done in two steps:

How to Clone a Single Branch in Git

Cloning a Single Branch Using git remote add¶

Creating a new repository¶

Adding the remote and fetching the branch¶

Checkout to the given branch¶

Cloning a Single Branch Using git clone¶

The git branch Command¶

The git init Command¶

The git remote Command¶

The git checkout Command¶

Force – Remote / Local Matching

git push

git pull

Trenton branch

EXAMPLES

Hard Reset – allow origin to overwrite local

Important: If you have any local changes, they will be lost. With or without --hard option, any local commits that haven't been pushed will be lost.[*]

Explanation:

Maintain current local commits

Uncommitted changes

Update: Using Git Switch

Original Post

How to Clone a Single Branch in Git

Cloning a Single Branch Using git remote add¶

Creating a new repository¶

Adding the remote and fetching the branch¶

Checkout to the given branch¶

Cloning a Single Branch Using git clone¶

The git branch Command¶

The git init Command¶

The git remote Command¶

The git checkout Command¶

Introduction to Git Clone

Introduction to Git Branches

How to Clone Git Branches

List all Branches in Repo

How to Clone a Specific Branch

Option One

Option Two

Conclusion

Clone branch into specific folder

Create new branch locally

Git Branch

How it works

Common Options

Creating Branches

Creating remote branches

Deleting Branches

Important: If you have any local changes, they will be lost. With or without `--hard` option, any local commits that haven't been pushed will be lost.[*]

Image Editor - Bitmap PIXIE
Palleon | Palleon Documentation