Simple GIT Command Sequence

I read the documentation and did a good job, but there are no real easy steps to be able to make local changes to github. I made the following steps, and I just want to make sure that you are doing the right thing. If I changed the foo.java file locally:

  • git status -s // shows that foo.java has changed

  • git add foo.java // add it to my local repo

  • git commit -m "my changes" // commit the local repo

  • git tag "v1.1" // create a tag

  • git push --tags // finally move the local commit to the remote repo with the new tag. this will require your password. if the tag is not installed as in step 4, just

git click

. is not it?

I'm just trying to make sure that these basic steps for most use cases are what is required to use github. I am new to github and these steps work for me, but I want to make sure that I am not making any fundamental mistake. Please comment if there are any missing steps. Again, I am concerned about the most common everyday use (for example, I really don't care about branches, etc., which I will study based on needs). Thank you in advance.

+5
source share
3 answers

Your steps are fine. However, to throw a little, about the comments:

Commenting on steps (2) and (3) is not the best way to think about what is happening, I don't believe.

2.git add foo.java //will add it to my local repo 3.git commit -m "my changes" //commit to the local repo 

The step that โ€œaddsโ€ your file to the local repository is git-commit . This is why he called commit ; You commit changes to the repository. git-add foo adds foo to the staging area, not to the repo itself.

Your git repository has three โ€œareasโ€, working , staging and repository , shown here (image taken from the Pro Git book ):

Git areas

You make changes and work in the creatively named "working directory".

When you have made some changes, you want to prepare for committing. This is where the "setting zone" begins. You "stage" the changes you want to make, and when you are happy with how the commit will look, you transfer the "intermediate area" to the "repository". [Note: on the man pages, this staging area is mainly related to index ].

This allows you to be more flexible. You can make all the changes since the last commit, or you can create separate files, or you can create parts of the files. You can add and delete files from the staging area without losing changes or ruin the repository history. What the git add and git rm commands do; they are added from the working directory in the staging area , but they are not added directly to the repository . (Hope the image helps make the differences clear).

Your steps are fine. If you want to know more about branching, committing, manipulating commits and branches and much more, I would recommend reading the Pro Git book - it got a whole bunch of beautiful pictures and language, simple enough so that I can understand it;)

+7
source

After (3), you can call git push origin master , which will push the current master branch on github

0
source

I think this is enough for a very simple use. I would like to add two comments:

  • It is always useful to check what you are adding to the staging area (this is what you are doing with git add ): either use git diff , or run git add --patch , which will launch an interactive procedure that allows you to decide whether to accept or reject each piece of the changed code. If you messed up something at this point, you can always git reset HEAD to revert the changes to (i.e. you just undo the add)
  • You might want to follow steps 2 and 3 by issuing git commit -a -m 'your message' .
0
source

Source: https://habr.com/ru/post/916691/


All Articles