在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:NataliaLKB/learn-git-basics开源软件地址:https://github.com/NataliaLKB/learn-git-basics开源编程语言:开源软件介绍:Learn gitThis workshop has been made for students of Founders and Coders, and therefore assumes that you have completed lesson 1 of Udacity's Git and GitHub course (as part of the precourse material) All contributions to this workshop are very welcome! If you have any suggestions for improvements, please raise an issue. The author will let you know whether they prefer to make the changes themselves, or whether you are welcome to submit your own PR (Pull Request). If you do make PR yourself, please follow the Founders and Coders contributing guidelines. Contents
GitHub FlowVersion control makes it possible for you and I to work on one file at the same time, because we can keep both our versions saved and then compare them once we have each finished our work. This allows us to integrate our changes more swiftly. Most developers use git as their version control system, but different teams use different "workflows". At Founders and Coders, we generally follow something called "GitHub flow", because this flow makes it easy to deploy the latest version of your application very regularly. For a fuller explanation, there is a useful article in the resources section. To see the steps involved in working on a "feature branch", follow GitHub's visual guide now. What is a branch? Git BasicsNext please fork this repository. Getting StartedThe next step is to clone the forked version of this repository. On the main page of the repo, copy the url shown here: Then use the command in your terminal:
You should now be able to redirect into the directory just created using the command line. Next, it is good to get in the habit after each command to use
Now check which branch you are on:
You should only see When there are other branches in your repo the green branch is the current one you are on. BranchingThe next step is to create your own branch to work on. try this:
It is best to try to name your branches as specific as possible, so not to confuse them with any others. There are many naming conventions out there for branches, but for this week simply try to name them off of a feature. For example (
As you can see, you have created your branch, but are not currently on it. To navigate onto it please:
Now you can see you are on that branch. Go back to master and now we are going to delete
As you can see, your branch is now gone. Making ChangesNow it is time to make some changes in the project. Make yourself a new branch named As you can see, this contains all the commands you will need to begin using git. Continue to add to it all the new commands you learn. To begin, here is a command that both creates a branch, and moves you onto it at the same time:
Add that command, and its description to cheatsheet.md and save it. Now in your terminal:
You will see something like this: You will see your changes in red. now we need to add them to the git staging area. Doing this is like telling git to pay attention to these files, and start tracking the changes. To do this write this command:
Now you can see the file name has turned green. Now to commit your changes.
The message could be anything, but it is best to make it something that describes what you just did. You can also use the command Merging Changes with MasterNow that you have made and committed your changes, it is time to merge your branch with master. Even though you are not working with anyone else on this repository, it is always good practice to make sure your current branch is completely up to date with master. Imagine if you were working with a team. Someone else has already pushed up changes to master. If that someone else and yourself have changed the same file, it is quite likely that your changes will not be compatible with theirs. To avoid this, you want to merge your changes with theirs to avoid future problems. Checkout back onto master and pull down. These commands look like this:
Pulling down means that you are getting any recent changes from the remote master branch which is located in Github. Next go back to your branch (
Even though in this situation there isn't any changes to merge, it is best to get in the habit on going through these steps in your work flow. Merging like this means taking any possible changes in master and merging them with the branch you are currently on. After you merge with master you have to push your changes to the remote repo (Github).
When you pull or push you are referring to your remote repo, or origin. In the example of For more information on pushing, see here Go to your browser and open up this repository in github. Press the branches button And then make a pull request to master Afterwards you will see a merge button. Press it and delete your branch. Now your remote branch master is completely up to date with your latest changes. Return to your terminal and navigate to your local master branch. Pull down. You will see your branch update (fast-forward). Delete the branch Merge ConflictsCheck all the branches on this repository, even the remote ones. To do this use this command:
You should see something like this: Run the command:
Open up the git cheatsheet, as you can see there are some differences between this and master. To see these differences use command:
The differences in green and the additions on this branch, that don't exist on master. The red are the things that are on master, that don't exist on this branch. Merge with master. You should have a git conflict that looks something like this: Do you see the lines at the top. The first section is labelled Afterwards git status, add the files in red, commit, and push. Then make a pull request to master like before and merge. Don't forget to update your local master branch, and delete the merged branch in Github and in your local repo. It is good to keep your working environments clean and organised. Changing File StructureImagine you're working on a project that's getting bigger in size. As new files are added, it makes sense to group some of them into folders. For example, it's a good idea to keep all CSS files in one folder, JS files in another etc. Let's assume you've just cloned a repository structured like this:
However, you'd prefer to split these into folders like:
In order to achieve this,
(This glues Basic function usage is
The command also takes optional parameters. To find out more, refer to documentation. Git for CollaborationTerminologyHEADSimply put, the HEAD is a reference to a commit object. For more information see: http://eagain.net/articles/git-for-computer-scientists/ The TimelineAs you know from the Udacity course, git stores all the commits on the project. You can use them as a timeline and travel back and forth in time. This section reminds you how to do that, which will come in handy as you work in projects with your team. Make a new branch called Step 1) Make a new directory in the project via the command line. Lets call it
Step 2) Also make a new file in that directory and call it whatever you like. A simple text file should be fine. After you are done, open it.
Write the current time stamp, and a short message to your future self. Save it. Next add and commit your changes. Your commit message should be descriptive of what you just did. Repeat step 2 twice more, deleting the previous time and message, and adding the new time and a different message. Make sure you add and commit each time. Make sure your commit messages are unique, and you can tell which one was first, second, and third. Step 3) Next type in this command:
You should see something like this: Pick the second time commit that you made and copy the hash. Use Step 4)
As you can see after you checkout a message appears informing you that you are in a 'detached HEAD' state, meaning your are not working on any current branch. Open up the file in the time folder and look at the time and message. It should be the 2nd one that you wrote. Repeat step 4, and use the hash of the first time commit you made. Open the file and see that the time of your first commit, and your message to yourself. This is going back in time. You can easily go back as far as you like in the project and see older iterations of this tutorial! Next, we should go back to the future. The quickest and easiest way is to checkout onto the Find the commit name of the last commit you did (the third time that you recorded) and copy the short hash in yellow. Checkout back to that commit, and CommittingWhen should you commit?You should aim each commit to be a "safe" version of the project. This means that if you checkout to any commit in your timeline, that should reflect where the project was at that point, and be functional. Given that, when you commit is very important. I have heard two very useful guidelines. The first, is that as you complete the task assigned to you, you make several commits at different times during that task. In the end you merge all those commits together to make one very informative commit of that task. I will talk about ways to merge commits together in a later section. The second method is you work through your task and complete it before adding or committing at all. Then you check the status of the repo and see all the files you have changed. The next step is selectively adding and committing Through my research I have come across many different methodologies, and ultimately you should try to do what seems the most natural to you. I use both of these methodologies depending on the extent of the task before me. The best thing is to always keep in mind that you and your colleagues will inevitably need to go back to your commits and it will help everyone if commits are aptly named. Likewise, even in pull requests, you must aim to make your commits a clear and concise summary of what tasks where completed on that branch. That way the person reviewing your pull request understands what they will be reviewing before looking at the code itself. Commit messagesJust like choosing when to commit, and what to commit, it is also important to think about your naming. It is always good to be as descriptive as possible with your commit messages. Also consider:
Remember that the purpose of this commit is to be a message for future you, or your colleagues who may not have known what you are working on. Try to think about your message with this in mind. Many development teams take it one step further and turn their commit messages into change logs. These change logs may be used for user consumption making it all the more important to have clear messages of what was done for that commit. I tend to favour one line commits for simplicity, but many schools of thought out there prefer multiline commit messages. For examples of "best practice" formats for this see: Merging CommitsOften you will find yourself wanting to merge commits, or organising your early commits slightly differently on a branch to better demonstrate what you worked on. I will briefly go through one easy way to do this. Reset SoftThis is my preferred method of merging commits together. It leaves you with lots of flexibility. To begin, make a new branch and make some new files and commit regularly (at least twice). Next
Your working directory shouldn't changes, but all the files that you changed should be in green. Your log should have the newest commit as the hash you copied. Even though all your work is still the same as before the reset, the commits are different. Then you can commit again and this is an easy way to replace 2 or more commits with one commit. For more information and techiques see:
RESOURCES
|
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论