GIT - Checkout

Behavior of git checkout

Checking out an earlier commit will change the state of at least one file.
This is sometimes true. Git doesn't allow you to save a new commit if no files have been updated, so you might think this is always true. However, it's possible to do the following:
  • Save a commit (call this commit 1).
  • Update some files and save another commit (call this commit 2).
  • Change all the files back to their state during commit 1, then save again (call this commit 3).
This sometimes happens if commit 2 contained a bug, and it's important to fix the bug quickly. The easiest thing to do might be to remove all the changes introduced by commit 2 to fix the bug, then figure out how to safely reintroduce the changes later.
At this point, commit 3 is the latest commit, so if you checkout commit 1, none of the files will be changed.
Checking out an earlier commit will change the state of more than one file.
Checking out an earlier commit will change the state of every file in the repository.
Both of these are sometimes true. Since each commit tracks the state of all files in the repository, it is possible that checking out an earlier commit will change the state of multiple files, or even all the files in the repository. However, it is possible to save a new commit after changing only one file, so it is possible only one file will change. 

After checking out a commit, the state of all the files in the repository will be from the same point in time.
This is always true. A commit saves a snapshot of all files in the repository at the time the commit was made, so checking out an earlier commit will result in all the files being reverted to their state at the time the commit was made. That is, the files will be in a consistent state.

Bu blogdaki popüler yayınlar

About Android padding, margin, width, height, wrap_content, match_parent, R Class

Padding and Margin padding  and  layout_margin  are two very similar attributes. Both determine the space around a View. The difference is that  padding  determines space within the boundaries of the view, and  layout_margin  determines the space outside the boundaries of the view. Width and Height Some of the most important properties are the width property and height property - those must be defined for every view. Remember that all views occupy a rectangular area on the screen - the width and height are the width and height of that area. You can define this in pixels, or better yet dp (stands for density-independent pixels): android:layout_width="200dp" android:layout_height="300dp" For the sake of having a layout be responsive and adjust to different devices, two common values are not numbers at all, but  wrap_content  and  match_parent  used as shown here: android:layout_width="wrap_content" android:layout_height="match_parent"
Devamı

@SerializedName and @Expose annotations

The  @SerializedName  annotation is needed for Gson to map the JSON keys with our fields. In keeping with Java's camelCase naming convention for class member properties, it is not recommended to use underscores to separate words in a variable.  @SerializedName  helps translate between the two. @SerializedName ( "quota_remaining" ) @Expose private Integer quotaRemaining; In the example above, we are telling Gson that our JSON key  quota_remaining  should be mapped to the Java field  quotaRemaining .  If both of these values were the same, i.e. if our JSON key was  quotaRemaining  just like the Java field, then there would be no need for the  @SerializedName  annotation on the field because Gson would map them automatically. The  @Expose  annotation indicates that this member should be exposed for JSON serialization or deserialization. 
Devamı