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
Related
I have a large repository (20000+ commits) that takes a while to do a one-time cutover from SVN to git. There is a tangled web of hundreds of branches, some of which are proper branches, others are more like developer sandboxes, some are partial branches, some are tags, some are unrelated repos which I will be extricating, etc. so I am familiar with the subgit configure feature and modified the config file in the subgit directory.
These branches create a lot of errors from subgit (I don't know why for most of them), and while I don't care about individual branches/errors, I don't want to exclude them all. There was an explosion of creating these branches around the 10000th commit, so I have to wade through the first half of the repo before any of these errors come up (about 4 hours).
So I'm wondering: Is there a way to restart the import after an error with a modified config file? It could either comb back through the commits it already did and make sure they look good or start at the problematic one, either way it would ideally succeed because I changed the branch mapping to exclude the problem. Thanks!
It is possible to restart the initial import with the same command used for the initial start, but the thing is that the mapping configuration change that affects branches mapping (means adds or removes branches to/from the configuration) requires the repository import restart from scratch as such the configuration changes usually affect the resulting Git objects.
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.
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.
I want to take on a project, but I’m not sure how to handle the updating process.
Normally, when asked to update a site, you back-up the database & site files, then make the updates locally or on a development server. Then when the updates are finished, you push them live.
My problem is that the site I’ll be working on registers new members every day, makes blog posts every day, and gets new comments on those posts every day. If I were to pull the site on Monday, update it in a testing environment, then push those changes live on Friday, every member who signed up and blog entry written during the week would be overwritten.
So what’s the best way to go about doing this? How do I update/add features to a site without losing the data gained on the live site during development? Surely it must be possible, since high-traffic sites like TechCrunch and Gizmodo make huge sitewide updates all the time without losing data.
It depends on what changes you're making. Is it file/template changes or database changes?
If it's just file changes, just pull the files and database to your local server, make changes to your files and then just push them (files only) to the live server when done. As long as no database changes have happened, that will work.
If there are db changes, things get a bit trickier. You would basically follow the same process, but make note of any db changes you are making on the local site. when everything is ready to be pushed to the live server, you have no other option but to take the site offline for users while you update.
You would then push all updated files to live server, and mirror any db changes you did on the local server (install/update plugins etc). When all that is done and tested, you can then put the site online again. Downtime should be minimal if you have made good notes on db changes.
This is dependant on being able to block access to users but still allow access for yourself, but that's standard with most CMSs.
Also, if you dont already you should look at integrating git into your workflow. If the changes you'll be making take a considerable amount of time you'll need a system in place where you can branch your code off into new versions while still keeping the original state of code that's on the live server.
That way, if there is an urgent fix that needs doing to the live site while your in the middle of developing new features locally, you can switch back to your master/original branch and make changes to the code that doesn't include any of the new stuff you have been working on the other branch.
Well, I've only done this for small traffic wordpress/drupal sites, but not having a "live" version hasn't been an issue for me. I have my development copy, make test the changes I want, and then roll those changes out to the live site on the fly by FTPing' them back up.
Are you going to be editing these registrations? Or are you just tweaking static files?
In the case of wordpress, I test a plugin out, and then just install it on the live site.
Typically the changes I'm making involve plugins/modules and some PHP stuff. This is obviously not the most nuanced solution, and I'm interested to see what more knowledgeable people have in mind.
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.