I am having some difficulty figuring out which Bazaar commands to use...
Suppose I have a local branch named "test" in a folder of the same name:
When I initially get the branch, I type:
cd test
bzr pull lp:project_name
To commit local changes, I type:
bzr commit -m "message"
I have no trouble with those commands.
Here is where I get confused:
How do I push changes to Launchpad? I'm guessing bzr push but doesn't that overwrite other contributors' changes?
How do I update my local branch? I'm guessing bzr pull, but doesn't that overwrite my changes?
What are the proper commands in each case?
bzr push won't overwrite other changes. It already someone else has pushed it changes it will stop and tell you that you need to merge first. So basically you can only push when you have included the changes from the push-location.
Similar with bzr pull it takes from the location. However you already local work committed, it will stop and ask you to use bzr merge.
Related
I have looked at many past posts without a specific response. I used git reset --hard to get me to a point in time when my code was not all jacked up. Yes I should have used a branch but I didn't. Now I have a message of HEAD is now at 0600b73 fixed error. What I would like to know is how to commit those changes, so I can push them back to Git, so they are the current head? I am not even sure if VS Code even recorded the changes. Git can be confusing so any help would be appreciated.
You haven't actually proven you have changes, HEAD is now at 0600b73 fixed error., that does not mean you have changes. That basically means that you moved the HEAD of git to a commit, generally you want it on a branch.
git status will tell you if you have things that need to be committed.
I am not even sure if VS Code even recorded the changes
VScode has some cool features around git but it doesn't actually record changes, unless you are referring to saving files. If you save the file, well it saves.
What you probably want to do is (I am assuming you actually do have changes):
confirm you have changes git status
move to a branch git checkout -b my-fix
add those changes git add . (adds all changes/also make sure you are at the root of the repo) or git add -p will let you look closely at changes and give you an interface to decide if you want to stage the change or not.
commit the changes git commit -m "Your message" or you can do a longer message with git commit -p
At this point you can merge this branch in to master, push the branch. It's up to you.
push your changes, git push origin my-fix, make a pull request and merge to master. You will then want to change to master and pull master
merge git checkout master , git merge my-fix
rebase git checkout master , git rebase my-fix
Here is some git learning material:
https://learngitbranching.js.org/
https://www.codecademy.com/learn/learn-git
https://try.github.io/
https://www.atlassian.com/git
Is it possible to undo one or two faulty commits I have made to Github. I'm not very good at coding either so if there's a way to do it without coding, that would be great.
Thank you very much
You can do this via doing the following command in your local workspace:
git reset --merge <hash>
Where <hash> is the commit prior to the commits that you want to revert.
The above command is enough if you haven't pushed to GitHub. If you have pushed to GitHub, you then run the following to force an update of the remote branch:
git push --force origin <branch>
(Note: This is assuming that your remote is named origin, but rename as appropriate.)
Note that this re-writes history on the remote branch, and is not recommended if other developers are using the same branch. If you know who the developers are, you can communicate with them to delete their local copies of the modified branch and ask them to run git fetch to get a new copy of the branch.
I've had problems using git pull origin SomeBranch in that when there are conflicts, sometimes I cannot open a file in Xcode to resolve the conflict.
From my reading, although I could be wrong, I thought git fetch grabs the code but does not merge it yet like git pull does. How does this work with Xcode?
For example, on one machine on Branch1, I put in some changes.
Then on machine 2, on Branch2, I want to fetch Branch1 changes.
So I did this
git fetch origin Branch2
My output from the command line was:
*branch Branch2 -> FETCH_HEAD
What does this mean? When I go to the source file of the file that I changed, I do not see any changes made.
I thought what would happen is in Xcode, it would then show the changes of that file in that source file and that file would then be Modified. And only when I commit would it be added to the staging area so I could merge it with everything else. But maybe I am understanding it incorrectly. Thoughts? Thanks.
I thought git fetch grabs the code but does not merge it yet like git pull does.
Yes, that is correct. git merge is what updates your working directory, which is why...
When I go to the source file of the file that I changed, I do not see any changes made.
git fetch retrieves the objects that represent the changes, but does not update your working directory. That's what git merge does. Remember that git pull is basically a git fetch followed by a git merge.
fetch just updates your remote tracking branch.
This allows you to inspect what was pulled down from the server before integrating those changes with what you have locally.
You now either merge or rebase those changes to your local branch (if it exists). If it doesn't, you can simply
git checkout branch2
if it does,
git merge origin/branch2
or
git rebase origin/branch2
to skip this 2 step process, just
git pull origin branch2
which will by default merge. You can override with
git pull --rebase origin branch2
you can change your config so that pull will always rebase instead of merge.
For a Git repository, you need to save changes you’ve made and commit them to your local repository before updating changes from the shared repository.
https://developer.apple.com/library/ios/recipes/xcode_help-source_control_management/UpdatingorPullingChanges/UpdatingorPullingChanges.html
Specifically, I'm using bzr, but tips for any VCS are welcome.
I think there are three options.
Use shelving
bzr shelve --all
bzr unshelve
Create a separate branch with the
latest
Create a patch of you
changes and revert the changes.
Apply patch when you need your
changes back.
Using Git:
git checkout HEAD^ # get the previous version, changing files on disk to match
make # run your project (or whatever command you use)
git checkout master # return to the "master" branch
The above applies if you've already committed whatever current changes you're working on, and want to go back to the previous commit. If you have changes that have not been committed yet, then use the stash:
git stash # save the uncommitted changes away
make # ...
git stash pop # restore your uncommitted changes
You can make and commit other changes in between the stash and the pop; this is Git's solution to the "boss interrupts with an immediate bug fix request" problem.
I'm just starting out with bazaar, and I've found that the checkout feature is the most useful for the way I work - namely I can c/o from a "master copy", do some development and then commit my changes in the new directory. This then updates the "master copy".
But what if I'm working on (eg) two projects, changing different portions of code? Say:
~/master - master copy
bzr co master ./gui
bzr co master ./engine
So I'm doing gui-related stuff in the ./gui directory and under-the-hood stuff in ./engine. How should I commit my changes? If I commit gui first, then engine, I guess any conflicts will be flagged in engine?
Is there a way to merge gui and engine, and then do just one commit to the master copy?
To make things a little more complicated, how about if I do this:
bzr branch gui ./mouse
Now I perhaps I've been working on mouse, but also on gui. If I want to merge the code from gui AND mouse, and then commit to master, what is the best way to manage this? Or indeed, if I also:
bzr branch gui ./keyboard
If I've changed altered gui, keyboard and mouse, should I hierarchically merge - ie mouse+keyboard, then merge this with gui, then commit gui to master?
I hope it is clear what I'm trying to achieve! Thanks in advance for your time.
If you have two checkouts, any time you commit changes to one, you will first have to pull down any changes from the other one, potentially having to resolve conflicts at each step. This is generally a good idea, since it's easier to resolve conflicts over time and make sure your code doesn't diverge too much.
However, it sounds like you want to have separate developers working on "gui" and "engine", or you just want to save your conflict resolution till development on both branches has completed. In this case, you should probably create them as independent branches with "bzr branch". Each branch can use local commits and not worry about conflicts with each other. Then when it comes time to merge you can do it one of 3 ways, all of which get the same end result:
1. Merge one branch into the other, then push it up to master:
cd gui
bzr merge ../engine
# manually fix any conflicts
bzr commit
bzr push #back up to main
The downside to the above method is that your "gui" branch now has the "engine" changes in it. Which is fine if you're going to throw away both branches once they're pushed back into the mainline. But if you want to keep the branches longer, you can:
2. Merge into the mainline:
cd master
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
This has the upside that you still have "gui" and "engine" as separate branches, but you've had to commit one to master before you were sure that they would both work together. So you really probably want to:
3. Create a merge branch:
bzr branch ~/master gui-engine-merge
cd gui-engine-merge
bzr merge ../gui
bzr commit
bzr merge ../engine
# manually fix conflicts
bzr commit
bzr push ~/master
# since this branch was only for merging, you don't need it anymore:
cd ..
rm -r gui-engine-merge
Yes, bzr should prevent you from checking in changes from the engine repo if it detects conflicts. Normally, you first do "bzr up" just prior to check-in and then make sure your stuff plays nice with others.
As for the second part of your question, dealing with mouse/keyboard branches, this is how I would normally do it. Simply cd into the gui dir, and then do:
bzr merge ../mouse
After merging the changes, you can then commit from the gui directory and it will send the changeset to the "master" directory.
Note that I'm hardly a bzr expert, but this is the way I've been dealing with SVN repos.