I'm going through the tutorial for angularjs. In step 0 of the tutorial it instructs me to run:
git checkout -f step-0
When I ran this I got "You are in 'detached HEAD' state" which I take to mean that I just created a new feature branch called "step-0" that did not previously exist. Then I reloaded my web page and saw that all the cool stuff from the master branch is now gone. Instead I get this basic page that says "Nothing here yet!".
Now this is all correct behavior. My question is why did git checkout change the state of my code?
I could understand if the branch existed and I switched branches then yea that would change my code. But in this case it looks like the branch does not exist and I don't see a branch by the name "step-0" on github.
So in my mind I just branched off Master and created a new feature branch. Any changes in code don't make sense to me in this case.
What happened?
The "detached HEAD" message means that you're not at the tip of any branch. You've gone back to an earlier commit on the master branch, but you haven't created a new branch that begins there.
You got there by switching to the "step-0" tag. A tag in Git is basically an alias for a commit ID: "step-0" refers to the commit 96a9b5b7fa5e5667e099d25c20a4bb19992c0f72. Tags are commonly used for naming releases (e.g. a "v1.0" tag on the revision that was released as version 1.0), but in this case they're just used to make it easy to switch to specific revisions as you follow the tutorial. A branch isn't needed because you aren't going to be committing a divergent set of changes from there.
Branches and tags are similar in that they're both names that refer to commits. The difference is that a branch changes as you create new commits — the branch name is updated to refer to the new commit ID each time — whereas tags are typically used to record points in history that don't change, such as the contents of a specific released version. (It's possible to change a tag, but only in the same sense that it's possible to change the history of a branch: if you've already pushed the tag to others, you'll have to ask them to delete it and pull the new one instead. You can't force tag changes on others.)
If you want to start a new branch from the commit you've just moved to, you can do so: git checkout -b my-branch.
Related
I'm still getting the hang of VS Code.
I want to make a react app using 2 different GET API URL endpoints but the exact same UI. In essence, I want to change just the base URLs between the 2.
I've tried creating a new branch in VS code to make 2 separate files but once I make edits in the master branch, the changes reflect in the new branch also.
Is there a way of making a different stand-alone branch from the VS code?
I've searched through the forums to no precise avail and I'm not that good at git. Thanks.
It is likely that your changes are being shown when you switch branch because you haven't commited your changes to a branch before switching.
Let's say you are on the master branch and make some changes. You can create a new branch new-feature and change your current working branch to new-feature bringing your existing changes across. This is useful because sometimes you will start to carry out some work before realising the scope is a bit too big and should be it's own branch.
If you want to keep the changes you have made on your current branch, you need to "stage" your changes with git add your_filename.here (or git remove). Once you have added and removed all changed files you want to keep on that branch, you need to git commit them. This is the step that finally adds the changes to the version history.
Now when you change to new-feature branch, your changes on master will not be there.
There are a number of GUI applications that make the git model more intuitive such as SourceTree, Github Desktop, and SmartGit
Database team is implementing code changes, using Visual Studio SSDT database projects with Git source control. Everyone is pushing to main Release branch with code review (only 5 developers on the team). All the database coworkers are only allowed pushing to different files only (tables, sprocs, functions), etc. The way work is assigned, none of us push or work the same sql file. Eventually all good changes from Release (currently in Work) are merged into Master branch (Production Ready).
Code Review ---> Push to Release Branch (Currently in work during Sprint) ---> Merge to Master Production Ready Branch
(a) What are the negative consequences of utilizing this strategy in Git?
(b) For cleaner history, should everyone Rebase ReleasePublic Remote into ReleaseLocal, or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.
Note: I agree, it would be annoying only if we are working on the same file and pushing changes. Alternative Strategy to create different feature branches and then merge into main branch. We are refraining from this strategy since each developer has 10 dba admin related changes a day, creating many branches and merges is time consuming and cumbersome-
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
Devops
The bottom line is if it's working for you then it's working.
The purpose of the source control solution is to assist you in producing software.
Use this setup until it doesn't work and then adjust. (Please note that all 5 of the devs could start using feature branches, if they want/need, without interfering with the other team member's flow).
Having said that there are consequences of using a single branch. Here are two examples
Releasable main/release branch
One of them could be shown in a following scenario:
A release happens
A commit with a bug in file A is committed
A commit file B is committed
You want to release the changes made to file B\
Now you don't have a releasable snapshot of the repo
If the changes for file A were tested in a feature branch then master/release branch is in a releasable state more often.
Pull requests
Having feature branches allows to use Pull Requests (which is a layer on top of git) better - your code reviews may be get easier to enforce and track.
we have delivered some set of packages to testing team and they completed testing.
In one of the package they report a defect and it was fixed and delivered to integration stream. But while deliver it asked for rebase and delivery contained reabase activity.
In rebase activity due to merging issues one of the file was modified in a package which had no defect.
As testing was already completed and the changes in the delivery is not required , our team wants to delete the latest version of a file [which is added as inadvertent] in integration stream.
If i delete the version of a file , will it have any ill-effect? ( For ex. while doing rebase again)
Deleting a version is almost never a good idea.
If that version has any hyperlink: don't delete it!
(You can see it by looking at its version tree: look for any red arrow coming to or going from that version)
If that version has any tag: don't delete it.
That label is probably the result of a baseline, and that would break the integrity of said baseline.
I would recommend checkout that file, and replace its content with the right one, before check it in back in ClearCase.
See also:
"How do I undo a checkin in ClearCase remote client": rmver is dangerous
"How do I roll back a file checked in to Clearcase?": a subtractive merge is preferable to restore the right content in a new version
This question is an evolution or resolution my previous question: Clone a git repo (in depth) I think creating a new question is the best thing to do in this situation, but I may be wrong.
This one is simple: how would I do something equivalent of git checkout master with libgit2
It seems like it was not possible a year ago: https://github.com/libgit2/libgit2/issues/247
According to this a clone was possible at least 5 months ago. But I have never seen any code, documentation or examples about how to do it. (Edit) I mean I haven't seen anything about a complete clone with git checkout included, nor any code/docs about the checkout.
According to this a clone was possible at least 5 months ago. But I have never seen any code, documentation or examples about how to do it.
The clone operation is basically made of four steps:
Initialize a new repository
Add a remote with a fetch refspec
Fetch the packfile from the remote and update your local references
Update the content of the workdir from the commit tree of the HEAD
Current version of libgit2 (v0.17.0) allows one to perform the three first steps.
The source code contains some examples. There's a "fetch.c" one as well.
how would I do something equivalent of git checkout master with libgit2
Checkout is not implemented yet. However, the following should help you go forward.
git_reference_name_to_oid() to retrieve the oid of the master branch
git_commit_lookup() to retreive a commit from an oid
git_commit_tree() to retrieve the tree of a commit
git_iterator_for_tree() to recursively browse all the leafs of the tree (and its subtrees)
Update
The clone feature has just been merged into the libgit2 repository.
clone.h header
sample code usage in examples/network/clone.c
As part of the pull request, the author took care of providing the users with a checkout implementation as well.
checkout.h header
checkout related unit tests
You can create a HEAD symbolic, then checkout to head, like
git_reference_create_symbolic(&head, repo, GIT_HEAD_FILE, branchname, 1);
git_checkout_head(repo, opts, stat);
I am trying to use git as something it wasn't made for - a database. Please feel free to tell me that this is a stupid idea.
Setup
One branch (let's call it robot) is being updated automatically by a script on a daily basis. The data comes from some other publicly available database.
Initially the master branch is the same as the robot branch.
Some of the data in the publicly available database is wrong, so I'll make a commit to the master branch and correct the error.
When the script detects any changes on the public database in the future, it will add those to the robot branch as a new commit (there's one commit per file).
Keeping track of differences
Now, I've obviously lost the ability to do a fast forward merge if I've modified the same file. But I could still cherry pick the good changes in the robot branch and import them into the master branch. The problem is that this might get rather messy after a while, when almost all the files have diverged.
How can I keep track of the difference between the different branches in a systematic way?
It sounds like you're looking for the git rebase command. This command allows you to update changes you've made to your master branch on top of the new head of the robot branch:
git checkout master
git rebase robot
There may be conflicts, if the database has been updated with a change to something you've changed in master. You must resolve those conflicts manually.