-
Notifications
You must be signed in to change notification settings - Fork 0
LANL Git FAQ
This page will be used to house the LANL Git FAQ. Please post questions here, and eventually they will be answered.
To create a local branch, you can use any of:
git branch <new_branch_name>
git branch <new_branch_name> <branch_point>
git checkout -b <new_branch_name>
git checkout -b <new_branch_name> <branch_point>
When <branch_point> is omitted from the command, it is replaced with HEAD.
After a local branch is created, you can push it to your fork to create a branch on your fork. This is done using:
git push <remote_name> <new_branch_name>
Where <remote_name> is one of the aliases in the left most column of git remote -v and <new_branch_name> is the name of the branch you just created.
Instead, you switch branches in a local repository.
To switch branches in your local repository, you can:
git checkout <branch_name>
To figure out which remote aliases you have created, and what they point to you can use:
git remote -v
The left column is the alias name, while the right column is the URL for where the alias points to.
For example, if you only want to test a branch, or see the code but not commit to it, it is sometimes easiest to work in what is called a detached HEAD.
To 'checkout' a version of code in a detached head from someones fork you first need to:
- Add a remote for the fork:
git remote add ... - Fetch the remote history:
git fetch ...
After you have fetched the history of the fork, you can checkout their branch in one of two ways:
- Detached HEAD:
git checkout <remote_name>/<branch_name>(e.g.git checkout MPAS-Dev/MPAS/ocean/developwill checkoutocean/developfromMPAS-Dev/MPAS) - Local branch:
git checkout -b <new_branch_name> <remote_name>/<branch_name>(e.g.git checkout -b ocean/feature MPAS-Dev/MPAS/ocean/developwill make a new local branch named ocean/feature off of MPAS-Dev/MPAS/ocean/develop and check it out.
If you already have a local branch, you can simply check it out using:
git checkout <branch_name>
If you want to pull in a specific commit, you can use git cherry-pick to pull it onto your branch.
If you want to pull in a set of commits, there are two options:
- Rebasing your branch off of the commits you want to incorprate into your branch
- Merging the other branch into your branch
However, often times when you bring in changes someone else made into your branch, you'll need to remove them at a later point in time. So, keep this in mind before deciding if it's work doing in the first place.
git checkout <commit> -- <file_list>
Where <file_list> can be a list of files you want to get from the other commit. NOTE This will throw away the versions you currently have of these files. So any changes will be lost forever.
git reset --hard <new_commit>
NOTE: This changes the branch you are on (i.e. what git branch reports you as being on) to point to <new_commit> rather than whatever it points to now. Additionally, it will change all the files in your current directory to be this version as well, so any local changes will be lost.
If you want to change a branch that you are not currently on (i.e. it is not checked out) you can:
git branch -f <branch_name> <new_commit>
Which will move the branch <branch_name> to point to <new_commit> but not change anything in your local directory.
git add -i and then select 5, patch, selecting files and individual changes that should be staged for the commit.
A) Yes it is possible to undo any commit in a repository. There isn't a single "best" workflow. It all depends on context.
If the merge commit has been pushed onto a public branch (let's say ocean/develop for example) best practice is to not remove it. However branches contained in people's forks are entirely theirs. They can merge and remove as they see fit, as long as they properly communicate any changes with other developers that may be affected.
An example of a developer that may be affected would be if one person did some work (call them the base developer) that another wanted to base their work off of (call them the branch developer). If the base developer modifies their branch (i.e. rewrites history) they should inform the branch developer, so the branch developer does no try to submit a pull request with incorrect history (i.e. history the base developer doesn't want in the repository).
Q) What is the best way to incorporate new features into a given development branch that are not yet on ocean/develop?
A) Similarly with a lot of git related things, there isn't a single "best" way to do things. There are options, and which is best depends on the situation.
The "easiest" way to incorprate changes from a single other commit is to use git cherry-pick. However, you need to make sure you remove the commit later.
The "easiest" way to incorporate multiple commits is to use git merge. However, again you need to make sure you remove the commit later, but additionally subsequent commits might only work after the merge, so you might have to do trickier things like rebuilding the merge commit, or migrating your branch.
The final way to incorporate multiple commits is to use git rebase. However here, you're changing the base of your branch. So the commits you previously built / tested may need to be updated to work again.
A) A rebase is easily the most useful tool for modifiying your own history, but both have downsides for incorporating other changes.
Merge commits can be really difficult to remove from history. However, rebasing can cause a lot of work in updating a branch.
Rebasing a branch on to it's base (i.e. git rebase -i $(git merge-base HEAD MPAS-Dev/MPAS/ocean/develop)) is incredibly useful for modifying a branches history.