I have a Rails app A and I cloned a Rails app B from it. Both have a separate Git repository for version control. Now I develop new features in separate feature branches which are then applied to either app A or app B.
But I also have feature or bug branches which need to be applied to both apps. Let's suppose I created a feature branch on app A and I want to apply this feature branch also to app B, how would I achieve this? Both git repo's are on my local machine and also on Github.
You can add a new remote on B.
git remote add A <url of A>
Now you can pull in changes from A by running the following on B local:
git fetch A feature
git checkout -b feature A/feature
All you have to remember is to keep any changes which you want to share on a separate branch. Now suppose you got some undesirable changes on this branch which you do not want to merge. You can always cherry pick individual commits on top of your current branch (master?)
git co master
git cherry-pick <hash of commit>
You can read more about it here: http://wiki.koha-community.org/wiki/Using_Git_Cherry_Pick
Related
I have recently started to experiment code review using Gerrit Code Review. Now I am trying to create a pipeline in jenkins and I have some issues with building based on a specific branch.
This is what I want to obtain:
I have 2 remote branches: master and develop.
For each new feature I create a local branch and I use git push origin HEAD:refs/for/develop to send the changes to review in order to be eventually merged into the remote's develop branch.
After the changes are accepted and the merge is finalized the code from the develop branch should be built and the result will be deployed to server_1.
At some point the develop branch will be merged into the master branch. The code from the master branch will be built and the result will be deployed to server_2.
I have managed to use Patchset Created event to start the build for the changes that are being reviewed. And probably I will use Change Merged event to start the build based on the develop branch after the changes have been merged
I made the following settings:
Refspec: $GERRIT_REFSPEC:$GERRIT_REFSPEC
Branches to build: $GERRIT_REFSPEC
disabled Lightweight checkout
I tried to use the Ref Updated event to start the build when I push a commit directly into the develop from the local develop branch but it results in a failure. Why is this happening? What settings should I make to make it work?
Also how do I deploy code to the right server based on the current branch name?
I am new to git so please bear with me. I have a rails application on my local machine that I am experimenting with and pushing to the master branch periodically. It works at the moment, but I have fallen behind, and now I am many commits behind the master.
$ git branch
* master
$ git status
On branch master
Your branch is behind 'origin/master' by 27 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
nothing to commit, working tree clean
However, when I use git pull and then start rails, my application breaks with a precompiler error. So I am forced to use git --reset to go back to the local commit before I used git pull.
What is the right way to get around this issue and merge with the latest changes on the master branch? Would one use git --rebase in this case?
Try
git stash
git pull origin master
And once it updates, git stash apply to reapply your local changes
Since nobody has stated this clearly yet: You ask
What is the right way to get around this issue and merge with the latest changes on the master branch?
When you do git pull that does merge the remote changes into your current branch. Whether you would choose to do a rebase instead of a merge (per your other question) is a separate issue, but the default behavior is to combine the two sets of changes (local and remote).
More precisely, by default git pull does a fetch followed by a merge. The exact merge operation depends on configuration and on command-line options, but in a typical configuration where origin/master is upstream of master, saying
git pull
will merge origin/master into master.
So why the errors?
One possibility is that there were merge conflicts. If that happens, git will tell you. If you say git status in this condition, it will tell you that there's a merge in progress and it will indicate which paths (files) need conflict resolution.
Another possibility is that the changes don't conflict (in that they don't affect the same region of the same file) but still don't work properly together. That you would simply have to debug.
I am working on a completely different structure from the one on master branch, on a On Rails app in a local branch. I am comiting everything and then pushing my changes to a remote branch as well. At some point in future, I would like to integrate my changes back into master, but I want to make it even first, so I won't be behind it, just ahead by n commits. If I am doing a
git pull origin master
into my branch and then push that, would I loose anything from my previous commits, or would those stay on top of the master branch ones? In theory I should be able to merge my branch, as I will only be ahead of master, but I am not entirely sure if that's how git is working
Never do significant work on the master branch. The only time you are really working on the master branch is when you are merging or if you are the lone programmer on a project (even then its questionable).
When working on a feature or taking care of a bug you want to be working on a separate branch.
For example when I take an issue from the product tracker I create a topical branch based on the name of the issue:
git checkout -b 136-fix-something-important
If the work on a topical branch takes a long time you keep up to date with the remote by pulling the changes into the master branch and rebasing your topical branch off master.
git status # make sure you have a clean slate otherwise stash or commit
git checkout master
git pull
git checkout 136-fix-something-important
git rebase master
This would fast-forward 136-fix-something-important if there are no conflicts or you would have to resolve the conflicts. However taking care of conflicts is better done early that later in a mega merge.
When you are done with the feature in your topical branch you either merge it (if you are a maintainer) or send a pull request (if you are a contributor).
So what do I do now?
Move your work to a separate branch. And reset your local master branch from origin/master:
git branch mybranchname
git reset --hard origin/master
git checkout mybranchname
You can the rebase your work in mybranchname off master.
git rebase master
Other answers aren't wrong, but it would be cleanest to push to a remote branch, pull to local master from remote master, then locally merge master into your local feature branch.
Then, your changes wouldn't be lost, merge conflicts could easily be resolved, and you won't rewrite any other potentially collaborative history with rebase.
you will not lose data when you do a PULL but you will get merge issues which you will need to fix.
While technically you can push without pulling (with --force flag), you should not do that, because it discards other people's work. First pull their changes, resolve conflicts and only then you can push.
Piece of advice, try to make your units of work small, as in don't spend too much time away from master especially if master gets updated frequently. The reason is that you will have a very difficult time merging.
I know that this question has been asked in many different forms, but I have yet to see the configuration that I want, so I'm throwing this out there.
What I want:
1. 2 clones of the master, so each has its own entire version of the project, so that one subdomain goes to his current work, and the other to mine so that we can both see the changes that we commit and push to the remote server in our respective remote clones.
We both have own local versions of our remote folders/clones.
Essentially we both have our own branches, that neither of us are ever committing to the master branch. My personal branch can be considered the master in this case, because I want him to be able to make his changes, me be able to see and test them on his subdomain, and them merge them into my own.
I also want him to be able to pull my latest commits to the remote server into his own remote clone, and then subsequently onto his local machine so he always has my latest code.
What are the best practices for this? As of now this is what we have been doing and it has been a huge hassle and makes me hate git.
I make changes locally, commit them, and then push to my remote folder of the same branch.
He merges his local folder/branch with the remote commits that I made.
Any commits hes made locally he then commits to his remote branch/subdomain. (This should mean that his remote branch also includes my changes that he merged since his remote folder should be an exact replica of his local machine)
Upon inspection and testing I say a feature is complete, and I then merge into my local branch/folder
I push to my remote branch/folder and everything is available to see on my domain.
Is this not the correct way of doing things? Any suggestions or advice greatly appreciated!
The essentials are that we each have our own branches, and can make additional branches for features and merge them into our own. And also that we each have exact replica copies of our local machines on the server in different folders that are pointed to by the webserver via subdomains so both can be viewed at the same time in different states.
I apologize in advance for the length of this, I just wanted to be as clear as possible.
What you've written is not extensible - add a third developer, and then what do you do?
Instead, have the following branches:
master (always clean, use only for deployment to production server)
staging (always clean)
acceptance (messy)
You create new branches from staging:
git checkout staging
git pull
git checkout -b feature/JF_my_new_feature_20141018
(use a unique set of initials so you know who wrote the branch, and datestamp the branch as well.)
When you're satisfied with your branch (and your tests run fine), you merge into acceptance and run tests there. When your coworkers (or your QA team, or whoever), have verified that the branch is good, you merge it into staging.
Everybody always creates new branches from staging, and nobody merges into staging without a thumbs-up from someone else.
I have a Rails app deployed on Heroku and I have a git repo that I'm currently working on with uncommitted code changes. In the meantime, I need to make changes to the source on Heroku independently of the local repo. Can I do the following:
Clone the Heroku git repo on the same development machine with a different app name though with the same account
Make changes to the new local repo
Commit those changes to the new local repo
Push those changes to the Heroku repo
Resume working on my original local repo
Will this approach work?
Yep, that workflow would work, or stash them - and don't forget if you do make a clone of the heroku repo you'll have made changes to a different clone of the repo and you'll need to make those changes in your original local repo.
In future I'd suggest that you assume that your 'master' branch is what's live on Heroku and branch of that to work in - you can even push this branch into a new app for testing purposes. This way bug fixes can be performed on your local master branch (or another branch and merged into master) and pushed to heroku and then when you've finished your new work you merge the branch back into master and deploy that to your live environment. I wrote a blog article on the subject a while back, here
I haven't used heroku but if I wanted to make changes to a deployed application while I had unsaved changes in my sandbox, I would do one of the following.
stash my local changes, cut a branch from the point where I want to make a fix, make it, deploy it, switch back to my original branch and pop from the stash.
Commit my unsaved changes (into the current branch - say work), cut a branch from the point where I want to make a fix, make my fix, deploy it, switch back to work, reset my HEAD to before my "temporary" commit and resume work.
Unless you're using git in an unconventional fashion, there's no need to make another clone.
If you clone the heroku repository to a separate directory, made changes and push it from there, then there is a possibility of conflicts later down the road.
If its only the issue with the uncommitted changes then certainly you can stash them using "git stash" and later retrieve it using "git stash pop".
My work-cycle: I always keep a master branch with the #1 rule "always push to Heroku after committing something to master". If I code on something that I do not want to deploy immediately, I have to branch.
I know this works not for all use cases, but having always a branch that is identical to the app that is productive on Heroku makes me sleep better ;)