timeScale Lerp – Custom Time Manager

By now I need a timeScale Lerp and this need to be Time.deltaTime independent so, for anyone who needs this too, here’s what I’ve got (C#). You can also use it to create slow motion effects and control the play /pause of your game (assuming that you are using a Time.timeScale dependent approach):

You cal also get this code at GitHub

/// <summary>
/// Time Manager.
/// Time.deltaTime independent Time.timeScale Lerp.
/// Author: Fabio Paes Pedro
/// </summary>
///
/// 

using UnityEngine;
using System.Collections;

public class CustomTimeManager : MonoBehaviour
{
    /// <summary>
    /// CustomTimeManager is Paused or not
    /// </summary>
    [SerializeField]
    private bool _isPaused = false;
    /// <summary>
    /// CustomTimeManager is Fading (from _minScale to _scale or vice-versa)
    /// </summary>
    [SerializeField]
    private bool _isFading = false;
    /// <summary>
    /// CustomTimeManager will pause after fading (is going from _scale to _minScale)
    /// </summary>
    [SerializeField]
    private bool _willPause = false;

    [SerializeField]
    private float _scale = 1f;
    private float _fadeToScaleDifference = 0f;
    private float _scaleToFade = 0f;
    [SerializeField]
    private float _deltaTime = 0f;
    private float _lastTime = 0f;
    private float _maxScale = 3f;
    private float _minScale = 0f;
    private bool _fadeToScaleIsGreater = false;



    #region PseudoSingleton
    private static CustomTimeManager _instance;
    public static CustomTimeManager Instance
    {
        get
        {
            return _instance;
        }
    }
    void Awake()
    {
        if (_instance != null) Debug.LogError("There's another instance of " + this + " already");
        _instance = this;
    }
    void OnDestroy()
    {
        _instance = null;
    }
    #endregion


    void Start()
    {
        Scale = Time.timeScale;
        StartCoroutine("UpdateDeltaTime");
    }

    public bool WillPause
    {
        get
        {
            return _willPause;
        }
    }

    public bool IsFading
    {
        get
        {
            return _isFading;
        }
    }

    public bool IsPaused
    {
        get
        {
            return _isPaused;
        }
    }


    /// <summary>
    /// Time.timeScale independent deltaTime
    /// </summary>
    /// <value>
    /// time.timeScale independent Delta Time
    /// </value>
    public float DeltaTime
    {
        get
        {
            return _deltaTime;
        }
    }

    /// <summary>
    /// Getter and Setter for the CustomTimeManager Scale (time.timeScale). This will set IsPaused to true automatically if the scale == 0f
    /// </summary>
    /// <value>
    /// Scale (Time.timeScale)
    /// </value>
    public float Scale
    {
        get
        {
            return _scale;
        }
        set
        {
            _scale = value;
            _scale = _scale < _minScale ? _minScale : _scale > _maxScale ? _maxScale : _scale;
            Time.timeScale = _scale;
            _isPaused = _scale <= 0.001f;
            if (_isPaused)
            {
                _scale = 0f;
                _willPause = false;
            }
        }
    }

    /// <summary>
    /// Pause toggle (Changes the "IsPaused" flag from true to false and vice-versa)
    /// </summary>
    /// </param>
    /// <param name='time'>
    /// Time until Pause or Play
    /// </param>
    /// <param name='playScale'>
    /// Play scale.
    /// </param>
    public void TogglePause(float time = 0f, float playScale = -1f)
    {
        StopStepper();
        // WillPause == true means that a "Pause" was already called: this will make "WillPause" change to false and call "Play" function. 
        // Else just toggle.
        _willPause = _willPause == true ? false : !_isPaused;
        if (_willPause)
        {
            Pause(time);
        }
        else
        {
            Play(time, playScale);
        }
    }

    void StopStepper()
    {
        _instance.StopCoroutine("FadeStepper");
    }

    /// <summary>
    /// CustomTimeManager Pause
    /// </summary>
    /// <param name='time'>Fading time until Time.timeScale == 0f</param>
    public void Pause(float time = 0f)
    {
        if (Mathf.Approximately(time, 0f))
        {
            _willPause = false;
            _instance.StopCoroutine("FadeStepper");
            Scale = 0f;
        }
        else
        {
            _willPause = true;
            FadeTo(0f, time);
        }
    }

    /// <summary>
    /// CustomTimeManager Play 
    /// </summary>
    /// <param name='time'>
    /// Fading time until Time.timeScale == scale param
    /// </param>
    /// <param name='scale'>
    /// Final scale for Time.timeScale
    /// </param>
    public void Play(float time = 0f, float scale = 1f)
    {
        if (Mathf.Approximately(time, 0f))
        {
            _instance.StopCoroutine("FadeStepper");
            Scale = scale;
        }
        else
        {
            FadeTo(scale, time);
        }
    }

    /// <summary>
    /// CustomTimeManager Scale Fading.
    /// </summary>
    /// <param name='scale'>
    /// The final Time.timeScale
    /// </param>
    /// <param name='time'>
    /// The transition time to reach the desired scale
    /// </param>
    public void FadeTo(float scale, float time)
    {
        _instance.StopCoroutine("FadeStepper");
        _scaleToFade = scale;
        _fadeToScaleDifference = scale - _scale;
        _fadeToScaleIsGreater = _fadeToScaleDifference > 0f;
        float scalePerFrame = _fadeToScaleDifference / time;
        _instance.StartCoroutine("FadeStepper", scalePerFrame);
    }

    /// <summary>
    /// Coroutine to fade the Unity's timeScale
    /// </summary>
    IEnumerator FadeStepper(float scalePerFrame)
    {
        bool achieved = false;
        _isFading = true;
        while (achieved == false)
        {
            Scale += scalePerFrame * _deltaTime;
            if (_fadeToScaleIsGreater)
            {
                achieved = _scale >= _scaleToFade;
            }
            else
            {
                achieved = _scale <= _scaleToFade;
            }
            yield return null;
        }
        Scale = _scaleToFade;
        _isFading = false;
        _willPause = false;
    }

    /// <summary>
    /// Updating our internal _deltaTime
    /// </summary>
    IEnumerator UpdateDeltaTime()
    {
        while (true)
        {
            float timeSinceStartup = Time.realtimeSinceStartup;
            _deltaTime = timeSinceStartup - _lastTime;
            _lastTime = timeSinceStartup;
            yield return null;
        }
    }

}

출처 : http://fliperamma.com/timescale-lerp-custom-time-manager/

윈도우 7 에는 S-ATA 의 드라이버로 IDE 호환 드라이버는 물론 AHCI 드라이버도 내장되어 있기 때문에, IDE 모드에서 윈도우 7 을 설치하였다고 할 지라도 별다른 드라이버의 설치나 윈도우의 재설치 없이, 곧바로 S-ATA 의 모드를 IDE 모드에서 AHCI 모드로 변경하는 것이 가능합니다. 단! 그럴려면 먼저 윈도우에게 이제부터는 AHCI 드라이버도 사용할 것이라고 알려줘야 하지요. 그것은 간단한 레지스트리 편집으로 가능합니다. 전체적인 작업은 아래와 같습니다.

간단하죠? 만약에 이렇게 S-ATA 의 모드를 AHCI 로 전환하여 사용하다가 다시 IDE 모드로 돌아가고 싶다면, 별다른 작업없이 곧바로 S-ATA 를 IDE 모드로 변경한 후 그대로 윈도우로 부팅하면 됩니다. 이렇게 한 번 IDE -> AHCI 로 전환한 경우 이후부터는 보통 아무런 문제없이 IDE <-> AHCI 모드로 원할 때마다 바로 바로 전환할 수 있습니다.

마찬가지의 이유로 AHCI 모드로 윈도우 7 을 설치하였다고 할 지라도 위와 같이 별다른 드라이버의 설치나 윈도우의 재설치 없이 S-ATA 의 모드를 IDE 모드로 변경하는 것이 가능합니다. 단! 이번엔 반대로 윈도우에게 이제부터는 IDE 호환 드라이버도 사용할 것이라고 알려주는 것만 다릅니다. 마찬가지로 이 작업은 간단한 레지스트리 편집으로 가능합니다. 전체적인 작업은 아래와 같습니다.

마찬가지로 이렇게 한 번 IDE -> AHCI 로 전환한 경우 이후부터는 별다른 설정 없이 곧바로 IDE <-> AHCI 모드로 원할 때마다 바로 바로 전환할 수 있습니다.

1. 배치 파일

참고로 아래는 이 글에서 설명한 레지스트리 편집 작업을 간편하게 할 수 있도록 만든 배치 파일입니다. 실제로 작업하실 땐 레지스트리 부분은 아래의 배치 파일로 하시면 될 듯 하네요.

 윈도우 7 사타 모드 전환.cmd

배치 파일은 사실 위와 같은 이유로 단순하게 msahci 와 pciide 의 Start 값을 모두 0 으로 설정하면 되지만, 그냥 AHCI 전환 때와 IDE 전환 때를 나눠서 작업하도록 만들었습니다. 그리고 해당 배치 파일은 윈도우 7 에서만 사용해야 하기 때문에 윈도우 7 에서만 작동하도록 하였습니다.



2. 윈도우 7 의 S-ATA 모드 변경 레지스트리의 이해

간단하게 이번 글에 대해서 이야기를 더 해보겠습니다. 윈도우 7 을 IDE 모드로 설치한 경우 관련된 레지스트리는 아래와 같이 설정됩니다.

반대로 윈도우 7 을 AHCI 모드로 설치한 경우 관련된 레지스트리는 아래와 같이 설정됩니다.

즉, 현재 사용 중인 S-ATA 모드에 해당하는 키의 Start 값 데이터가 0 이 되고, 반대 키의 Start 값 데이터가 3 이 되는 것이죠. 모드 전환을 할 때는 이제 반대 키의 Start 값 데이터를 0 으로 바꿔주어 해당 드라이버도 사용할 것임을 알려주는 겁니다. 이 때 현재 사용 중인 드라이버에 해당하는 키의 Start 값 데이터는 굳이 3 으로 변경할 필요는 없습니다.

고로 msahci 키와 pciide 키의 Start 값의 데이터를 모두 0 으로 만들어주면 언제든지 S-ATA 의 모드를 원하는 대로 설정할 수 있게 되는 겁니다. 간단하죠? 또한 이런 식으로 S-ATA 모드를 전환하여 양쪽 모두에 S-ATA 드라이버를 설치해두면 모드에 맞춰 자동으로 해당 드라이버가 적용됩니다. 뭐 사실 그렇게까지 크게 필요는 없어 보이지만요. ^^;


마지막으로 이번 글을 작성하면서 실제로 제 시스템에서 IDE 상태와 AHCI 상태에서 각각 윈도우를 설치한 후, 윈도우 기본 내장 드라이버 상태, 칩셋 드라이버를 설치한 상태, 보드가 인텔인지라 AHCI 일 때는 IRST 까지 설치한 상태, 이렇게 각각의 상태를 설정해놓고, 글에서 언급한 레지스트리의 변경만을 통해 AHCI <-> IDE 모드 전환을 하고, 다시 원래의 모드로 전환하는 테스트를, 반대 값만 0 으로 활성, 반대 값을 0 으로 활성 현재 값을 3 으로 비활성의 테스트를 모두 진행해보았지만, 그 어떤 경우에서도 별다른 문제를 발견하지 못했습니다. 그리고 추가로 검색을 해보아도 동일한 방법으로 문제가 생겼다는 다른 분들의 사례도 딱히 없는 것으로 보아 윈도우 7 에서는 오늘 알려드린 내용만으로도 별 문제가 없을 듯 합니다.

이게 원래 알려진지도 굉장히 오래된 팁이고, 그동안 별다른 문제가 있다는 이야기도 없었기에, 사실 이렇게까지 테스트를 진행해볼만한 글이 아닌데 얼떨결에 하다보니까 그렇게 되었네요. 이상입니다. ㅡㅡ;

출처 : http://cappleblog.co.kr/527

링크 : http://cdmanii.com/2928

Link : http://forum.unity3d.com/threads/unity-4-5-new-hierarchy-window-sorting.248298/#post-1642742

[File]

$AlphaNumericSort.cs

기존의 이름이 아닌 트랜스폼 기준으로 변경되었는데요.

출처 : http://www.gamecodi.com/board/zboard.php?id=GAMECODI_Talkdev&page=1&sn1=&divpage=1&sn=on&ss=on&sc=on&keyword=sort&select_arrange=headnum&desc=asc&no=2703

  [수정]

- Unity2019 대응[2020-11-03]

[파일]

iTween Visual Editor version 0.6.1(with_Unity2019+).zip

[링크]

http://u3d.as/1tM

iTween's  Ease type

iTween 은 간편하게 오브젝트의 이동 에니메션을 쉽게 처리해 줍니다. 

그런데 오브젝트가 로보트처럼 딱딱하게 움직이면 좀 보기가 좋지 않겠죠.

그래서 iTween은 여러가지 ease type를 지정할수 있습니다. 

 EaseOutQuad,    
 EaseInOutQuad,  
 EaseInCubic,    
 EaseOutCubic,   
 EaseInOutCubic, 
 EaseInQuart,    
 EaseOutQuart,   
 EaseInOutQuart, 
 EaseInQuint,    
 EaseOutQuint,   
 EaseInOutQuint, 
 EaseInSine,     
 EaseOutSine,    
 EaseInOutSine,  
 EaseInExpo,     
 EaseOutExpo,    
 EaseInOutExpo,  
 EaseInCirc,     
 EaseOutCirc,    
 EaseInOutCirc,  
 Linear,         
 Spring,         
 EaseInBounce,   
 EaseOutBounce,  
 EaseInOutBounce,
 EaseInBack,     
 EaseOutBack,    
 EaseInOutBack,  
 EaseInElastic,  
 EaseOutElastic, 
 EaseInOutElastic

이 리스트에 보이는 것처럼 상당히 많은 양의 타입을 지정하는데요. 

위의 코드에서 보시다 시피, 해시테이블을 만들때, easeType을 지정하면 됩니다. 

Breakpad Client Libraries

Objective

The Breakpad client libraries are responsible for monitoring an application for crashes (exceptions), handling them when they occur by generating a dump, and providing a means to upload dumps to a crash reporting server. These tasks are divided between the “handler” (short for “exception handler”) library linked in to an application being monitored for crashes, and the “sender” library, intended to be linked in to a separate external program.

Background

As one of the chief tasks of the client handler is to generate a dump, an understanding of dump files will aid in understanding the handler.

Overview

Breakpad provides client libraries for each of its target platforms. Currently, these exist for Windows on x86 and Mac OS X on both x86 and PowerPC. A Linux implementation has been written and is currently under review.

Because the mechanisms for catching exceptions and the methods for obtaining the information that a dump contains vary between operating systems, each target operating system requires a completely different handler implementation. Where multiple CPUs are supported for a single operating system, the handler implementation will likely also require separate code for each processor type to extract CPU-specific information. One of the goals of the Breakpad handler is to provide a prepackaged cross-platform system that masks many of these system-level differences and quirks from the application developer. Although the underlying implementations differ, the handler library for each system follows the same set of principles and exposes a similar interface.

Code that wishes to take advantage of Breakpad should be linked against the handler library, and should, at an appropriate time, install a Breakpad handler. For applications, it is generally desirable to install the handler as early in the start-up process as possible. Developers of library code using Breakpad to monitor itself may wish to install a Breakpad handler when the library is loaded, or may only want to install a handler when calls are made in to the library.

The handler can be triggered to generate a dump either by catching an exception or at the request of the application itself. The latter case may be useful in debugging assertions or other conditions where developers want to know how a program got in to a specific non-crash state. After generating a dump, the handler calls a user-specified callback function. The callback function may collect additional data about the program’s state, quit the program, launch a crash reporter application, or perform other tasks. Allowing for this functionality to be dictated by a callback function preserves flexibility.

The sender library is also has a separate implementation for each supported platform, because of the varying interfaces for accessing network resources on different operating systems. The sender transmits a dump along with other application-defined information to a crash report server via HTTP. Because dumps may contain sensitive data, the sender allows for the use of HTTPS.

The canonical example of the entire client system would be for a monitored application to link against the handler library, install a Breakpad handler from its main function, and provide a callback to launch a small crash reporter program. The crash reporter program would be linked against the sender library, and would send the crash dump when launched. A separate process is recommended for this function because of the unreliability inherent in doing any significant amount of work from a crashed process.

Detailed Design

Exception Handler Installation

The mechanisms for installing an exception handler vary between operating systems. On Windows, it’s a relatively simple matter of making one call to register a top-level exception filter callback function. On most Unix-like systems such as Linux, processes are informed of exceptions by the delivery of a signal, so an exception handler takes the form of a signal handler. The native mechanism to catch exceptions on Mac OS X requires a large amount of code to set up a Mach port, identify it as the exception port, and assign a thread to listen for an exception on that port. Just as the preparation of exception handlers differ, the manner in which they are called differs as well. On Windows and most Unix-like systems, the handler is called on the thread that caused the exception. On Mac OS X, the thread listening to the exception port is notified that an exception has occurred. The different implementations of the Breakpad handler libraries perform these tasks in the appropriate ways on each platform, while exposing a similar interface on each.

A Breakpad handler is embodied in an ExceptionHandler object. Because it’s a C++ object, ExceptionHandlers may be created as local variables, allowing them to be installed and removed as functions are called and return. This provides one possible way for a developer to monitor only a portion of an application for crashes.

Exception Basics

Once an application encounters an exception, it is in an indeterminate and possibly hazardous state. Consequently, any code that runs after an exception occurs must take extreme care to avoid performing operations that might fail, hang, or cause additional exceptions. This task is not at all straightforward, and the Breakpad handler library seeks to do it properly, accounting for all of the minute details while allowing other application developers, even those with little systems programming experience, to reap the benefits. All of the Breakpad handler code that executes after an exception occurs has been written according to the following guidelines for safety at exception time:

• Use of the application heap is forbidden. The heap may be corrupt or otherwise unusable, and allocators may not function.
• Resource allocation must be severely limited. The handler may create a new file to contain the dump, and it may attempt to launch a process to continue handling the crash.
• Execution on the thread that caused the exception is significantly limited. The only code permitted to execute on this thread is the code necessary to transition handling to a dedicated preallocated handler thread, and the code to return from the exception handler.
• Handlers shouldn’t handle crashes by attempting to walk stacks themselves, as stacks may be in inconsistent states. Dump generation should be performed by interfacing with the operating system’s memory manager and code module manager.
• Library code, including runtime library code, must be avoided unless it provably meets the above guidelines. For example, this means that the STL string class may not be used, because it performs operations that attempt to allocate and use heap memory. It also means that many C runtime functions must be avoided, particularly on Windows, because of heap operations that they may perform.

A dedicated handler thread is used to preserve the state of the exception thread when an exception occurs: during dump generation, it is difficult if not impossible for a thread to accurately capture its own state. Performing all exception-handling functions on a separate thread is also critical when handling stack-limit-exceeded exceptions. It would be hazardous to run out of stack space while attempting to handle an exception. Because of the rule against allocating resources at exception time, the Breakpad handler library creates its handler thread when it installs its exception handler. On Mac OS X, this handler thread is created during the normal setup of the exception handler, and the handler thread will be signaled directly in the event of an exception. On Windows and Linux, the handler thread is signaled by a small amount of code that executes on the exception thread. Because the code that executes on the exception thread in this case is small and safe, this does not pose a problem. Even when an exception is caused by exceeding stack size limits, this code is sufficiently compact to execute entirely within the stack’s guard page without causing an exception.

The handler thread may also be triggered directly by a user call, even when no exception occurs, to allow dumps to be generated at any point deemed interesting.

Filter Callback

When the handler thread begins handling an exception, it calls an optional user-defined filter callback function, which is responsible for judging whether Breakpad’s handler should continue handling the exception or not. This mechanism is provided for the benefit of library or plug-in code, whose developers may not be interested in reports of crashes that occur outside of their modules but within processes hosting their code. If the filter callback indicates that it is not interested in the exception, the Breakpad handler arranges for it to be delivered to any previously-installed handler.

Dump Generation

Assuming that the filter callback approves (or does not exist), the handler writes a dump in a directory specified by the application developer when the handler was installed, using a previously generated unique identifier to avoid name collisions. The mechanics of dump generation also vary between platforms, but in general, the process involves enumerating each thread of execution, and capturing its state, including processor context and the active portion of its stack area. The dump also includes a list of the code modules loaded in to the application, and an indicator of which thread generated the exception or requested the dump. In order to avoid allocating memory during this process, the dump is written in place on disk.

Post-Dump Behavior

Upon completion of writing the dump, a second callback function is called. This callback may be used to launch a separate crash reporting program or to collect additional data from the application. The callback may also be used to influence whether Breakpad will treat the exception as handled or unhandled. Even after a dump is successfully generated, Breakpad can be made to behave as though it didn’t actually handle an exception. This function may be useful for developers who want to test their applications with Breakpad enabled but still retain the ability to use traditional debugging techniques. It also allows a Breakpad-enabled application to coexist with a platform’s native crash reporting system, such as Mac OS X’ CrashReporter and Windows Error Reporting.

Typically, when Breakpad handles an exception fully and no debuggers are involved, the crashed process will terminate.

Authors of both callback functions that execute within a Breakpad handler are cautioned that their code will be run at exception time, and that as a result, they should observe the same programming practices that the Breakpad handler itself adheres to. Notably, if a callback is to be used to collect additional data from an application, it should take care to read only “safe” data. This might involve accessing only static memory locations that are updated periodically during the course of normal program execution.

Sender Library

The Breakpad sender library provides a single function to send a crash report to a crash server. It accepts a crash server’s URL, a map of key-value parameters that will accompany the dump, and the path to a dump file itself. Each of the key-value parameters and the dump file are sent as distinct parts of a multipart HTTP POST request to the specified URL using the platform’s native HTTP facilities. On Linux, libcurl is used for this function, as it is the closest thing to a standard HTTP library available on that platform.

Future Plans

Although we’ve had great success with in-process dump generation by following our guidelines for safe code at exception time, we are exploring options for allowing dumps to be generated in a separate process, to further enhance the handler library’s robustness.

On Windows, we intend to offer tools to make it easier for Breakpad’s settings to be managed by the native group policy management system.

We also plan to offer tools that many developers would find desirable in the context of handling crashes, such as a mechanism to determine at launch if the program last terminated in a crash, and a way to calculate “crashiness” in terms of crashes over time or the number of application launches between crashes.

We are also investigating methods to capture crashes that occur early in an application’s launch sequence, including crashes that occur before a program’s main function begins executing.

출처 : https://code.google.com/p/google-breakpad/wiki/ClientDesign

처음에는 Rebase를 왜 해야 하고 언제 어떻게 해야 하는지 좀 헷갈린다. 헷갈리는 이유는 정답이 없고 미묘함이 있어서인데 그래도 대략적인 가이드가 있으면 좋겠다 싶어서 정리해보았다.

Social Coding Platform

svn이나 다른 VCS 도구 말고 git을 사용해야 하는 이유는 커뮤니케이션이다. 개발이라는 작업은 혼자 하는 게 아니라서 코드를 공유하고, 리뷰하고, 피드백을 받아야 하는데 Git으로 하면 일이 좀 쉬워진다(Git이 쉽다는 것은 아니다).

git과 github의 인기는 VCS 본연의 기능뿐만 아니라 커뮤니케이션을 원활하게 할 수 있는 플랫폼이 함께 필요하다는 것을 보여준다. git은 소스관리에도 뛰어난 도구지만 그게 Git만의 장점은 아니다.

git은 단순히 VCS가 아니다. 소스관리뿐만 아니라 커뮤니케이션에 필요한 모든 것이 들어 있다. 특히 코드를 공유하는 것은 정말 끝내 준다. Git 이외에 필요한 도구가 별로 없다. 나는 히스토리를 엉망으로 관리하는 프로젝트을 살펴보고자 gitx를 가끔 사용하고 차이를 살펴보고자 diffmerge를 아주 가끔 사용한다. 정말 아주 가끔이다. 한 달에 한 번도 실행하지 않는다.

그 외에는 항상 콘솔에서 작업한다. git은 아직도 발전 중이고 코드를 쉽게 공유하는 방법이 계속 통합될 것으로 생각한다. git에는 정말 필요한 모든 것이 통합되고 있어서 언젠가 git으로 문자 메시지로 코드를 보낼 수 있는 날이 올지도 모른다는 상상을 하고 있다.

배려

동료는 그녀와 같다. 배려 없이 초대에 응하는 그녀는 없다. 최대한 친절을 베풀어야 그녀를 내 저장소로 초대할 수 있다. 공포를 조장하거나 무턱대고 돈만 살포해서는 진심을 이끌어 낼 수 없다. 스스로 응할 때까지 배려하고 인내해야 한다.

코드는 당연히 잘 짜야 한다. 버그는 없을수록 좋고, 주석은 간략하고 명확해야 하고, 변수나 함수이름, 파일이나 디렉토리 구조나 이름 등등…. 중요하지 않은 것이 없다. 좋은 글에는 좋은 문장도 많은 법이다.

git도 마찬가지다. 변수 이름을 잘 짓듯이 브랜치 이름도 잘 지어야 한다. 커밋 메시지도 표준 포멧에 따라 잘 지어야 한다. 그리고 히스토리도 예쁘게 만들어야 한다.

Merge vs Rebase

Rebase는 히스토리를 단장하는 데 필요하다. 나 혼자 쓰는 저장소에서도 Rebase가 없으면 지저분해서 히스토리를 읽을 수가 없다.

잘 정리한 히스토리를 엿보고 싶다면 npm 저장소를 구경해보는 것이 좋다. @izs님은 완전 git타쿠:

히스토리가 정말 보기 좋다. github의 'pull request'도 사용하지 않고 죄다 손으로 Merge하는 것 같다.

커밋 vs Merge 커밋

Merge와 Rebase를 살펴보기 전에 커밋부터 다시 살펴보자.

커밋은 의미의 단위다. 지금 하는 일을 적당하게 한 조각으로 나눠서 커밋한다. 10줄, 100줄처럼 정량적인 단위가 아니다. 고기를 사듯이 '커밋 한 근 주세요.'라고 말할 수 없다. 커밋 하나는 의미 하나다.

커밋 하나하나에도 의미가 있지만 어떤 모듈을 개발한다면 여러 개를 하나로 묶어서 처리할 필요도 있다. 그러니까 여러 개의 커밋을 묶음으로 표현할 수 있는 커밋이 필요하다. 그게 Merge 커밋이다. Merge 커밋은 일종의 커밋 묶음이다

npm 저장소에 @izs님이 만들어 놓은 Merge 커밋을 보자:

1ecd0eb는 gyp를 구현한 커밋들을 묶어 놓은 Merge 커밋이다. gyp 브랜치를 만들어 gyp를 구현하고 master 브랜치로 Merge했다.

Merge 커밋은 사실 커밋 묶음 나타내는 것이 아니다. 보통 커밋은 Parent가 하나인데 Merge 커밋은 Parent가 여러 개다. 하지만, Parent가 여러 개인 점을 이용해서 커밋 묶음으로 다룰 수 있다:

C6는 Merge 커밋으로 Parent가 두 개다.

Merge 커밋을 Reset하면 관련 커밋이 전부 Reset된다:

C3와 C5가 같이 Reset되기 때문에 master 입장에서는 커밋 묶음이 Reset된 것이다.

npm 저장소에서 master 브랜치가 Merge 커밋인 1ecd0eb를 가리키는 상태에서 'HEAD~1'으로 Reset하면 gyp 브랜치가 통째로 Reset된다. 그래서 master는 c4eb2fd를 가리킨다.

Merge vs Rebase

다음과 같은 브랜치를 Merge, Rebase해보고 그 결과를 비교해보자:

git merge iss1 명령으로 iss1를 Merge한다. 노란색인 C1은 Merge Base이다:

git merge iss2 명령으로 iss2를 Merge한다:

git merge iss3 명령으로 iss3를 Merge한다:

iss1, iss2, iss3를 Merge 했다. C9, C10, C11은 Merge 커밋이다. 이 그림에서는 히스토리가 복잡하지 않다고 생각할 수 있지만, 이정도 되는 내용도 콘솔에서 보면 헷갈린다. 한눈에 들어오지 않는다. 이제 Rebase 후 Merge해보자.

헷갈릴 수 있으니 원본 브랜치를 다시 한번 보고:

git checkout iss1과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C1이 아니라 C4가 된다:

git checkout master과 git merge iss1를 차례대로 실행해서 Merge한다. Rebase를 하면 항상 Fast-Forward Merge가 가능해진다. 하지만, 무턱대고 Fast-Forward Merge를 하는 것이 아니라 앞서 얘기했듯이 커밋을 묶음으로 관리하고 싶지 않을 때만 Fast-Forward Merge한다. 이 경우는 커밋이 하나이므로 그냥 Fast-Forward Merge한다:

git checkout iss2과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3가 아니라 C2'가 된다:

git checkout master과 git merge --no-ff iss2를 차례대로 실행해서 Merge한다.--no-ff 옵션은 강제로 Merge 커밋을 남기려고 주는 것이다. iss2 브랜치는 커밋이 두 개고 이 커밋은 iss2를 처리한 결과이므로 커밋 묶음으로 처리하는 것이 낫다(물론, 내용상 --no-ff 옵션을 주는 게 틀릴 수도 있다.):

git checkout iss3과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3에서 C9이 된다:

git checkout master과 git merge --no-ff iss3를 차례대로 실행해서 Merge한다:

다음 그림은 위에서 Rebase 없이 Merge한 결과다. 한번 비교해보자:

Rebase를 하고 나서 Merge한 것이 훨씬 보기 좋다. 아무리 복잡한 과정을 거쳤어도 한눈에 들어오게 할 수 있다.

마치며

Git처럼 히스토리를 다중으로 관리하는 시스템에서 Rebase는 필수다. Mercurial도 Git의 영향을 받아 Rebase를 지원한다. 이글에서는 Rebase가 왜 필요하고 언제 어떻게 해야 하는지 알아봤다.

UPDATE: 20121122

Merge Commit은 Commit을 묶음으로 관리하는데도 유용하지만 Release Note에 넣을 만한 것을 미리 Merge Commit으로 만들어 놓으면 편리할 것 같다. 배포할 때 Merge Commit만 추려볼 수 있으니 Release Note를 따로 작성하지 않아도 된다.

참조) http://blog.naver.com/goldrushing/130147289978

