Here's my situation....
I have created a repository on GitHub of a project. I worked on the project on a different computer then that which I have created the repository on. I now need to update the GitHub with the changes. I'm working from Android Studio. It seems the only option I have is to either create a new repository. I want to know how to update my old one without having to clone it and modify it then upload changes.
When you worked on the separate computer did you clone the repo? If so you can just push your changes. If not, you'll need to setup a remote
first init a git repo if your work is not in a git repo
git init
then add a remote
git remote add origin https://github.com/user/repo.git
use git remote -v to verify
set upstream
git remote add upstream
then pull, commit, push your changes now that your remote is setup
https://help.github.com/articles/adding-a-remote/
make a new git repo on your new PC using git init, this will add your project to a new repo on your machine.
add all your source to this new repo using a
git commit -am "whatever description of changes made"
Now checkout a new branch, call it what you like, but something like
`git checkout -b new_work`
should do the trick.
Now switch back to your master branch using git checkout master and connect your repo to your remote git repository on github
git remote add origin https://github.com/user/repo.git
You can set the upstream then using
`git remote add upstream`
Next you pull the remote code into your master branch using
git pull https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git BRANCH_NAME
Now you can merge all your new changes back into the master branch as you would in your normal workflow using
`git merge new_work`
or whatever you called your new branch.
Then push the master back to github using
`git push`
This approach has the advantage of being able to track all your changes properly and reverse them if needs be or amend update as needed whilst keeping the original code in tact and is the normal workflow for git.
Of course in the future you would pull the repo from git before making any changes and you wouldn't have this problem.
Hope that helps
Related
I have already did my first commit of my app on Github. Now I want to maintain several versions (like 1.0, 1.1, 1.2 etc.) of my app, whenever I add a new module to my app, on Github. How to do that using android-studio VCS or using terminal?
You can create different branchs for each version. You can have your current version in a generic especific branch and before you change to a new version, create a new branch named after the version of your choice.
If the current version is 1.2, for example, and you need to create a new version, stay in your current branch, create a new branch for version 1.2 and after that return to your current branch. (it will copy all the content of the current branch to a new branch).
To create a branch you can follow this example:
git checkout -b v1.2
When you go back to the current branch, your new changes will not affect your old version 1.2. It will be safe in it's own branch v1.2.
I would go with tags. That's the correct way to manage versions (or releases) of your app.
The Git Flow approach suggest you start from the master branch, then create a new branch called develop.
git checkout -b develop
From there you will create a new branch for each feature/request/issue and after it is done, return to the develop branch.
To create a new branch, if positioning in develop
git checkout -b new-feature
Commit as much as you want in that branch and when done, upload it to GitHub
git push -u origin new-feature
If the feature is done you can create a Pull Request in GitHub and merge that branch with the develop branch.
Repeat the process until you are ready for a new version/release.
Once you are done create a pull request in GitHub to merge develop into master.
Now the master branch will have all you want for you new version.
To tag it, position on master and update it from GitHub
git checkout master
git pull origin master
Now your local branch is up-to-date. Let's tag it
git tag v1.0
An you can also upload the tag to GitHub
git push --tags
A TAG is a mark in your repository pointing to the code of the specific version/release you have tagged.
I'm working on a project where we have reached a milestone. My git repository is up to date and everything is working correctly. Our client has now updated their api's and we're unsure how it will affect our code.
What I want to do is create a branch (already done) and upload the full repository to the branch. So I will have the project duplicated, one in the master and one in the new branch. I will then work and commit to the new branch leaving the master untouched. So going forward then for each release I can do the same, so we can fall back to the previous branch if there's any problem.
Can someone tell me how to do this please. I'm using Git and I'm working through a mac terminal.
I've gone through relevant questions on SO but I don't see the info I require, or perhaps I've missed it.
You don't upload a repository to a branch.
You have your code in a repository, and the repository has branches. No duplication, but you can get (checkout) master or the branch to set your working files to the version you want: master for untouched changes, branch for your recent changes.
Always good to do when you have reached a milestone is to tag the commit:
$ git tag v1.0
Then from there you can start a branch to work on integrating the new API
$ git checkout -b client_api_update
Work and commit in your branch. It does not affect the content in master, which you can checkout when you want to get your working files as they were in your milestone version (or checkout the tag).
When the integration of the new API is done, it's time to merge your branch to master in order to release support of the new API:
$ git checkout master
$ git merge client_api_update --no-ff
--no-ff is optional, but I think it makes for a more elegant history.
You are at a new milestone, so tag:
$ git tag v1.1
Here is how your history would look like:
/- v1.0 /- v1.1
A---B------------------G - master
\---C---D---E---F-/ - client_api_update
Let's say the branch you created in the main repo is <main_repo_new_branch>. Then the steps would be:
cd <local_repo_dir>
git remote add mainrepo <main_repo_dir>
git push mainrepo <local_repo_branch>:<main_repo_new_branch>
cd <main_repo_dir>
git checkout <main_repo_new_branch>
I am learning how to use Git for version control. One of the uses of creating branches is to add new features while master branch contains the stable code. I am using Git Bash for Windows in conjunction with Eclipse for editing the code.
So, assuming that I want to create a new feature called social-share and a branch named the same, how would I go about doing that?
Wont I first have to create a branch, commit the entire master branch to it and then add new feature code?
So I'm assuming that you already have a branch called develop where your development occurs.
The first thing to do is create the feature branch based on the current branch and switch to the created branch
$ git checkout -b social-share
Optionally if you want to push that branch to a remote Git repo to track it there:
$ git push -u origin social-share
Pushing the branch to the remote repo is dependent on your environment and whether or not you want others to work on this branch.
Once you've finished your changes to the social-share branch you'll want to merge those back into your develop branch.
First switch to develop branch
$ git checkout develop
Merge social-share into devleop*
$ git merge --no-ff social-share
Delete social-share branch
$ git branch -d social-share
Push changes to origin
$ git push origin develop
* The reason you use the --no-ff flag is so the merge uses a new commit object and to avoid just fast-forwarding the develop branch which preserves the fact that the social-share branch existed at one point.
If you want to read more about this branching model then checkout the post it was based on. Also, if you would like to learn more about git branching by actually doing it there's a great tutorial series/sandbox that you should checkout (git it?).
I'm trying to do some contributing to Cyanogenmod. As per the directions at https://github.com/CyanogenMod/android_vendor_cm, I do the following:
repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0
repo sync
And, as expected, after a few hours I have the CM source! However, the documentation at http://source.android.com/source/developing.html is a little confusing.
Basic Workflow
The basic pattern of interacting with the repositories is as follows:
Use repo start to start a new topic branch.
Edit the files.
Use git add to stage changes.
Use git commit to commit changes.
Use repo upload to upload changes to the review server.
Since the documentation states "Repo is a repository management tool that we built on top of Git." I assumed that once I initialized an android repo (and the fact that the URL ended in .git) the repo automatically would contain such an environment that I could use git. When I tried to follow the Basic Workflow instructions, however, git complained that it didn't find a git repository. This makes sense because I only saw a .repo directory, and no .git directory, like git expects.
So, then, do I need to initialize my own git repository? The instructions aren't very clear on that.
Thanks!
In order to gain git functionality you must initialize it as a git repository.
Try moving to the directory you cloned and type git init.
I have a whole android project code,it is very different from google's,because a team have developed on it for one year.Now I decide to use git instead of svn.And I want to use repo script to maintain the project.How to transfer?I've try to mirror a git server from Google via
repo init -u https://android.googlesource.com/mirror/manifest --mirror
then build my branch,but when I merge my project code to it,it is too difficult.
Is there a easy way?Thanks!
I am working on this same issue, the most progress I have made is due to this google group discussion.
From what I can tell you are going to have to maintain projects individually using git (I think you can do a repo start instead of git branch to setup your branches, then when you are ready to push changes you can use git push to the mirror. The thing you can gain from the repo script is the ability to use repo sync to sync all of the projects, and repo start to make new branches.
Could you be more specific about the problem you ran into with the merge? I may be able to help more on that front.