I am fairly new to Git and have created a new branch from our repo and been working on it for quite a while, but from the time I started working on it there have been many large changes to the remote master. My local branch doesn’t include these changes and I am a bit confused as to what the next steps are to make sure my branch will work with the remote code and vice versa. Should I at this point, call “git fetch” and “git merge” to update my local repository code to include all the changes in the remote version? And what if it breaks my version of the code?
Yes that’s what you should do.
While there are many strategies for using Git the most popular (in my experience) is the use of feature branches. That is when you have something to work on, you update your local master (or whatever the primary branch is) and make sure your remote (origin) primary branch is also up-to-date. Create a feature branch for the particular item you’re working on. If for some reason that feature branch becomes long lived before pushing it to your remote (origin) and raising a Pull Request (against Upstream) then you should regularly fetch/merge based on the primary branch from Upstream (in order to get those delta changes that you’re talking about). From time to time you may discover that there are conflicts (that you modified a file/line that someone else did in the mean time.) It’s up to you to de-conflict those changes when you fetch and merge. (Hopefully there are unit/functionality tests you can run.)
Keep your feature branches small and specific, push/PR often. Update (fetch/merge) regularly.
Thanks! This is basically a “feature” branch as you suggested. So, I will have to “git fetch”, “git merge” and then manually check the code for any instances where my code made changes to the remote version and vise-versa, then do a "git push origin "? (branch I was working off of)
Then what about “Pull Requests”, where do they come into play?
Basically yes, git will let you know about any conflicts (that is code that can’t be merged automatically). Make sure to run tests, depending on language and project structure it’s usually possible to change code in one file so that code in another file doesn’t work right, without any conflicts. Especially if it’s a file you added, so upstream doesn’t know about it yet.
Where pushes should go depends on the workflow, you mentioned “our repository” above, so I assume it’s a shared one. In that case pushing your feature branch there is probably correct. In case of doubt ask the people you’re sharing the repository with.
Pull requests are a way to request merging of your changes into the upstream branch (usually the default branch). Others can review and comment on the changes, request improvements as needed, and people with the necessary rights can merge the code. Creating a pull request requires your feature branch to be either in the shared repository or on your fork (on Github) of it.
Can I push this new branch to the repository as a new branch and then create a pull request? And how would I do that?
push origin ?
Yes. After you have pushed the branch the Github website should offer you the option to when you look at the branch on the repository page.
The easiest case would be this, if you want to use the same name for the remote branch as for your local feature branch (replace the branch name):
git push origin your-feature-branch
It’s often a good idea to use
--set-upstream on the first push. That way you can just use
git push when on that branch to push to the same upstream branch.
Normally the first time you
git push on a feature branch it’ll tell you that you should set the upstream and give you the whole command like
push --set-upstream origin/your-feature-branch.
Since this is a branch, and not master, would I even have to do a git fetch and git merge on my local feature branch? Or, could I just git push origin my-feature-branch and then create a pull request on the repository?
Technically you could, but then any conflicts would show up on the pull request, and would still have to be resolved before merging. I don’t know the workflow in your project, but it’s commonly expected that the person making a pull request ensures that any conflicts get resolved.
That said, it’s also possible to create the pull request and mark it as WIP/draft to discuss the code (and possibly how to resolve conflicts) in the comments.
I did a “git fetch” and “git merge” and "git push origin ". This made sure my branch matched the repo branch, but shouldn’t I have updated my local branch to include the merged code, tested it, then pushed it to the remote branch and created the pull request? How would I do this, if this is the correct way.
The detail we’re missing is if you’re working on your own project or a company/3rd party project?
The workflow I see most people use for 3rd party projects is something like:
- The following assumes “master” is the default branch for the project, and “my-feature-branch” is the branch you’ve been developing something new on.
- Create a feature branch and do your work. Realize a week later or whatever that you’ve fallen behind.
git checkout master.
git fetch upstream.
git merge upstream/master(at this point your local master is up-to-date).
git push(at this point your origin master is up-to-date).
git checkout my-feature-branch.
git merge upstream/master.
- At this point you may encounter conflicts and need to resolve them.
git push(at this point your local feature branch is up-to-date with the main repo and has your changes as well, and now that you’ve pushed that means your fork now has an up-to-date feature branch).
- Open a PR from your feature branch (your fork/origin) against the upstream project/repo.
Note: At step 7 you could also rebase your changes on top of upstream/master, however you may then need to
git push --force since you’ll be rewriting the history of your feature branch (on your fork/origin).
Thanks! I am merging my feature into another branch “dev” in a repository that others are also making changes on, so your instructions seem to work; I now have merge conflicts. How exactly do you resolve 92 issues in a package-lock.json file? There were 2 changes made to the package.json and I’ve accepted both of them. Should I run npm install? Will that fix the package-lock.json conflicts?
I’m not a node person, but you’ve only really got two options.
- Over write the upstream changes with yours (which are likely older).
- Over write your package-lock.json with the upstream one (which means you probably need to re-test and perhaps re-write some code).