http://blog.naver.com/bridman/40195903160

출처 : http://mydoh.tistory.com/63

No JVM installation found. Please install a 64-bit JDK.

If you already have a JDK installed, define a JAVA_HOME variable in Computer

> System Properties > System Settings > Environment Variables.

윈도우에서 안드로이드 실행시 위와 같이 에러 문구발생시 아래와 같이 설치해주세요.

1. 아래 사이트로 가서 최신 버젼 JDK를 다운받고 설치 합니다.

http://www.oracle.com/technetwork/java/javase/downloads/index.html

2.  내 컴퓨터 오른쪽 마우스 클릭 > 속성 > 고급시스템설정 에서 [고급]탭을 선택  후 [환경변수]를 클릭 합니다.

3. [새로만들기]를 클릭해서 JAVA_HOME 이라는 변수를 추가 합니다.

JAVA_HOME 은 JDK가 설치된 경로로 등록하시면 됩니다.  ( C:\Program Files\Java\jdk1.8.0_20 )

4. 이번엔 Path 를 찾아서 누른후 편집을 눌러주세요.

그후 ;%JAVA_HOME% 을 변수값 맨뒤쪽에 공백 없이 복사하여 붙여넣기 합니다. path  들과 구분하기 위해 ";" 세미콜론을 사용합니다.
Path-편집  -  ;%JAVA_HOME% 붙여넣기  -  확인클릭
 

5. 마지막으로 정상적으로 설정되었는지 테스트 해보세요.

( 윈도우키+r ) 입력 후 아래와 같이 cmd 실행해주세요.

명령 프롬프트 창에서 javac -version 입력해서 버젼 정보가 출력되면 정상적으로 설치 완료된 것입니다.
(추가: 나는 jdk 1.8.0_31을 깔았는데 cmd에서 위 명령어는 먹히지 않고 java -version 이 됐다. 버전업 되면서 달라진걸까?)

출처 : http://lab.anybuild.co.kr/bbs/faq/3241