Reputation: 681
So, I have a branch checked out from the master branch.
master
I have some changes in models. Now, I'm done with the work that I had to do in the models branch.
Similarly, I will create the next branch and do some work there and push to that branch itself.
So, what should I do next?
git pull origin models
git checkout master
git merge models
git pull origin nextBranch
git checkout master
git merge nextBranch
Now, it is being said, "Always stay up to date with the master". I don't understand what that means. We're not pushing anything to master, right? We're pushing to the local branches. Also, I've seen folks doing always git pull origin master
. Can someone explain to me the proper workflow?
.
I don't know, I'm just confused.
Upvotes: 2
Views: 640
Reputation: 7012
I think the confusion comes from the different styles of working with git. Some of them are there because of personal preferences, and some because of a different workflow (working locally or with a remote for example, or using gitflow).
So, a little about the commands you asked about:
git pull origin master
- this will update the local master branch to be the same as the remote master branch. Assuming you're not working directly on your local master branch, this should always work and give you the latest changes available.git pull origin <other_branch>
- Same as the previous bullet but for another branch. it fetches the remote copy of your local branch, merges the remote changes with your local changes, giving you the most up-to-date branch that includes your changes. Basically, it's like saving some of the work on the remote branch, making some local changes, and then creating a new document from both of the changes. You can force it to do a rebase
instead of a merge by passing the flag git pull --rebase origin master
So basically, when you've finished working on a feature of a bug, you want to do the following:
git pull origin models
]git checkout master
]git merge models
]This will work as expected as long as you're working alone and don't plan to have someone else review your changes!
If you plan to work with other people, you probably want someone to go over your changes to make sure everything works as expected before merging the new feature to the master branch.
So you don't want to git merge models
to your local master branch, but create a pull request on the remote git service and merge the remote feature branch with the remote master branch (after a code review). makes sense?
Here's the remote way of doing it (kind of simpler locally but with extra steps on the service itself): (Should be done on the feature branch)
# get all the features that got merged into the master branch remotely (by other users) and merge them into your feature branch
git rebase origin/master
# get the latest changes (saved by you on a different machine) from the cloud and merge with local changes:
git pull origin models
# commit all the new changes locally
git add .
git commit
# push back to the cloud!
git push origin
Now on Github, you can create a pull request (you'll see a prompt to do that). After a code review, you can click on 'Merge Pull Request` to merge this branch to master.
you can see which branch you're going to merge into:
Upvotes: 9
Reputation: 66
git pull origin master
tells git to update your current branch with whatever is currently in master. This is the command that you want to use regularly while working on your local branch to ensure you don't have any big merge conflicts to resolve when you are 'done' and ready to merge your code.
When you are done with the work on your feature branch (in this case called 'models'). It sounds like you want to merge that back into master, and push it
So, locally you would do
git checkout master
git merge models
git push
Which will switch you back to the master branch, merge the changes you had on the models branch into the master branch, then push those changes back to your central repository.
Upvotes: 3