Video Course 24 episodes explain Git and version control step-by-step, one topic per video. Advanced Git Kit 10 short videos help you learn more about the advanced tools in Git. Web Development Website Optimization Websites need to load fast to make visitors happy. Try Tower - For Free. What's the difference between git fetch and git pull? Let's now look at the fine but important differences between "fetch" and "pull".
Download Now for Free. Get our popular Git Cheat Sheet for free! New content and updates. Yes, send me the cheat sheet and sign me up for the Tower newsletter. It's free, it's sent infrequently, you can unsubscribe any time. With each commit there most likely will be additions, and there will also be deletions from time to time. To get a baring of the updates I have made, let's get the status. To add files, I can add them individually or I can add all at once.
From the root of the project I can use:. In order to remove deleted files from the version control, I can again either remove individually or from the root address them all like so:.
I'm lazy, I don't want to think, so I make heavy use of the following command to address all additions and deletions. All the preceding commands will stage the updates for commitment.
If I run a git status at this point, I will see my updates presented differently, typically under the heading of Changes to be committed:.
At this point, the changes are only staged and not yet committed to the branch. The next step is to commit with a message. Here is where I lean on the Angular style commit messages linked to above. To commit, do the following:. It is considered best to illustrate your comment in the tense that this will do something to the code.
It didn't do something in the past and it won't do something in the future. The commit is doing something now. Comments are cheap. When working with feature branches on a team, it is typically not appropriate to merge your own code into main. Although this is up to your team as to best manage, the norm is usually to make pull requests. Pull requests require that you push your branch to the remote repo. As far as Git is concerned, there is no real difference between main and a feature branch. So, all the identical Git features apply.
There is a special case when working on a team and the feature branch being pushed is out of sync with the remote. There are two ways to to address this. A very common approach is to pull. This will fetch and merge any changes on the remote repo into the local feature branch with all the changes addressing any issues with diffs in the branch's history, now allowing you to push. But there is a cost. This merge down will create a broken path in your project's history. A preferred method is to rebase.
Read below for additional information on this. When I am creating the feature branch, this is all pretty simple. But when I need to work on a co-workers branch, there are a few additional steps that I follow.
My local. To see what knowledge my local branch has of the remote branch index, adding the -r flag to git branch will return a list. The -p or --prune flag, after fetching, will remove any remote-tracking branches which no longer exist. Doing a git pull or git fetch will update my local repo's index of remote branches. As long as co-workers have pushed their branch, my local repo will have knowledge of that feature branch. By doing a git branch you will see a list of your local branches.
By doing a git branch -r you will see a list of remote branches. The process of making a remote branch a local branch to work on is easy, simply check out the branch. This command will pull its knowledge of the remote branch and create a local instance to work on. Depending on how long you have been working with your feature branch and how large your dev team is, the main branch of your project may be really out of sync from where you created your feature branch.
When you have completed your update and prior to creating a pull request, you not only have to be up to date in order to merge your new code but also be confident that your code will still work with the latest version of main.
It's here where there are two very different schools of thought. Some teams don't mind if you PULL the latest version from main , by simply doing the following. This will fetch and merge any changes on the remote repo into the local branch with all the changes, now allowing your feature branch able to be merged.
This works for the purpose of merging, but it's kind of gross on the branch's history graph. Then there are teams who are not a fan of this process, simply because pulling from origin can really screw up the feature branch's history and make it harder to perform more advanced Git features if needed.
Rebasing a feature branch is not as scary as most make it seem. All a rebase really is, is taking the updates of the feature branch and moving them to a new spot in the history as to be on top of the latest version of main.
It's as if you just created that feature branch and made the updates. This creates a very consistent branch history that is easy to follow and easy to work within all situations. To rebase your local feature branch off of the latest version of main , following these steps will be a guarantee every time.
And that's it. This process will ensure that you have the latest version of main then take the commits from your feature branch, temporarily unset them, move to the newest head of the main branch and then re-commit them.
As long as there are no conflicts, there should be no issues. Yes, there are those who are not fans of force pushing, but in the case of a feature branch, this is ok. Now force pushing to main , well, that's a really bad idea.
When performing operations like rebasing you are in effect changing the branch's history. When you do this, you can't simply push to the remote as the histories are in conflict, so you will get rejected.
To address this, adding the --force flag to force push tells the remote to ignore that error and replace the previous history with the new one you just created.
In the worst-case scenario, there is a conflict. This would happen even if you did the pull directly from main into the feature branch.
To resolve a conflict, read the error report in the command prompt. This will tell you what file has a conflict and where. When opening the file you will see a deliberate break in the file's content and two parts that are essentially duplicated, but slightly different.
This is the conflict. Pick one of the versions and be sure to delete all the conflict syntax injected into the document. Once the new updates are staged, you can't commit again as this process is inside a previous commit. So you need to continue with the rebase, like so:. If for any reason you get stuck inside a rebase that you simply can't make sense of, you can abort the rebase;.
As long as there are no other issues, the rebase will continue and then complete with an output of the updates. The pull request is where the rubber meets the road. As stated previously, one of the key points of the feature branch workflow is that the developer who wrote the code does not merge the code with main until there has been through a peer review.
Leveraging Github's pull request features, once you have completed the feature branch and pushed it to the repo, there will be an option to review the diff and create a pull request. In essence, a pull request is a notification of the new code in an experience that allows a peer developer to review the individual updates within the context of the update. For example, if the update was on line 18 of header. This experience also allows the peer reviewer to place a comment on any line within the update that will be communicated back to the editor of origin.
This review experience really allows everyone on the team to be actively involved in each update. Once the reviewer has approved the editor's updates, the next step is to merge the code. While it used to be preferred to merge locally and push main, Git has really grown into this feature and I would argue today it is most preferred to simply use the GUI took in Github.
Creating a merge commit is ok, this will simply merge in the new feature branch code into the main branch as long as there are no conflicts. Github will not allow you to merge if it already knows there will be conflicts.
The squash and merge process is interesting as this will compact all the commits to this feature branch into a single commit to the main branch. This may or may not be an issue depending on how your team want's to preserve history. If you are a user of the Angular commits, you may not want to use this feature. Lastly, there is the rebase and merge. Showing my preference for rebasing earlier, I am definitely a fan of this merge action.
There is another wikipage on how to rebase or merge a branch. If you pull remote changes with the flag --rebase , then your local changes are reapplied on top of the remote changes.
If you pull remote changes with the flag --merge , which is also the default, then your local changes are merged with the remote changes. This results in a merge commit that points to the latest local commit and the latest remote commit. It is best practice to always rebase your local commits when you pull before pushing them.
0コメント